Is it not possible to reopen a ClientApi Eventstore Connection, after it has been .Close()'d ?
If I attempt to call ConnectAsync() after a .Close(),
I’m greeted by ObjectDisposedException.
I am aware that Dispose() calls Close(), but that wouldn’t by itself mean that Close() also implies Dispose…?
I am aware that I could just recreate a fresh connection,
but that has a lot of implications for things that refer to the original connection, e.g. handlers.
Are you sure you need to close it? Typically IEventStoreConnection is singleton WRT the lifetime of your application.
https://eventstore.org/docs/dotnet-api/connecting-to-a-server/
The situation/scenario is catastrophic.
When our systems overload, we get all 10 reconnection attempts exhausted.
Thus the connection closes itself.
From this outset, I would like to reconnect, ‘once it’s safe again’.
It only makes sense to re-attempt reconnect after a significant timeout (say, 5, 10, 30 seconds).
But to the extent the connection is disposed, I must
(1) let all users/clients access it though an accessor method, and
(2) hook up all event routing again, to another instance, instead of all the things tied to the now dead connection
(which sundry bits and pieces have found through dependency injection.)
It would be much preferable, if I could avoid having to replace the existing instance.
You might try KeepReconnecting() on the ConnectionSettingsBuilder
Thanks - I’ve considered it, but decline,
since our application servers are flooding our eventstores with connection-attempts during breakdowns,
such that our ‘connection close reason’ is ‘failed to establish connection/server refused’.
The point is, I do not want to reconnect aggressively,
since this appears to contribute to the extent of our crashes.
how many application servers do you have? and how many connections per server?
It would be pretty trivial (as in about an hour) to offer a back off strategy to the connection (also allowing custom back offs). Would this solve your needs?
If so I will have it in by the end of the week.
about 5 servers with ~100 apps each.
The eventstores live on 3-4 other servers, which host ~5 eventstore instances each (all single-cluster).
An eventstore instance may have between 30-100 applications on it (single connection with 7-10 subscriptions).
@Greg: thank you for the proposal.
Though it might help us, I share your earlier thought “something else/underlying must/might be the problem”.
As such, I consider this an experiment to learn further about what is wrong
I currently have a local prototype we’ll be testing, where I implement a ‘turtle’ mode
While doing so, the app server temporarily refuses to take on new write requests
(this is not ideal, but much preferable to 10-20 minutes of breakdown, and semi-feasible for our usecase.)
Based on what we learn, we might be very interested in the back-off feature.
However, we might instead learn what we are doing wrong…
Cheers, Jakob.
This was years ago so take it with a grain of salt, but I believe I heard that once you get up to 50 tcp connections it’s time to reconsider. Would it be possible to pool connections between the apps? Alternatively, you could switch over to the http client.