camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neil Thorne (work)" <neil.tho...@travelex.com>
Subject Re: Recovery in activemq
Date Thu, 06 Sep 2007 13:13:28 GMT

Sorry guys,

scratch these comments. I just read the Camel TOE section properly and I'm
using a Spring JmsTransactionManager to create transactional producers and
consumers by default:

eg.

ActiveMQConnectionFactory activeMQConnectionFactory = new
ActiveMQConnectionFactory("vm://localhost?broker.persistent=true");
        JmsTransactionManager jmsTransactionManager = new
JmsTransactionManager();
       
jmsTransactionManager.setConnectionFactory(activeMQConnectionFactory);
        JmsComponent component =
ActiveMQComponent.jmsComponentTransacted(activeMQConnectionFactory,
jmsTransactionManager);
        component.setConcurrentConsumers(1);
        camelContext.addComponent("activemq", component);

I'm also now seeing the messageIds are the same for "recovered" messages.

I still would like a neat way of finding out if this message is "recovered"
though, but both messages are the same. 

[aultMessageListenerContainer-1] ActiveMQMessageConsumer        DEBUG
Received message: MessageDispatch {commandId = 5, responseRequired = false,
consumerId = ID:J06483-2779-1189082228516-3:0:1:1, destination =
queue://test.in, message = ActiveMQObjectMessage {commandId = 6,
responseRequired = false, messageId =
ID:J06483-2779-1189082228516-3:2:1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:J06483-2779-1189082228516-3:2:1:1, destination = queue://test.in,
transactionId = TX:ID:J06483-2779-1189082228516-3:2:1, expiration = 0,
timestamp = 1189082232641, arrival = 0, correlationId = null, replyTo =
null, persistent = true, type = null, priority = 4, groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false, userID =
null, content = org.apache.activemq.util.ByteSequence@1554233,
marshalledProperties = null, dataStructure = null, redeliveryCounter = 0,
size = 1322, properties = null, readOnlyProperties = true, readOnlyBody =
true, droppable = false}, redeliveryCounter = 0}
[aultMessageListenerContainer-1] ActiveMQMessageConsumer        DEBUG
Received message: MessageDispatch {commandId = 4, responseRequired = false,
consumerId = ID:J06483-2787-1189082256703-3:0:1:1, destination =
queue://test.in, message = ActiveMQObjectMessage {commandId = 6,
responseRequired = false, messageId =
ID:J06483-2779-1189082228516-3:2:1:1:1, originalDestination = null,
originalTransactionId = null, producerId =
ID:J06483-2779-1189082228516-3:2:1:1, destination = queue://test.in,
transactionId = TX:ID:J06483-2779-1189082228516-3:2:1, expiration = 0,
timestamp = 1189082232641, arrival = 0, correlationId = null, replyTo =
null, persistent = true, type = null, priority = 4, groupID = null,
groupSequence = 0, targetConsumerId = null, compressed = false, userID =
null, content = org.apache.activemq.util.ByteSequence@1fe4169,
marshalledProperties = null, dataStructure = null, redeliveryCounter = 0,
size = 1322, properties = null, readOnlyProperties = true, readOnlyBody =
true, droppable = false}, redeliveryCounter = 0}
 
any ideas?

We're currenty thinking of going with an idempotent receiver that uses the
messageIds above.

thanks,

Neil


Neil Thorne (work) wrote:
> 
> Hi,
> 
> I need some clarification - it's maybe more at the activemq level but here
> goes...
> 
> We have a situation where we have a consumer where we don't want to
> process the same message twice. It's a legacy booking system where this
> will result in double booking the same payment.
> 
> We are trying to recreate a catastrophic failure of the camel process
> where it is using an activemq embedded broker with persistent queues. So
> "same message" here is the physical message on the bus.
> 
> We may receive another message for the same payment, but we DO want to
> process that. 
> 
> When we kill our java process, any message that is not fully processed is
> indeed recovered from activemq's journal and sent processed again.
> 
> However when we inspect the second "recovered" underlying jms message it
> has a NEW messageId.
> 
> I was expecting it to have the original messageId.
> 
> I was going to use this as a synthetic idempotency key.
> 
> I was also hoping that "recovered" messages from the journal would be
> tagged in some way ("redeliveryCounter" goes from 0 to 1?).
> 
> This would make it even easier for our system to ignore these messages.
> 
> In our case it's if in doubt, don't retry, just manually intervene. If we
> could see the message as "recovered" we could route it accordingly.
> 
> thanks for any help,
> 
> Neil
> 

-- 
View this message in context: http://www.nabble.com/Recovery-in-activemq-tf4391171s22882.html#a12522295
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message