Catch Up Subscriptions v2.0.0

Hey All,

I’ve been playing with v2.0.0 and I’m finding subscriptions are not working. Is anyone else experiencing this or is it just me ?

The code is a modified version (to compile for v2.0.0) of James’ GetEventStoreDispatcher –

Is there something I’m missing?

Ok :slight_smile: This was pretty simple - just needed to set user credentials… seems weird though, as the same client was able to write to event store without credentials.

I’m now seeing events appear in the subscription, however the subscription is getting dropped on the first event appearing…

Looking in the logs I can see the following error…

[PID:04628:007 2013.07.25 10:01:57.276 ERROR TcpConnectionManager] Closing connection ‘external-normal’ [, L127.0.0.1:1113, {0a3ef719-87cb-4362-a461-4f58b107e30d}] due to error. Reason: Connection queue size is too large: 50002.

Any idea?

Can you post of gist of how you’re setting up the EventStoreConnection?


Sounds like the events are not getting dispatched through TCP etc.
What is your code for dealing with the catchupsubscription?

The code for the catchup subscription is basically the same as james’ gist, the only change i think ive made is to the HandleSubscriptionDropped callback to be compatible with 2.0.0:

Nothing fancy with the connection setup ->

So I’ve not been able to get to the bottom of this, but I’ll try to explain what I’m seeing.

I have the catchup subscription running as a console app and a web site that appends events. When I start the console app, it will catch up to the current position as normal, but when I send a command through the website, resulting in a call to AppendToStream, the console app begins receiving this same event over and over.

I’ve reverted back to v1 now and subscriptions are working fine here.

Hi Joseph,

I’ve managed to reproduce this now - the problem is in the GetEventStoreDispatcher class (a normal catch-up subscription doesn’t exhibit the same problems).

The subscription keeps being dropped and the code currently blindly resubscribes which overflows the queues. I’ll post a version which tolerates failure better shortly.



Hi Joseph,

I’ve posted another Gist that doesn’t exhibit the same problem (here at least) - it takes a much safer approach to deserialization.

There are some notes about where it still needs improvement, but not going to look at those this evening!



Ok, after looking at your gist I spotted the issue with my code:

    private void RecoverSubscription()
        _subscription = _connection.SubscribeToAllFrom(_positionRepository.GetLastProcessedPosition(), false, HandleNewEvent, HandleSubscriptionDropped);

“HandleSubscriptionDropped” is actually handling liveProcessingStarted (i kind of wondered why the exception wasnt being passed anymore) — :expressionless:

This explains why it “appeared” that the subscription was being dropped as soon as a new “live” event appeared!

I must have past “Ballmer’s Peak” by that stage :slight_smile: