DisruptorCommandBus

I want to use the DiruptorCommandBus but it’s limitation of supporting only one type of aggregateroot is a problem for me.
Are there any plans to remove that limitation?

Hi Ming,

yes, I do have plans to remove that limitation. At least, there will be another implementation that doesn’t have any functional restrictions. It probably won’t be as fast as the original, but still faster than the SimpleCommandBus. Another limitation that I want to remove in the future is the number of threads being used. Currently, it is always 3. Nowadays, multi-core machines typically means 16 cores, not 4, so having 12 threads dedicated to Command Processing shouldn’t be a problem.

Cheers,

Allard

That good to hear.
What’s your best guess when this will be done?
If it’s far off then I will have to build it myself and will probably start by reverse engineering the current one.

Hi Ming,

It’s really hard to give an indication. It is most likely not within 3 months anyway.

Cheers,

Allard

I’ve created a new implementation of CommandBus using the Disruptor.
It is based on the SimpleCommandBus and DefaultUnitOfWork.

The design consists of two EventHandlers, CommandInvoker and EventPublisher.
Unlike the “official” one, there is not prefetcher stage since it was causing problems for my app.

For concurrency, the constructor allows setting the number of CommandInvokers and EventPublishers.
At dispatch time, a meta data field is used to determine the instance of CommandInvoker and EventPublisher to use.
This meta data should be set so that all commands and eventpublishers are in the correct sequences, eg orderId.

The implementation currently does not support return values and callbacks.
Since my app does not need it I may not add support for it at all.
I will clean it up and share it in a week or so.