Using Disruptor-net With WCF – Part 2

This is in continuation to my earlier post of using Disruptor-net with WCF. I have attempted to try out the Disruptor-net v1.1.0.

I have renamed the classes from my previous example to suit the naming convention of the Disruptor-net v1.1.0 (Port of the Java Disruptor 2.7.1). Events are published by Publishers and consumed by a Consumer.

The Events (of type Event) are Binary serilialized using ProtoBufNet and publised by multiple WCF Clients (EventPublisher) to an WCF Service (EventService) over NetNamedPipeBinding (This can be replaced with other types of Bindings based on the need).

The Consumer consists of the Disruptor, setup to invoke a chain of EventHandlers in a Diamond Path configuration. The DiamondPathEventHandlingSequencer is a simple DSL based class that encapsulates the setting of the Disruptor for a Diamond Path event handling sequence. The RingBuffer is filled up with instances of type ISequencerEntry. This interface provides methods for the IEventHandlers to read and write state of the Event as it traverses through the Diamond Path event handling Sequence.

Three event handlers are hooked up using the Disruptor in a Diamond Path Configuration. They resemble the architecture of LMAX explained here. They are the Journaler, UnMarshaller and Business Logic Processor. To keep the example simple I have not included the Replicator.

The EventJournaler journals all incoming events to a persistant store provided by Redis.

The EventAssembler deserialises the incoming Binary stream and writes the assembled Event instance back to the RingBuffer.

The EventTracker plays the role of the Business Logic Processor. In the context of this example, it just reference counts the number of events coming from each EventSource.

The above 3 handlers are setup inside the EventSequencer, a singleton wrapper over the DiamondPathEventHandlingSequencer.

The EventService publishes the incoming events to the EventSequencer, which internally is publised to the RingBuffer through the DiamondPathEventHandlingSequencer. Subsequently the RingBuffer takes care of invoking the Event Handlers in the appropriate sequence.

I also ran a few simple tests on my laptop, a Core i7 2.20GHz machine with 4GB memory. Below are the results.

A very trivial inference is that the Throughput of the Consumer almost equals to that of the Publiser, when there is minimal latency in the Event Handling path. So Distruptor does its job of sequencing the events across threads in an most effective way without incurring a lock over head.

The source is available here. The Code is self explanatory. It has two parts, a Publisher and Consumer. Ensure that the Consumer is started before running the Publiser.

This had been my second adventure with Disruptor, so any feedback on incorrect or better usage of the Disruptor would be much appreciated.

About these ads

2 thoughts on “Using Disruptor-net With WCF – Part 2

  1. Just wanted to say, it’s been very useful. Would be great to hear any further experience you’ve had with Disruptor. Some anecdotes from real life application will be even better.
    Thanks anyways for your posts so far.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s