You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Marc Weil <ma...@gmail.com> on 2010/03/11 22:51:01 UTC

BlobMessage Corruption in OpenJDK?

Hey all,

I seem to have run into a strange problem, and I'm not sure if it's
ActiveMQ's fault or not. I figured I'd ask if anyone here has heard of it
just in case, though.

So, I am using a BlobMessage to send a large message from a client to a
server. The AMQ instance as well as the process listening to it are both
running on the same server on the OpenJDK Runtime Environment (IcedTea6
1.6.1) (6b16-1.6.1-3ubuntu1), OpenJDK 64-Bit Server VM (build 14.0-b16,
mixed mode). I am sending a BlobMessage by constructing it with an
InputStream. When I send the BlobMessage from a client machine running Sun's
HotSpot JDK (6.0 of course), everything works fine. However, when the
message is sent from a client machine also running OpenJDK (the same version
as the server), the data has a ton (several hundred kilobytes) of NULL
characters appended to the end. It also seems as if EOF isn't being sent
correctly by the client. I'm seeing these characters when I examine the
temporary file in the Jetty server's "data" directory. These extra NULL
characters are breaking the SAX parser we are using later on in the system.

This is how I'm sending the message:

            // Open a session
            ActiveMQSession session = (ActiveMQSession)
this.connection.createSession(false, Session.AUTO_ACKNOWLEDGE);

            // Get ready to send a message to the meta queue
            Destination sendDestination = session.createQueue("myQueue");
            MessageProducer producer =
session.createProducer(sendDestination);
            producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

            // Set up the receiving temporary queue
            Destination receiveDest = session.createTemporaryQueue();
            MessageConsumer consumer = session.createConsumer(receiveDest);

            // Create the message and add the metadata
            BlobMessage message = session.createBlobMessage(stream); //
            message.setObjectProperty("metadata", meta);

            // Set the reply to the temp queue
            message.setJMSReplyTo(receiveDest);

            String correlationID = createRandomString();
            message.setJMSCorrelationID(correlationID);

            // Finally send the message
            producer.send(message);

And this is how I'm receiving it:

            Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
            Destination listenDestination = session.createQueue("myQueue");
            MessageConsumer consumer =
session.createConsumer(listenDestination);
            MessageProducer replyProducer = session.createProducer(null);
            replyProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
            BlobMessage msg = (BlobMessage) consumer.receive();

Has anyone heard of any problems with this in AMQ? Again, I'm not sure that
the issue lies here. However I'm pretty suspicious of it since the data is
corrupted once it is turned into a jetty temporary file.

*** We are using ActiveMQ 5.3.0, and again, the JDK on which the problem is
occurring has a version string of OpenJDK Runtime Environment (IcedTea6
1.6.1) (6b16-1.6.1-3ubuntu1), OpenJDK 64-Bit Server VM (build 14.0-b16,
mixed mode). ***

Thanks!
Marc Weil

Re: BlobMessage Corruption in OpenJDK?

Posted by Marc Weil <ma...@gmail.com>.
Márcio,

Yeah I'm quite sure it has something to do with an incompatibility of some
sort between ActiveMQ and OpenJDK. To answer your question, yes I have tried
it with the Sun JDK on both sides and it works perfectly. It also works when
the client uses the Sun JDK and the server (where ActiveMQ is running) uses
OpenJDK. It only doesn't work when the client uses OpenJDK. That leads me to
believe that the problem is somewhere on the sending side of things. Perhaps
some of the logic inside BlobMessage's send() method is the culprit?

Thanks,
Marc

2010/3/12 Márcio Geovani Jasinski <ma...@gmail.com>

> Hi Marc,
>
> Sorry by the misunderstood. Reading once more your first message I
> understood better what you mean.
>
> By your description, I would think that the problem resides on OpenJDK side
> cause your code looks fine.
> Second, the same configuration works using Hot Spot version.
>
> If it's possible I would give a try using Sun JDK/JRE on both sides. Is it
> possible?
>
> --
> Márcio Geovani Jasinski
> Blumenau, Santa Catarina
>

Re: BlobMessage Corruption in OpenJDK?

Posted by Márcio Geovani Jasinski <ma...@gmail.com>.
Hi Marc,

Sorry by the misunderstood. Reading once more your first message I
understood better what you mean.

By your description, I would think that the problem resides on OpenJDK side
cause your code looks fine.
Second, the same configuration works using Hot Spot version.

If it's possible I would give a try using Sun JDK/JRE on both sides. Is it
possible?

-- 
Márcio Geovani Jasinski
Blumenau, Santa Catarina

Re: BlobMessage Corruption in OpenJDK?

Posted by Marc Weil <ma...@gmail.com>.
Márcio,

I certainly am not appending those characters intentionally! I apologize if
my first message made it seem like that was my doing. The stream is somehow
getting corrupted and those characters are getting appended to the end of
the transmitted data on the server side. That's the problem I'm trying to
solve.

Thanks,
Marc

2010/3/12 Márcio Geovani Jasinski <ma...@gmail.com>

> HI Marc,
>
> At least in C++ null character (\0) means end of strings and as I remember
> same thing applies to files.
> In your position I would try to avoid those null characters unless you have
> a really good reason for that...
>
> Have you tried send BlobMessages without those NULL chars appended?
>
> --
> Márcio Geovani Jasinski
> Blumenau, Santa Catarina
> Fone: +55 47 9653 4899
>

Re: BlobMessage Corruption in OpenJDK?

Posted by Márcio Geovani Jasinski <ma...@gmail.com>.
HI Marc,

At least in C++ null character (\0) means end of strings and as I remember
same thing applies to files.
In your position I would try to avoid those null characters unless you have
a really good reason for that...

Have you tried send BlobMessages without those NULL chars appended?

-- 
Márcio Geovani Jasinski
Blumenau, Santa Catarina
Fone: +55 47 9653 4899