Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2005

Tip: Looking for answers? Try searching our database.

Corrupt String or bytearray  transport over RMI

Thread view: 
Rolfje - 25 Jul 2005 12:57 GMT
Hello,

I have a strange problem when transporting a String and it's byteArray
between 2 JVM's on the same machine. The JVMs are seperately started
instances of IBM's 1.3.1 JVM which also comes with Websphere 4.5.

On JVM1, I have something along the lines of:

String jvm1String = "Some nice String";
byte[] jvm1bytes = jvm1String.getBytes("ISO-8859-1");

Now, I transport the string and the array through RMI toto JVM2. In
JVM2 I do the following:

jvm2bytes = jvm1String.getBytes("ISO-8859-1");

for (int i = 0; i < jvm2bytes.length; i++) {
 if (jvm2bytes[i] != jvm1bytes[i]) return false;
}

This allways returns false. Manually checking the arrays shows that the
two byte arrays only differ somewhere in the middle, and only for about
2 bytes, regardless the content of the String. I have no idea what
would cause java to behave differently between the two jvm's.

My question is: Is this likely to be a bug in:
a) the transportation of Strings over RMI
b) the transportation of byte arrays over RMI
c) the way String.getBytes("ISO-8859-1") is implemented
d) the way I am using rmi or the getBytes() method

Due to requirements, I can not change the JVM, so I need to find a way
around this. I am using the bytearrays to verify data integrity.

Thanks in advance,
Rolf
Thomas Weidenfeller - 25 Jul 2005 14:17 GMT
> This allways returns false. Manually checking the arrays shows that the
> two byte arrays only differ somewhere in the middle, and only for about
> 2 bytes, regardless the content of the String.

And you don't want to tell us the exact difference? E.g. showing us the
 byte values which differ? Should we use our paranormal forces to guess
them?

> My question is: Is this likely to be a bug in:
> a) the transportation of Strings over RMI
> b) the transportation of byte arrays over RMI
> c) the way String.getBytes("ISO-8859-1") is implemented
> d) the way I am using rmi or the getBytes() method

Get more facts. Use

a) A debugger to inspect the original byte array and the received byte
array to check the encoding.

b) Compare the bytes to an ASCII / ISO Latin 1 code table to figure out
which characters got encoded or decoded wrongly. I am surprised that you
didn't do this already.

c) Get a network sniffer like Ethereal and check what is actually going
over the wire.

/Thomas

Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Rolfje - 27 Jul 2005 09:40 GMT
First of all, I humbly apologize for underestimating your paranormal
forces :-).

I took your advise on inspecting the byte arrays. It seems I got so
distracted by the character sets, toByteArray() and other distracting
code, that I overlooked the fact that somewhere in the middle, the
actual strings really did not match exactly.

The cause of this all was a bug in a bussines class which mutilated
itself when serializeing/ deserializing. Then, the toString() method
was used to get the (rather large) byte array from.

So, no magic here, just a plain overlooking of the obvious :-)

Thanks for putting me back on track, by sending me back to the debugger
and inspect the data byte-by-byte.

All the best,
Rolf


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.