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.yo...@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.yo...@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
>
