Single event processor on HA cluster


How to ensure that only one event subscriber will get an event in HA configuration.

Or maybe there is a technique to ensure that an event is taken already by another subscriber.

I am searching for a solution to spread event processing between several nodes.

You want competing consumers is that correct?

Yes, that's correct.

There is work under way to support competing consumers.

Szymon who is on this list has also done some work adding this to event store. I cc’ed him on this email so he can add what state he is at (I know it was working at one point and maybe he can share)

I did some work two months ago. Recently I managed to rebase it on top of current head. The code is working and I think I can push a version of it based on current develop head. Last time we talked with Greg he suggested an optimization in process of storing the state of this competing customer subscription but I haven’t manage to work on that.

One important thing is the code does not try to guarantee exactly-once delivery. It’s at-least-once by design. The client API is a draft and might need some improvement with regards to concurrency/threading. It is working but I think that one can expect and better experience with regards to customizing how the arriving events are processed (i.e. on one thread, thread pool etc)


W dniu piątek, 7 marca 2014 12:38:54 UTC+1 użytkownik Greg Young napisał:

I think, if we just could get the current node number and the total number of nodes in a cluster we could

bool isMyEvent = (eventNr % totalNodeCount) == currentNodeNumber;

if (isMyEvent) Process(event);

there could be situations with lost events, but if we could query them and rerun later that would be ok…

is this possible with ES?

2014 m. kovas 7 d., penktadienis 13:46:39 UTC+2, Szymon Pobiega rašė:

What happens if a node goes down? The main benefit of competing consumers is if you lose a node the other nodes will pick up the work of that node. In order to do this it needs to be handled on the producer side.

If you are just looking for a fan out to distribute work this would work. However I would go one step further as what happens when you add a new node? Instead I would say %32 and then tell each node what it should work on (eg each node can work on 6 numbers). Later if you want you can make each node work on 3 and have twice as many nodes.



My previous question was not very clear I think… Is there a way in ES API to get TotalNodeCount and CurrentNodeNumber?

we are working with resources when we are processing an event, and there is no way to work with it concurrently (‘It’s at-least-once by design’), so only one node will succeed to process it others will fail. But if the number of these collisions will be low it will not be a big problem. Is there a way to predict the number of these collisions?

2014 m. kovas 7 d., penktadienis 15:02:13 UTC+2, Greg Young rašė:

The nodes are exposed through gossip. Currently the client knows all of this but I don’t think we expose it. It would however be trivial to expose.

Is the area where this is handled.



Also could you be a bit more clear on what your goal is here? There may be other wways of getting there.