Hey there,
I’ve been looking at the implementation of DisruptorCommandBus and I have a few questions; apologies if they’re obvious - I’m still ingesting everything and I’m not completely able to reason against how Disruptors work yet:
-
It’s not clear to me how the processing chain works - are all Commands sent to all CommandHandlerInvokers? If so, does that mean if a CommandHandlerInvoker that is not responsible for running the Command is busy (with another Command) that the Disruptor will need to wait for it before proceeding onto the serializing/publishing?
-
Since all Commands for a particular instance of an AR are handled by the same CommandHandlerInvoker, is it safe to say that at any given time there will be at most one thread in the AR instance? If so, I’m guessing it’s suboptimal to do I/O inside the AR (including logging?) Is there a recommended pattern to get the I/O done ahead of time?
-
The Javadocs say that the DCB will use three threads; I’m assuming that means “at minimum” and that given a larger thread pool to work and a proper number of command invoker/serializer/publisher threads that it can process more Commands in parallel?
-
If an instance of an AR can plough through Commands quickly, it can generate many Events. It looks like the Disruptor is wired up such that the Events that each Command generates are written per-Command to the EventStore. I feel like this would eventually backlog the EventStore. Is handling rollback/replay thread safe enough that if the EventStore were to actually just queue (so writes are batched) the Events to be written (and EventPublisher received an empty EventBus) that it could safely issue a rollback/etc?
I have to say, I really like what’s been done with the DCB, especially the non-trivial effort that’s gone into rollback/replay!
JAmes