Java Object Output Stream and Ice

[brian]

Hello again,

We have been using Ice, IcePack, IceStorm, IceBox, and Freeze successfully now for over 2 years in a heterogenous (Java/C++, Unix/Windows), distributed environment and we love it! Thanks again for all the great work.

We just noticed a performance issue in legacy non-Ice Java code that uses ObjectOutputStream and ObjectInputStream objects to read and write across processes. It appears as though the consumer is not keeping up with the producer and conquently the producer process is blocking a lot. Classic problem. We had a similar problem in Ice using two-way proxies, but once we changed to one-way proxies, performance got a *lot* better.

I have been trying to find out the underlying protocol that Java Object Streams at javasoft.com, but to no avail. I assume its TCP/IP two-way protocol, but cannot confirm.

We are considering re-engineering this communication link using Ice one-way proxies, but want to make sure it is worth it. Do you know if Java Object Streams use, in fact, a two-way protocol? Are there any recommendations you would have -- e.g. UDP vs. TCP -- for this problem?

Thanks a bunch for your help.

Brian

[mes]

Hi Brian,

The ObjectInputStream and ObjectOutputStream classes only perform "marshaling", i.e., they translate Java primitive and object types into a binary format, and vice versa. They can be wrapped around another stream, such as one you might get from a network connection, but they don't perform any networking tasks themselves. You'll need to examine the legacy application in more detail to discover the origin of the underlying stream.

Hope that helps,
- Mark

[brian]

Good point. the ObjectOutputStream is constructed this way:

ServerSocket serverSocket = new ServerSocket( somePort );
Socket socket = serverSocket.accept();
ObjectOutputStream oos = new ObjectOutputStream( socket.getOutputStream() );

.....
while(...)
oos.writeObject(...)

The ObjectInputStream construction:

Socket socket = RMISocketFactory.getDefaultSocketFactory().createS ocket( InetAddress.getLocalHost().getHostName, port );
...
ObjectInputStream ois = new ObjectInputStream( socket.getInputStream() );
...

while( ... )
ois.readObject();

I suppose we can experiment with setting socket buffer sizes, but wanted your opinion if you thought Ice might be better is this situation for some reason. This connection will always be Java<->Java.

THanks again,

Brian

[marc]

Since this is a general Java question, let me suggest that you post this question in some Java support forum.

[brian]

Marc,

I was only trying to give some background to the basic questions which I stated which is:

Do you think can Ice achieve better performance than this current implementation of Object streams using sockets from Java server and client. Perhaps using one-way proxies. Please read the entire thread.

Your thoughts would be very much appreciated.

Thanks,

Brian

[marc]

I'm sorry, but we do not have any performance data for your current implementation, therefore we cannot give any advice. If you would like us to investigate, please contact us at info@zeroc.com for commercial consulting services.

[rdilipk]

I not 100% sure if this is relevant but it appears that java.io.ObjectInputStream and java.io.ObjectOutputStream does appear to have some performance related issues. So much so that the JBoss gang have come up with thier own version of Java serialization (although I **think** it works only with JDK 1.5). This is probably old news, but pls take a look at this:
http://labs.jboss.com/portal/?ctrl:i...=serialization

[michi]

OutputStream would have to be implemented using introspection. At a hunch, I'd say that it's the introspection that causes the loss of performance, not the socket or the serialization as such. (Ice doesn't use introspection to marshal Slice types in Java.)

Cheers,

Michi.

[brian]

Michi & rdilipk,

Thank you both for you comments/suggestions. This is the kind of information I was seeking in the first place.

Brian