Disposed connection not reconnecting

EventStoreDB
1

I’ve read many older posts about this same issue, all of which recommend exactly what we are already doing with our EventStore connection. We have a singleton connection in our container and if we lose the EventStore connection, the connection never reconnects. Maybe I am completely misunderstanding how this works?

var settingsBuilder = ConnectionSettings.Create()
.KeepReconnecting()
.FailOnNoServerResponse();

var connection = EventStoreConnection.Create(config.ConnectionString, settingsBuilder);
await connection.ConnectAsync().ConfigureAwait(false);

``

I have recently upgraded the client to 5.0.1 (from the now-obsolete NetCore version) because I saw there was an issue fixed associated with using both KeepReconnecting and FailOnNoServerResponse. I also tried using only KeepReconnecting and got basically the same behaviour. Our server is running 4.1.1.0.

Are we using this incorrectly?

Thanks

2

Perhaps you’re using clustered mode and need a KeepDiscovering() ?
This code isnt C# but you may find it useful for reference: https://github.com/jet/equinox/blob/master/src/Equinox.EventStore/EventStore.fs
Either way, the answer lies in turning on logging - it’ll log as it tries/succeeds/gives up on reconnecting etc…

–Ruben

3

Thanks for the suggestions. We are using clustered mode in some environments, so I’ll be sure to add that option.

As it turns out, we had some settings also configured in the connection string, which seems to override the code settings, so once I figured that out, it started to work as expected.

4

I spoke too soon. I had it work once the way I want it to (fail when the server is down, reconnect once the server is back online). Then it went back to not failing. The reconnect works fine.

My connection string has the following options:

MaxReconnections=2147483647;FailOnNoServerResponse=True

``

I have played around various other timeout parameters but could not get the request to fail. The logs show the connection being reattempted indefinitely.

“message”: “EventStoreConnection ‘ES-a0da4eda-9b7d-410f-9918-338be5ae39b1’: closing TCP connection [127.0.0.1:1113, 127.0.0.1:65254, b218921e-1e21-43e6-9741-35af085f5e4c] due to HEARTBEAT TIMEOUT at pkgNum 0.”,

“message”: “ClientAPI TcpConnection closed [20:42:01.828: N127.0.0.1:1113, L127.0.0.1:65254, {b218921e-1e21-43e6-9741-35af085f5e4c}]:”,

“message”: “Received bytes: 0, Sent bytes: 59”,

“message”: “Send calls: 2, callbacks: 2”,

“message”: “Receive calls: 1, callbacks: 0”,

“message”: “Close reason: [Success] EventStoreConnection ‘ES-a0da4eda-9b7d-410f-9918-338be5ae39b1’: closing TCP connection [127.0.0.1:1113, 127.0.0.1:65254, b218921e-1e21-43e6-9741-35af085f5e4c] due to HEARTBEAT TIMEOUT at pkgNum 0.”,

“message”: “TcpPackageConnection: connection [127.0.0.1:1113, L127.0.0.1:65254, {b218921e-1e21-43e6-9741-35af085f5e4c}] was closed cleanly.”,

“message”: “TcpPackageConnection: connected to [127.0.0.1:1113, L127.0.0.1:65260, {e1ce2034-3427-46cb-a836-5f532532cee8}].”,

``

5

Turns out “docker pause” gives inconsistent results as a simulation for outage. After switching to “docker stop” the reconnect and failure behaviour is as expected.