activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John F. Lentz" <>
Subject Re: Strange StreamMessage problem
Date Thu, 27 Mar 2008 20:42:16 GMT

After looking at the documentation more closely I think I've answered my own
question, and that this behavior is by design.

"To read the field value, readBytes should be successively called until it
returns a value less than the length of the read buffer. The value of the
bytes in the buffer following the last byte read is undefined. 

If readBytes returns a value equal to the length of the buffer, a subsequent
readBytes call must be made. If there are no more bytes to be read, this
call returns -1. "[])[]) 

By those lines of documentation it looks like that -1 return value is used
as an indicator that the byte array has been fully read.  And therefore even
if the user knows the size of the byte array they should make another call
to the readBytes() method in order to clear out that indicator flag.

John L.

John F. Lentz wrote:
> I can't find an answer to this question in the forum, so I appologize if
> it has already been addressed.
> I'm having a strange effect when using a stream message to transmit
> multiple byte arrays in a single message.
> My message consists of the following stream (short, byte[], int, byte[]). 
> When I attempt to call StreamMessage.readBytes to get the second byte
> array out of the stream it returns -1.  Reading the documentation it
> sounds like that indicates that there is a null byte array in the stream. 
> If I then attempt to the StreamMessage.readBytes call again I get the
> results that I'm expecting.
> If I send the following stream (short, int, byte[]) then I see the
> expected behavior with that byte array.  Meaning that the first time I
> attempt to read the byte[] out of the StreamMessage that it retrieves the
> array succesfully.
> Any idea what is going on?
> Thanks,
> John L.

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message