Catch Up Subscriptions v2.0.0

EventStoreDB
#1

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 – https://gist.github.com/Jospeh/6076881

Is there something I’m missing?

#2

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.

#3

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’ [127.0.0.1:3930, L127.0.0.1:1113, {0a3ef719-87cb-4362-a461-4f58b107e30d}] due to error. Reason: Connection queue size is too large: 50002.

Any idea?

#4

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

James

#5

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

#6

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: https://gist.github.com/Jospeh/6076881

Nothing fancy with the connection setup -> https://gist.github.com/Jospeh/6078549

#7

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.

#8

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.

Thanks,

James

#9

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.

https://gist.github.com/jen20/6092666

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

Cheers,

James

#10

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 http://xkcd.com/323/ :slight_smile: