Is your client in the same VM as the server?
Are you saying that when you call getText on the text message it returns an empty string?
Thanks for the response.
I found the problem. It only occurs when the text message exceeds a certain size.
I don't know how to increase this limit. The messages could be as much as 100K.
I wonder if you're running into the writeUTF() limit, which is 64k.
Good point. Could well be the 64K limit.
Apologies, I am currently travelling back from JbossWorld so probably won't be able to investigate for a couple of days.
I am running into a 32K limit - to the byte.
I have 32K test string that works but as soon as I add 1 more character it bombs
I have replicated this and can confirm it is due to the 64K limit "bug" in writeUTF (thanks Elias for the hint).
The fix is fairly straightforward and will be in the next release.
In the mean-time the workaround is not to use strings > 64K in text messages, object messages, map messages or as string properties.
Instead you can convert to a byte in your code and convert back on receipt.
Thanks for your patience.
Ok, I have fixed this in CVS HEAD.
We now support strings up to 4GB as bodies of TextMessages or ObjectMessages.
All other strings in messages (i.e. string properties, other string fields, strings in map messages, stream messages or bytes messages) still have the 64K limit.
This is because there is some overhead in coping with longer strings and I don't want to hit performance for the normal case of smaller strings.
Tim, you're welcome for the hint. I would suggest documenting the 64k limitations for properties, map messages, etc., and as an improvement add a method that checks at the API level when limit is crossed.