Axon Events - Availability with RabbitMQ

Imported from Google Groups
#1

Hi,

Is there any configuration to enable ‘ack’ for the rabbitmq only after successful processing of the EventHandler (probably last eventHandler for the Event)?

Or what’s the hook-point to ‘ack’ or ‘nack’ a message ?

Scenario:

  • Server crashes when EventHandler method is in-progress

Since the message is ‘auto-acked’ by Spring-amqp, this is not available in the RabbitMQ Queue.

Axon version: 2.3.2
AMQP Cluster: RabbitMQ

These are non-saga eventHandlers. With saga-eventHandlers,is it possible to recover this scenario?

Note: We are not using Event-store or replay cluster.

Thanks,
Jebu.

#2

Just to add, the Cluster is configured as AsyncCluster.

#3

Hi,

instead if using auto-ack (the default, if no tx manager is configured), you can use an EventHandlerMonitor on your cluster to perform the acks instead. The EHM is notified after events have been successfully handled (or when a failure occurred).

Cheers,

Allard

#4

Thanks Allard.

Just to clarify, should we then define (or override) a new Cluster which implements EventProcessingMonitor and use in the axon-cluster config?

If so, how to access the ‘Channel’ to issue a ack/nack? Please share if there are any samples available.

e.g

`

#5

Hi,

no you must register a EventProcessingMonitor with the cluster actually processing the events. You define the queues that the cluster listens to yourself, so you must have access to them in your configuration. I believe the manual ack configuration is part of the ContainerListener configuration.

You must also somehow include the Rabbit ID of a message to the event message. This is the responsibility of the AMQPMessageConverter. You can probably extend the DefaultAMQPMessageConverter to include some extra meta data.

Cheers,

Allard

#6

Hello,

This thread has left me puzzled: I have had this setup for a while and never used EventProcessingMonitor. In fact many, many times we blocked the event queue because of a failing handler and have in roadmap a smarter error handling.

My guess is that you should not use the Async cluster for this, possibly it does not even make sense at all with the AMQP terminal.

I plan on releasing some code of our Axon “Boot” packages, that is various Spring @Configuration classes and some annotations, then we’ll see if there’s any good idea in there.

Cheers,
Andrea

#7

Hi,

if you use the regular cluster, which is absolutely possible, you don’t have the flexibility to handle events in a multi-threaded fashion, while still being able to guarantee order between certain events.

Looking forward to your Boot packages…

Cheers,

Allard