java-to-java interprocess communication
Hi all,
we currently have a java front-end talking to a java backend (several java backends, actually) using RMI calls. The front-end and the backends are on different hosts. We plan to move them all onto the same host. For best performance and stability, should we continue using RMI, even though it's the same server, or should we do something else like have the front-end locate the back-end processes by PID and serialize objects through the IO streams?
btw the backends are all different processes because they each communicate with a thread-unsafe native app.
thanks alot!
--neonfrog
[628 byte] By [
tbouck] at [2007-9-26 3:07:07]
Why go through all of that when RMI already does it for you? You will just be doing the exact thing which RMI provides in a clean relatively secure manner.
If you do it yourself you will have to consider and manage all the issues which the RMI developers have covered over the years.
Stick with RMI, makes it easy if you ever want to go back as well.
dnoyeB at 2007-6-29 11:10:33 >
Thanks for the reply--
The major reason I want to know if alternatives to RMI are suggested is that RMI is designed to be used in a distributed environment. I'm sure it will work fine on a single server, but would we be paying in performance for network-access and security overhead we don't need? I'm sure there is at least a minor performance hit because of this, so the question is, "does RMI have considerable unnecessary overhead that we should explore avoiding through handling process communication ourselves?"
Thanks!
--neonfrog
tbouck at 2007-6-29 11:10:33 >
>...but would we be paying in performance...And you are asking this because you have already used an automated performance/profiling tool to determine that RMI has a non-trivial impact on your application?
Unfortunately, we don't have a profiling tool. I'm asking because I want to know if there is any "common knowledge" as to whether RMI is or isn't the best way to go for interprocess communication on a single computer. Since no one is saying, "yes, RMI is designed to be the best way for _any_ two processes to communicate with one another" and no one is saying "no, silly, RMI is really optimized for distributed objects", I'm guessing there isn't any common knowledge on the subject.
--neonfrog
tbouck at 2007-6-29 11:10:34 >
Let me spell it out :)
U.S.E. R.M.I.
Indeed if microsoft though of this, I know Sun and Java have too. I am more than willing to bet that local RMI will not use all the code remote RMI would. And would be quite a bit more efficient. This would be a function of the server though. I mean, once your client gets a reference, and the marshaller realizes its local, im sure you wont be going through the IP stack. I could be wrong, but DCOM has this much sense, so I assume RMI does as well.
If your passing Objects, do the RMI. primitives, then you have options.
If you dont believe me, just start writing the marshalling - unmarshalling code, and start compensating for bigendian and little endian and Unicode vs ASCII, security, etc. When your done, guess what you will have? RMI ;-)
You could try CORBA, but its got 2 be heavier than RMI. if your doing primitives, named pipes is coming in 1.4 I hear.
Ok, I ramble too much. But use the architecture which is supplied, "secured", and operational.
dnoyeB at 2007-6-29 11:10:34 >
The only alternativ is see is to throw away the remote stuff completely but of cours this only works if you will never ever go back to a more then 1 server scenarioSpieler
Hi all,
thanks alot for the input. specifically what I was planning on doing is locating the back-end process by PID, getting a Process object, and connecting to its input and output streams. Then I could send a single signal indicating what I wanted to the instream, which would trigger the backend to do some stuff and come up with a result for me, wrapped in some kind of class. This class could be converted to byte[] and serialized to the ostream back to the calling process, which could then have its own classloader to generate an object from the byte array and cast it. I don't see that this would necessesitate rewriting all the big/little endian stuff and generic argument marshalling etc.
Although I think we will go with RMI (or at least run a test), do you guys see any immediate flaw in this strategem?
thanks
--neonfrog
tbouck at 2007-6-29 11:10:34 >
>I mean, once your client gets a reference, and the marshaller realizes its
>local, im sure you wont be going through the IP stack
I am not as sure about that. That would imply that it is using another communication medium besides sockets. And I don't think it does.
However, I do believe socket communication on a single box is significantly faster than over a network (presuming that the machine is normally faster than the network.) At the very least there is no collision handling so that should boost the rate to 12meg rather than the normal 6-7 meg.
> >I mean, once your client gets a reference, and the
> marshaller realizes its
> >local, im sure you wont be going through the IP
> stack
>
> I am not as sure about that. That would imply that it
> is using another communication medium besides sockets.
> And I don't think it does.
>
> However, I do believe socket communication on a single
> box is significantly faster than over a network
> (presuming that the machine is normally faster than
> the network.) At the very least there is no collision
> handling so that should boost the rate to 12meg rather
> than the normal 6-7 meg.
You are assuming Sun is leaving the optimization to the socket. IF its normal for a socket to"short cirtuit" on localhost connections, then probably yes. But somehow they will have to stay off the wire for efficiency and DCOM does so I expect RMI to as well. anyway I tested this years ago in school, and local is VERY much faster than remote.
dnoyeB at 2007-6-29 11:10:34 >
