TextMessages returned as payloadasbytearray

[onit]

Hello,

I am using:
JBoss_4_0_4_GA
JBoss Messaging 1.0.1.CR2

Everything is on one JBoss server.

I have an EJB that is virtually identical to the messaging stateless EJB in the examples that come with JBoss Messaging. The EJB has a sendRequest method that puts a TextMessage in a queue named requestQueue and a getResponse method that retrieves TextMessages from a queue named responseQueue.

A MDB is listening on the requestQueue queue. It processes the request and puts the results into a TextMessage and sends it to the responseQueue queue.

When the EJB gets the TextMessage from the responseQueue the payload is an empty string but the message seems to be in the payloadasbytearray.

I'm guessing this has something to do with serialization.

Any help or direction would be greatly appreciated.

Thanks,

Dennis

[timfox]

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?

[onit]

Tim,

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.

Thanks again,

Dennis

[genman]

I wonder if you're running into the writeUTF() limit, which is 64k.

[timfox]

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.

[onit]

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

Dennis

[timfox]

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.

[timfox]

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.

[genman]

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.