This implementation is correct given the code requirements you've stated. Best practice is to wrap your publishing code in a try-finally block to ensure that a claimed sequence is always published:
long sequence = ringBuffer.next();
try {
Event e = ringBuffer.get(sequence);
// Do some work with the event.
} finally {
ringBuffer.publish(sequence);
}
It may also be a good idea to explicitly specify in the constructor that you need a multiple-producer Disruptor, but that is already done in the default constructor you've used. You should not synchronize writes to the RingBuffer
as the process of claiming and publishing the sequence number is already thread-safe. Note however that there is no guarantee that the order in which events are published to the RingBuffer
in concurrent invocations of doPost()
will be the same as the order they're received by your web application.
The Disruptor is just a specialized queue and is therefore subject to all the usual problems they have with unbounded growth. If there are no available slots in the buffer, your call to ringBuffer.next()
will block until one becomes available. You should both provide sufficient capacity to the RingBuffer
to handle bursts of traffic, and consider ways to apply back pressure in the (hopefully rare) case that the buffer is filled.
In your particular use case, if the CodeGeneration
or CampaignSave
steps are taking a very long time compared to the first two, and can be deferred, it may make sense to use additional Disruptors/RingBuffers to queue up events for those executions.