Steven,

I think you might need to do some more debugging to try and pinpoint the
exact point where the body is null unless others have more time to look at
it.  As Art said, check different points where the body could be null.

I originally thought I had found the issue when I tested synchronizing on
the getText() method just to see if that would fix it but I forgot that the
VM transport and other parts of the broker actually copy the message so two
threads shouldn't be accessing getText() at the same time and your
consumers should each get their own copy of the message.

On Thu, May 31, 2018 at 9:50 AM, Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> I forgot that when using the VM transport the message is supposed to be
> copied on dispatch inside ActiveMQConnection so this may not be the exact
> issue, I need to look at it a bit more.
>
>
> On Thu, May 31, 2018 at 9:41 AM, Christopher Shannon <
> christopher.l.shan...@gmail.com> wrote:
>
>> The issue is when using the VM transport and the getText() method has to
>> unmarshall data back into text from the byte sequence.  This happens
>> because you go from the NIO to VM transport.
>>
>> The main problem is you have multiple threads (3 consumers) at the same
>> time calling getText() on the text message and there is a race condition
>> where it will set the content to null during it.
>>
>> I created a very simple test case to show the issue and created a jira
>> https://issues.apache.org/jira/browse/AMQ-6981
>>
>> On Wed, May 30, 2018 at 6:06 PM, Arthur Naseef <a...@amlinv.com> wrote:
>>
>>> Try turning the broker and client logging up to trace and see what the
>>> logging shows for the message content.
>>>
>>> Also, try the following:
>>> - Same test with a Java producer (using plain ActiveMQ libs) instead of
>>> the
>>> Scala producer
>>> - Same test with a Java consumer (using plain ActiveMQ libs) instead of a
>>> Scala consumer
>>> - Use the "tcp" transport instead of the "nio" transport
>>>
>>> Anyway, the goal I would say is to trace the problem to the point of
>>> hand-off between the broker and client.  For example, the following
>>> questions come to mind (for the problematic messages):
>>> - Is the broker receiving the body over the wire (i.e. tcp connection)?
>>> - Is the broker sending the body over the wire?
>>> - Is the client library receiving the body from the application?
>>> - Is the client library sending the body to the application?
>>>
>>> Hope this helps.
>>>
>>> Art
>>>
>>>
>>> On Wed, May 30, 2018 at 2:41 PM, codingismy11to7 <ste...@codemettle.com>
>>> wrote:
>>>
>>> > We recently updated from (ancient) ActiveMQ 5.10.x to 5.15.4. I've
>>> noticed
>>> > that text messages are now sporadically returning null as their message
>>> > bodies when they were sent with bodies.
>>> >
>>> > After failing to make a unit test showing this error, I created a
>>> project
>>> > that reproduces part of what our software is doing, which reliably
>>> > replicates the race condition (my last run got null message bodies on
>>> > ~0.03%
>>> > of messages). I was able to vastly simplify what our software is doing
>>> and
>>> > still reproduce, but when I tried to simplify further the issue stopped
>>> > appearing.
>>> >
>>> > Reproduction and full explanation:
>>> > https://github.com/CodeMettle/amq_null_body_repro
>>> >
>>> > Since I don't have a self-contained unit test I was hesitant to open an
>>> > issue directly and decided to send a message here instead.
>>> >
>>> > I'm a Scala/Akka developer, so I used the tools I was comfortable with
>>> to
>>> > make this reproduction without writing a lot of code, but I'm sure
>>> somebody
>>> > more comfortable in Java and the ActiveMQ API could reproduce in a unit
>>> > test. I'm assuming it has something to do with multiple Sessions
>>> consuming
>>> > the same topic and calling TextMessage.getText at the same time.
>>> >
>>> > Any suggestions of what to do next?
>>> >
>>> > Thanks
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-
>>> > f2368404.html
>>> >
>>>
>>
>>
>

Reply via email to