Conditions under which a connection is disconnected / subscription dropped

EventStoreDB
#1

I’m connecting via client API v2.0.2 with the following settings:

let settings =

ConnectionSettings.Create()

.UseNormalConnection()

.KeepReconnecting()

.KeepRetrying()

Then subscribing to a stream and the following events are logged:

  • connection disconnected

  • connection reconnecting

  • subscription dropped, reason=connection closed, ex=connection closed

I’m not sure why the connection becomes disconnected. In the tests I’ve done, I could have multiple processes running on local machine subscribing to various streams and then one of them disconnects, while another doesn’t even if subscribed to the same stream. I can restart the subscription upon dropping, but trying to avoid this or at least deal with it at a lower level.

#2

Can you try verbose logging and see if you’re seeing heartbeat timeouts?

#3

Testing that now.

#4

It looks like it is caused by: hearbeat timeout -> close socket -> close connection -> drop subscription

The issue is that the connection reconnects, but the subscription doesn’t. Do you think it would be acceptable to add such a mechanism on top of the client? Or do you think it is better to crash to whole process and restart?

Also, in this case I had a local EventStore instance running with to processes with one subscription each. The default heartbeat timeout is 1500ms. Not sure why it would timeout. Would you advise increasing the timeout?

#5

Where are you registering your subscription? The best place to do this is likely when handling the connected event from the client - then they will resubscribe on reconnection.

James

#6

Preferable, I would like to resubscribe without affecting the subscriber, so somewhere inside the gist I sent you the other day: https://gist.github.com/eulerfx/a4a29502f673f13b6a23

There is a place where I handle the dropped event, at which point I could queue up a re-subscribe. Can I attempt a re-subscribe right after the dropped event? Or can I only do it after a successful reconnect?

#7

Did you figure out how client disconnect should be handled? I’m having the same problem with SubscribeToAll which then disconnect for some reason which I can’t figure out and I stop receiving events.

#8

I haven’t found out more detail, but in the meantime I set a timeout of 5 sec before reconnection after the dropped event.