I am using axon 2.3.1 with distributed command bus and JGroups config with loadfactor of 1 Along with an interceptor for every command fired. I am doing a littie trick while firing the events and commands just for exploration purpose, i am making thread sleep in the EventHandler after applying the Event
@EventHandler
Thread.currentThread().sleep(5000);
and firing approximately 100 commands , I observed that all 100 commands altogether come on the Interceptor first and then the on the @commandHandler (Aggregate) and are fired one by one.This means that they are somewhere buffered and then sent on the gateway. Otherwise they would have directly sent on the Aggregate after the handling by the interceptor. I wanted to know
1 >Where they are buffered and what is the impact on Heap-memory in JVM if too many commands/events are buffered before firing ?
2>As in the real world scenario any major application can have load of around 10K commands in short span of time if they are made to wait what can be the consequences?
Does anyone have any idea. It would be great to know.
The SimpleCommandBus (which is used as the “local segment” of a DistributedCommandBus by default) doesn’t do any buffering. Each thread will handle the thread it dispatches. So basically, you’ll have as many “buffer” positions as you have threads.
It is recommended to use the DisruptorCommandBus if you use event sourcing. Otherwise, the AsynchronousCommandBus will also be capable of doing some buffering.
Actually I am using disruptor command bus with jgroups configuration.The issue i am facing is some of the messages that we dispatch on the command bus takes too long to processes
and some are even dropped. I am using an interceptor to know which command is being fired and doing some logging while i observed the messages are fired from interceptor but they take too long
to reach Aggregate and some are even dropped. That’s why i asked the previous question where are these messages buffered.
Note: I am already using an Interceptor. The problem i am facing is somewhere after sending the message from JChannel it takes too long to reach aggergate even some get Is there any mechanism to handle these messages after firing from interceptor before reaching the aggregate so that i can know where the messages are stuck and how some are dropped.
It would be really helpful if you can throw some light on it.
Hi Allard thanks for you valuable input,
Actually I am using disruptor command bus with jgroups configuration.The issue i am facing is some of the messages that we dispatch on the command bus takes too long to processes
and some are even dropped. I am using an interceptor to know which command is being fired and doing some logging while i observed the messages are fired from interceptor but they take too long
to reach Aggregate and some are even dropped. That’s why i asked the previous question where are these messages buffered.
Note: I am already using an Interceptor. The problem i am facing is somewhere after sending the message from JChannel it takes too long to reach aggergate even some get Is there any mechanism to handle these messages after firing from interceptor before reaching the aggregate so that i can know where the messages are stuck and how some are dropped.
It would be really helpful if you can throw some light on it.
the DistibutedCommandBus is a mechanism that connects a number of local command buses. You can configure which implementation you want to use as the “Local Segment”. By default, this is the SimpleCommandBus. So probably, the thread pool used by JGroups is depleted by threads waiting for locks. You probably want to configure a flow control protocol in your groups configuration to provide proper push-back.
Can we use “Local Segment” as DisruptorCommandBus to distributed command bus will it improve performance ? and if possible can you recommend any reliable messaging toolkit other than jgroups which can be easily integrated with Axon.
as I said in an earlier message, the DisruptorCommandBus is recommended in this situation. Axon only provides components to integrate with JGroups. Of course, you can use that code as an example to integrate with another mechanism. However, JGroups is probably reliable enough, if you configure it correctly.