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 10:36:40 GMT
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