((BytesMessage)message).readBytes(...) on a redelivered Byte

[plesur]

JBoss 4.2.2.GA
JBoss Messaging 1.4.0.SP3
JBoss Remoting 2.2.2.SP7

Hi,

my 'payload'-bytearray (see below) which has been declared and initialized via:
byte[] payload = new byte[(int)bytesmessage.getBodyLength()];
has the right size ((int)bytesmessage.getBodyLength() still returns the correct size of a redelivered BytesMessage's payload).

But then calling bytesmessage.readBytes(payload) method on a redelivered BytesMessage results in a strange behavior (maybe only strange for me:) - the 'payload'-bytearray is still initialized although as I can see when I debug my project the JBossBytesMessage.payloadAsByteArray[] property (private) isn't empty and holds the right content.

It plays not matter if I'm testing with standalone remote MessageListener-ClientApplications or under deployed MDBs - same behavior.

public void onMessage( Message message )
{
 try
 {
 if (message instanceof BytesMessage)
 {
 // Create bytemessage object to hold the content of the bytemessage
 BytesMessage bytesmessage = (BytesMessage)message;

 // Create bytearray in size of the bytemessage
 byte[] payload = new byte[(int)bytesmessage.getBodyLength()];

 // Read the bytemessage
 bytesmessage.readBytes(payload);

 .
 .
 .

It sounds a bit like:
http://jira.jboss.org/jira/browse/JBMESSAGING-1079
but this is old and should be fixed since 1.4.0.SP1

Can someone replicate this - or am I doing something wrong?

Thanks in advance!

[jmesnil]

"plesur" wrote:

But then calling bytesmessage.readBytes(payload) method on a redelivered BytesMessage results in a strange behavior (maybe only strange for me:) - the 'payload'-bytearray is still initialized although as I can see when I debug my project the JBossBytesMessage.payloadAsByteArray[] property (private) isn't empty and holds the right content.

I'm not sure to follow you: you say that your 'payload' byte array is initialized with the content of the BytesMessage, right?
If that's the case, it is the expected behavior.

hope it helps,
jeff

[plesur]

"jmesnil" wrote:

I'm not sure to follow you: you say that your 'payload' byte array is initialized with the content of the BytesMessage, right?
If that's the case, it is the expected behavior.

hope it helps,
jeff

Hi Jeff,

with initialized i mean a new created empty bytearray in the size of the Bytemessage's payload:
byte[] payload = new byte[(int)bytesmessage.getBodyLength()];

with:
bytesmessage.readBytes(payload);
it should be filled - this is what didn't work for me on a >redelivered message<.

[jmesnil]

"plesur" wrote:

with initialized i mean a new created empty bytearray in the size of the Bytemessage's payload:
byte[] payload = new byte[(int)bytesmessage.getBodyLength()];

with:
bytesmessage.readBytes(payload);
it should be filled - this is what didn't work for me on a >redelivered message<.

Ok, we're on the same page.

This is indeed weird. We have a JUnit test BytesMessageTest.testRedelivery() which checks this use case and this test pass for JBM 1.4.0.SP3.
Our test does not use a MessageListener but I don't think it'd affect the message behaviour.

Can you write a unit test which reproduces your problem in your environment?

[plesur]

Hi Jeff,

sorry wasn't available for the last two days.
I know now how I can prevent an empty byte-array on a redelivered bytemessage (redelivered by session.recover() on a non-transacted client_acknowledge-session)
which I get by invoking the previous mentioned standardoperations.

The problem 'at our site' seems to be based on the configuration attributes:
. DefaultRedeliveryDelay (messaging-service.xml) &
. RedeliveryDelay (destinations-service.xml) (overwrites ServerPeer default)

My testresults for readBytes(...) on a redelivered bytesmessage with payloadAsByteArray=[72, 73, 95, 74, 69, 70, 70, 10]:
using the standard non clustered destination: testQueue.
with 0 or 1 msec as DefaultRedeliveryDelay & RedeliveryDelay or no entry (RedeliveryDelay only of course)
are:

ServerPeer (DefaultRedeliveryDelay) --- Destination (RedeliveryDelay) --- Result (Content of byte[] after .readBytes(...))
-------------------------------------
0 --- 0 --- [0, 0, 0, 0, 0, 0, 0, 0]
1 --- 0 --- [0, 0, 0, 0, 0, 0, 0, 0]
0 --- 1 --- [72, 73, 95, 74, 69, 70, 70, 10]
1 --- 1 --- [72, 73, 95, 74, 69, 70, 70, 10]
0 --- / --- [0, 0, 0, 0, 0, 0, 0, 0]
1 --- / --- [72, 73, 95, 74, 69, 70, 70, 10]

The weird thing is that case #5 can be found as part of the default configuration.
Well it's hard to believe that 'our' problem is based only on these two attributes
(many others would have the same problem then) but I can live with it knowning
that in the end the final saying delayattribute must have an value greater or equal one msec.

lesse