--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
June 30, 2015 at 8:48 AM
We've been using Sagas and Quartz to schedule jobs for integration with external systems. I agree with you and Allard: this is more natural if there's some relation to your domain.Quartz is a pretty heavy-weight framework. It works pretty well for big, slow jobs, not so well if you have thousands of small, quick jobs. Also, if you use DistributedCommandBus, beware that Quartz will happily fire its trigger on any of the servers in your cluster (randomly), not necessarily the same one that originally processed the saga. So you either have to turn off saga caching (performance hit), or make your Quartz-triggered event trigger a command, just to be routed to the correct server, to trigger the "real" event, to trigger the saga to do the work -- pretty ugly. (I understand distributed sagas are a very hard problem in general.)I personally would prefer your messaging option if it would work for you, despite your concerns. However I think I would make an event handler send the message directly rather than using a distributed event bus terminal. Your MQ system will take care of the queueing, durability, delivery, batching, and gives you some tools to retry after errors. You could run ActiveMQ embedded in your app if you don't like the idea of setting up RabbitMQ; this is comparable to running Quartz. ActiveMQ even has distributed and discovery capabilities. Axon can't integrate the EventBus directly with ActiveMQ out of the box, but that's OK if you roll your own message publisher as I suggested. Saga + Quartz could be a more natural fit if each job must be stateful and integrates tightly with your Axon aggregates. But integration through messaging is a tried and true method.
--
You received this message because you are subscribed to a topic in the Google Groups "Axon Framework Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/axonframework/nvEmLb4wsn8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to axonframewor...@googlegroups.com.
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
Hi Steven,
event handlers (the beans, not the aggregate) can do anything they need to. It is, however, bad practice to combine both state updating handlers and those communicating with external components in the same cluster. In a replay, you generally don't want to invoke all these external components again.Cheers,Allard
On Tue, Jun 30, 2015 at 7:05 PM Steven Grimm <kor...@midwinter.com> wrote:
Thanks for the advice. One point of confusion I have about your suggestion: I thought it was generally considered bad practice to perform actions in event handlers (other than updating internal data structures) because then you lose the ability to replay the event stream if you need to generate a new view of your data to run queries against. How would you deal with that? The obvious solution that comes to mind is to set an "I'm doing a replay" flag that the event handler checks before sending its message to the external service.
-Steve
<compose-unknown-contact.jpg>
June 30, 2015 at 8:48 AM
We've been using Sagas and Quartz to schedule jobs for integration with external systems. I agree with you and Allard: this is more natural if there's some relation to your domain.Quartz is a pretty heavy-weight framework. It works pretty well for big, slow jobs, not so well if you have thousands of small, quick jobs. Also, if you use DistributedCommandBus, beware that Quartz will happily fire its trigger on any of the servers in your cluster (randomly), not necessarily the same one that originally processed the saga. So you either have to turn off saga caching (performance hit), or make your Quartz-triggered event trigger a command, just to be routed to the correct server, to trigger the "real" event, to trigger the saga to do the work -- pretty ugly. (I understand distributed sagas are a very hard problem in general.)I personally would prefer your messaging option if it would work for you, despite your concerns. However I think I would make an event handler send the message directly rather than using a distributed event bus terminal. Your MQ system will take care of the queueing, durability, delivery, batching, and gives you some tools to retry after errors. You could run ActiveMQ embedded in your app if you don't like the idea of setting up RabbitMQ; this is comparable to running Quartz. ActiveMQ even has distributed and discovery capabilities. Axon can't integrate the EventBus directly with ActiveMQ out of the box, but that's OK if you roll your own message publisher as I suggested. Saga + Quartz could be a more natural fit if each job must be stateful and integrates tightly with your Axon aggregates. But integration through messaging is a tried and true method.--
You received this message because you are subscribed to a topic in the Google Groups "Axon Framework Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/axonframework/nvEmLb4wsn8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to axonframewor...@googlegroups.com.--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.