activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alistair Young <alistair.yo...@uhi.ac.uk>
Subject Re: Random persistent messages lost
Date Tue, 27 Sep 2011 13:58:29 GMT
I resorted to tcpdump on the broker and the consumer to track the messages and it seems the
consumer is dropping messages. Of 16 incoming identical messages, it only acted upon 3. Also,
it failed to act on another single message. By that, it didn't pass them to the message handler.
tcpdump showed the messages arriving at the consumer. Is there anything I could poke to see
why the consumer would discard messages?

Alistair

-- 
mov eax,1
mov ebx,0
int 80h




On 27 Sep 2011, at 11:40, Alistair Young wrote:

> this is the code that does the sending. I've just watched a batch of three messages being
sent, two simply disappeared.
> 
>        ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(brokerURL);
>        connection = connectionFactory.createConnection();
>        connection.setClientID(clientId);
>        connection.start();
>        session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>        destination = session.createTopic(topicName);
>        producer = session.createProducer(destination);
>        producer.setDeliveryMode(messageMode);
>      TextMessage message = session.createTextMessage(messageText);
>      producer.send(message);
> 
> I tried to create a simple test but the embedded broker never calls isAllowedToConsume
> 
> Alistair
> 
> 
> -- 
> mov eax,1
> mov ebx,0
> int 80h
> 
> 
> 
> 
> On 27 Sep 2011, at 11:36, Alistair Young wrote:
> 
>> the topic consumers don't need to be present when the message is sent as the messages
are persistent and they are durable topic subscribers. They are never persisted by activemq.
They just disappear. I can't track the messages through the system as isAllowedToConsume is
never called for the original message. It's only called when camel reroutes the message and
camel never sees the missing messages, as verified by org.apache.camel.Processor instances.
>> 
>> Alistair
>> 
>> 
>> -- 
>> mov eax,1
>> mov ebx,0
>> int 80h
>> 
>> 
>> 
>> 
>> On 27 Sep 2011, at 11:25, Gary Tully wrote:
>> 
>>> please provide some code that demonstrates your problem. Are you sure
>>> that the topic consumers are present when the messages are sent?
>>> Try and reduce the complexity of your usecase, the bottom line is that
>>> messages won't just disappear without good reason, there are hundreds
>>> of test cases that verify this is the case.
>>> 
>>> 
>>> On 27 September 2011 11:16, Alistair Young <alistair.young@uhi.ac.uk> wrote:
>>>> not a lot seems to work. 8 identical messages sent to the broker in quick
succession. Three arrived, 5 just disappeared. It's complicated by the fact MessageAuthorizationPolicy::isAllowedToConsume
never seems to be called for the original message, so I can't really verify whether the message
disappeared once inside activemq. isAllowedToConsume is only called when the message is routed
by camel to the next topic:
>>>> 
>>>> message -> topicA -> camel -> topicB
>>>> 
>>>> isAllowedToConsume is never called for topicA
>>>> isAllowedToConsume is called for topicB with a destination of topic://topicB
>>>> 
>>>> Alistair
>>>> 
>>>> --
>>>> mov eax,1
>>>> mov ebx,0
>>>> int 80h
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 26 Sep 2011, at 16:19, Alistair Young wrote:
>>>> 
>>>>> trying to log incoming messages at the broker to narrow the problem and
another problem appears. This works on one server but adds 0x0 chars on another so the message
fails to parse:
>>>>> 
>>>>> public boolean isAllowedToConsume(ConnectionContext context, Message
message) {
>>>>> 
>>>>> new String(message.getContent().data, message.getContent().offset, message.getContent().length)
>>>>> 
>>>>> so on one server the offset and length are wrong as it seems to report
too many chars
>>>>> 
>>>>> Alistair
>>>>> 
>>>>> --
>>>>> mov eax,1
>>>>> mov ebx,0
>>>>> int 80h
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 22 Sep 2011, at 12:05, Gary Tully wrote:
>>>>> 
>>>>>> Is this code shared by multiple threads? does it need synchronization?
>>>>>> 
>>>>>> What you are experiencing does seem odd, it would be great if you
>>>>>> could provide a simple junit test case that can reproduce.
>>>>>> 
>>>>>> Also, peeking that the code of the logging plugin, it should be
>>>>>> logging sends, that is again odd:
>>>>>> http://svn.apache.org/viewvc/activemq/tags/activemq-5.5.0/activemq-core/src/main/java/org/apache/activemq/broker/util/LoggingBrokerPlugin.java?view=markup
>>>>>> 
>>>>>> On 22 September 2011 10:59, Alistair Young <alistair.young@uhi.ac.uk>
wrote:
>>>>>>> would someone be kind enough to have a quick look at this code
to see if it could cause problems? The method returns a reusable connection so the user of
the class doesn't have to connect/disconnect on every message. The first message never fails,
it's always when reusing the connection that random messages disappear.
>>>>>>> 
>>>>>>> thanks,
>>>>>>> 
>>>>>>> Alistair
>>>>>>> 
>>>>>>> try {
>>>>>>>   // Try to reuse a previous connection
>>>>>>>   if (previousMxConnection == null) {
>>>>>>>     ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(brokerURL);
>>>>>>>     connection = connectionFactory.createConnection();
>>>>>>>     connection.setClientID(clientId);
>>>>>>>     connection.start();
>>>>>>>     session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
>>>>>>>     destination = session.createTopic(topicName);
>>>>>>>     producer = session.createProducer(destination);
>>>>>>>     producer.setDeliveryMode(messageMode);
>>>>>>> 
>>>>>>>     mxConnection = new MatrixConnection();
>>>>>>>     mxConnection.connection = connection;
>>>>>>>     mxConnection.session = session;
>>>>>>>     mxConnection.destination = destination;
>>>>>>>     mxConnection.producer = producer;
>>>>>>>   }
>>>>>>>   else {
>>>>>>>     session = previousMxConnection.session;
>>>>>>>     if (previousMxConnection.producer == null) {
>>>>>>>       producer = session.createProducer(previousMxConnection.destination);
>>>>>>>       producer.setDeliveryMode(DeliveryMode.PERSISTENT);
>>>>>>>       previousMxConnection.producer = producer;
>>>>>>>     }
>>>>>>>     else {
>>>>>>>       producer = previousMxConnection.producer;
>>>>>>>     }
>>>>>>>     mxConnection = previousMxConnection;
>>>>>>>   }
>>>>>>> 
>>>>>>>   TextMessage message = session.createTextMessage(messageText);
>>>>>>>   producer.send(message);
>>>>>>> 
>>>>>>>   return mxConnection;
>>>>>>> }
>>>>>>> catch(Exception e) {
>>>>>>>   throw new MatrixClientException(e);
>>>>>>> }
>>>>>>> }
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> mov eax,1
>>>>>>> mov ebx,0
>>>>>>> int 80h
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 22 Sep 2011, at 10:50, Alistair Young wrote:
>>>>>>> 
>>>>>>>> nothing seems to help. There are still messages just disappearing.
Also the logging doesn't seem to log anything to do with producers:
>>>>>>>> 
>>>>>>>> <loggingBrokerPlugin logAll="true" logConnectionEvents="true"
/>
>>>>>>>> 
>>>>>>>> I can see lots of camel consumers from the local machine
looking at the routes but nothing about incoming messages from producers.
>>>>>>>> 
>>>>>>>> Alistair
>>>>>>>> 
>>>>>>>> --
>>>>>>>> mov eax,1
>>>>>>>> mov ebx,0
>>>>>>>> int 80h
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 21 Sep 2011, at 13:13, Alistair Young wrote:
>>>>>>>> 
>>>>>>>>> I'm running ActiveMQ 5.5.0 as a spring webapp rather
than the standalone version. Would you recommend the standalone one? Not sure how to use camel
with that though.
>>>>>>>>> 
>>>>>>>>> there's quite a high rate of packet loss on the network
it seems and according to this:
>>>>>>>>> http://activemq.apache.org/async-sends.html
>>>>>>>>> the default is sync send for persistent messages outside
transactions. I'm using transactions on the broker but not the producer to preserve camel
routes across restarts. So I presume the producer is using sync mode to send the messages
as they are persistent. However, no error from the broker and no message arriving might hint
at async mode falling foul of packet loss perhaps?
>>>>>>>>> 
>>>>>>>>> I'll try this on the broker connection to see if it helps:
>>>>>>>>> 
>>>>>>>>> jms.useAsyncSend=false
>>>>>>>>> 
>>>>>>>>> Alistair
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> mov eax,1
>>>>>>>>> mov ebx,0
>>>>>>>>> int 80h
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 21 Sep 2011, at 13:02, Torsten Mielke wrote:
>>>>>>>>> 
>>>>>>>>>> What is the exact broker version used on your side?
>>>>>>>>>> In case its not the latest released version, can
you try the latest version?
>>>>>>>>>> 
>>>>>>>>>> Do you set any particular headers on the Topic message
in your producer?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Sep 21, 2011, at 1:54 PM, Alistair Young wrote:
>>>>>>>>>> 
>>>>>>>>>>> I can't explain this at all. It's almost like
the opposite of reliable messaging. At times, almost 1 in 3 messages just disappears. No errors.
The KahaDB/db-*.log show no record of the message every arriving and yet the producer doesn't
get an error.
>>>>>>>>>>> 
>>>>>>>>>>> Alistair
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> mov eax,1
>>>>>>>>>>> mov ebx,0
>>>>>>>>>>> int 80h
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> http://fusesource.com
>>>>>> http://blog.garytully.com
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> http://fusesource.com
>>> http://blog.garytully.com
>> 
> 


Mime
View raw message