Hi,
When I connect to a persistent subscription and I’m debugging something, the connection often drops (due to missing hearbeats) and the subscription isnt reconnected. I see that the EventStoreConnection is reconnected, but not the actual subscription unless I connect to it again.
I think this is wrong, unless the user explicitly Stops a PersistentSubscription, the underlying EventStoreConnection should keep trying to reconnect to all previously connected persistent subscriptions. What’s the recommended approach for this?
"When I connect to a persistent subscription and I'm debugging
something, the connection often drops (due to missing hearbeats) and
the subscription isnt reconnected. I see that the EventStoreConnection
is reconnected, but not the actual subscription unless I connect to it
again."
There are options to avoid this. Set high timeouts via config/command
line and set high timeouts on your connection when debugging. The
debugger stops all threads when at a break point preventing heartbeats
from being responded to.
"II think this is wrong, unless the user explicitly Stops a
PersistentSubscription, the underlying EventStoreConnection should
keep trying to reconnect to all previously connected persistent
subscriptions. What's the recommended approach for this? "
You have a dropped event off the subscription. Call connect after.
Reconnecting logic is specific to your connection (not all connections
reconnect).
I could call connect on the Dropped event, but that isn’t so simple nor robust. How should I handle max reconnect attempts? And what if it fails to reconnect at that time due no connectivity? The dropped event won’t be called again,
so I probably need the reconnect logic to be done in background. So effectively I need a timer watching for subscription connection statuses and making sure I’m always connected or at least trying to connect in a reliable way.
So if my service happens to be without network connectivity for a period longer than the heartbeat timeout, I need to explicitly prevent this situation for persistent subscriptions, but not for the EventStoreConnection itself because that one does reconnect. That’s why I was saying this should be done as part of the already existing EventStoreConnection reconnect logic.
"I could call connect on the Dropped event, but that isn't so simple
nor robust. How should I handle max reconnect attempts?"
Your connection is doing this ... connecting to a persistent
subscription will return you a failure if it fails. Its just saying
"this persistent subscription you have is no longer valid feel free to
make a new one if you want"
From the servers perspective PersistentSubscriptions are transient.
When your subscription is gone its already killed your connection to
the subscription and moved all the messages you were working on back
to be processed by other connections to the subscription.
Greg