Re: Bestpractice to avoid multi producer deadlock ?

144 views
Skip to first unread message

Michael Barker

unread,
Oct 7, 2012, 10:08:42 AM10/7/12
to lmax-di...@googlegroups.com
Use the EventPublisher and EventTranslator interface.

On Sun, Oct 7, 2012 at 2:30 PM, basu76 <basant...@gmail.com> wrote:
> Hello,
> I have a doubt, could some one clarify on this ?
>
> In a multi producer scenario, once a producer claims a sequence, but fails
> to publish, would other producers be blocked for ever ? From my
> understanding it does
>
> Any best practices to handle this scenario ? Something like a claim is made,
> with out timeout, and if the publish doesn't happen in that time a dummy is
> published, so that the other producers can continue ?
>
> thanks
> Basu
>
>
> --
>
>

Michael Barker

unread,
Oct 8, 2012, 3:44:33 PM10/8/12
to lmax-di...@googlegroups.com
To give a bit more clarity on this.

On Sun, Oct 7, 2012 at 2:30 PM, basu76 <basant...@gmail.com> wrote:
> Hello,
> I have a doubt, could some one clarify on this ?
>
> In a multi producer scenario, once a producer claims a sequence, but fails
> to publish, would other producers be blocked for ever ? From my
> understanding it does

Yes it does. You should endeavour to implement you code such that it
does not fail to publish. There's a couple of techniques that I've
mentioned below.

> Any best practices to handle this scenario ? Something like a claim is made,
> with out timeout, and if the publish doesn't happen in that time a dummy is
> published, so that the other producers can continue ?

The reason I mentioned the EventPublisher/EventTranslator is that they
represent the most appropriate pattern. You should to the following:

RingBuffer<Event> ringBuffer ....

long sequence = ringBuffer.next();
try {
Event event = ringBuffer.get();
// Set the data on the event
finally {
ringBuffer.publish(sequence);
}

This will ensure that the sequence is alway published. You should
make sure the the code that puts the data onto the event is just a
simple data translation and doesn't do anything that is likely to
throw an exception, e.g. I/O. One of the gotchas with this approach
is that if you do happen to throw an exception (e.g.
NullPointerException) is that you could end up with a corrupt message
being passed to your handler. To counter this problem we do the
following in some cases:

long sequence = ringBuffer.next();
try {
Event event = ringBuffer.get();
event.isValid(false);
// set the data
event.isValid(true);
finally {
ringBuffer.publish(sequence);
}

Then the EventHandler can do:

public void handleEvent(long sequence, Event e, boolean isEndOfBatch) {
// Discard invalid events.
if (!event.isValid()) {
return;
}

// Process the event.
}

Mike.
Reply all
Reply to author
Forward
0 new messages