BatchEventHandler design

[Fil Mackay]

Just wondering this wasn't reduced to a single method that provides an
array of T's, indicating a complete 'batch'? Is this a latency
killer..?

[Martin Thompson]

Good question. This is a pattern I often see implemented.

The issue I see with this approach is the usage of the array. You
have to either allocate an array for each call and copy the references
into it. If a pre-allocated array is used it would need to be the
size of the ring buffer to reflect the true size of the batch, plus
pass values to indicate the valid range in the array. Either way work
has to be done which is wasted CPU cycles that could be better used to
do other real work.

It also adds another layer of indirection for memory access that has
the potential to cause a cache miss.

Martin...

[Fil Mackay]

How many OnAvailable(T[] ...) calls would you want in-flight at a time - presumably more than one..

Of course another answer is ditch OnEndOfBatch() and have another (completely seperate) idle notification mechanism.. :)

I don't like the array either.. but I'd keep OnEndOfBatch away so I can feed the items into a sequence very easily :)

Regards, Fil.

[Olivier Deheurles]

IObserver<T> you mean ;) http://msdn.microsoft.com/fr-fr/library/dd783449.aspx

OnAvailable and OnEndOfBatch are equivalent to IObserver.OnNext with a
struct nesting the event and a flag for the end of batch
ExceptionHandler can be replaced by IObserver.OnError
LifecycleAware.OnShutdown is the equivalent of IObserver.OnComplete

The interface matches but I think the semantic behind RX does not:
- an exception (OnError) terminates the stream, this in not the case
with the disruptor
- you can not subscribe to the disruptor while it's hot: observers
would have to be setup before "starting" the disruptor, this does not
work very well with operators like retry for instance which will re-
subscribe in case of error
- lots of operators do not make sense with the disruptor or would
just not work

I'm not a RX expert but I know several people who are, let me know if
you need help to dig around RX and the disruptor..

Olivier

[Olivier Deheurles]

Oups, previous post was for IPC thread... I'll post it there...

On 11 août, 18:26, Olivier Deheurles <m...@odeheurles.com> wrote:
> IObserver<T> you mean ;)http://msdn.microsoft.com/fr-fr/library/dd783449.aspx

[mikeb01]

A large portion of the Disruptors that we use in our application site in front of I/O operations (journalling, multicast messaging) and the onAvailable(), onEndOfBatch() metaphor works really well for us.  It allows for very efficient batch over these slower boundaries, which is key for avoiding "J curve" effects under load.

However you are not restricted to using the BatchEventProcessor, you could use a ConsumerBarrier directly and build your own SingleEventProcessor with a SingleEventHandler and IdleNotificationListener interfaces.  Admittedly the ConsumerBarrier is subject to quite a high degree of change and the BatchEventHander can isolate you from that.

Mike.

[Martin Thompson]

Last night I checked in a new version of this. BatchEventHandler ->
EventHandler, and the onAvailable(Event event) -> onEvent(Event event,
boolean endOfBatch).

This allows the interface to have a single method implementation which
makes it easier for hotspot to optimised and will be better come
lambdas.

I'd like to stabilise on the new interfaces now and get a release
out. Does anyone object to new API design? The new API should make a
port to C++ more straight forward.

[Olivier Deheurles]

Hi Martin,

I applied all the changes a few days ago to the .NET version, I think the naming is way better now (I got rid of the batch prefix in all classes).

I'm still not sure about the ErrorHandler and I wonder if it should not be part of the EventHandler interface, something like onError(Exception ex, Event event, bool endOfBatch).

From a usability point of view I think it's more explicit for the developer to have to implement the error logic all the time, it's a bit to easy to forget to setup an error handler. It would as well simplify your life if you want to add a DSL-like syntax later.

Olivier

[Martin Thompson]

Hi Olivier,

We tend to use many instances of the Disruptor throughout our system.
They all tend to have very similar error handling which we like to
centralise. Therefore we create some standard error handlers and
inject them across the board.

We use tools like Freud, which we have open-sourced (http://
code.google.com/p/freud/), that enforces coding conventions on our
project so mistakes like this get caught at build time.

What issues are you seeing that could benefit from this change?

Martin...

[Olivier Deheurles]

Martin,

I've not faced any issue with the disruptor but I can see issues based
on previous experience:

Reactive Extensions framework (http://msdn.microsoft.com/en-us/data/
gg577609) has 2 core interface called IObservable<T> and IObserver<T>.
IObserver is very close from the EventHandler API.
When you subscribe to an IObservable stream you specify a callback
'OnNext' called each time you receive an event (= onEvent)
Optionally you can as well provide a callback "OnError" in case of
exception.

We are making very heavy use of this framework on the project I'm
working on and I can tell that developers tend to "forget" (read "be
lazy") and do not implement the error handling logic.

Adding an onError method to EventHandler would "force" the developer
to implement it, or at least to think about it, which is a first step
in the right direction. If you need a centralized error handling logic
you can still inject it in the handler and the onError callback just
has to call directly the error handler.

In a "pull" scenario, when you call a method you expect the method to
return or to throw. Both paths are handled at the same place in your
code.
In a "push" scenario, when an API calls on you code you may expect as
well to have the happy path and the unhappy path logic close to each
other.

This is just a suggestion and I understand there are perfectly valid
arguments for the current implementation ;-)

Olivier

[Fil Mackay]

Oliver,

Full agreement with this - what do you think of using IObserver anyway
in the .net port regardless of the Java implementation? Slightly
different semantics but we can compensate for it so it fits well with
rx..

Sent from my iPhone

[Olivier Deheurles]

I would probably try to do something on top of the disruptor and not force the user to use RX. We probably do not want as well to have any dependency on RX, a layered approach is probably better.

Olivier

[Fil Mackay]

Remember this would not create a rx dependency as IObserver etc are
defined in the BCL.. It would just provide easy access from rx or
streaminsight for that matter..

Sent from my iPhone

[Fil Mackay]

On Aug 12, 5:36 pm, Olivier Deheurles <m...@odeheurles.com> wrote:
> I applied all the changes a few days ago to the .NET version, I think the naming is way better now (I got rid of the batch prefix in all classes).
>
> I'm still not sure about the ErrorHandler and I wonder if it should not be part of the EventHandler interface, something like onError(Exception ex, Event event, bool endOfBatch).

Oliver, I can't see these changes checked in - are they still local?

Regards, Fil.

[Olivier Deheurles]

Hi Fil,

Yes I did not had time to checkin, the renaming affects 90%+ of the code base, I wanted to do a proper review before checkin. Very busy at the office atm, can't find much spare time..

Olivier