I have a really weird issue, it might be my setup is weird, but I give it a try.
I have one service where I use two subscriptions. They both share the same underlying connection, so that should work fine. The first subscription is a catch-up subscription that makes sure our read views are in sync with the event store. The second one is a live subscription that handles all event that should be handled only when the system is live. The reasoning for this is that we only want to handle it when it happened, if the system goes back up we don’t want to retry.
Now to the problem. When I run this service in VS it seems like the live subscription randomly loses the connection against the event store. I can’t see anything in the log and it is only when I debug. If I fire up the service without debugging it works as expected.
Has anyone experienced something like this?
So its not random. If you bring up verbose logging in the client or
write out the events that happen off the subscription you will see
whats happening.
What is happening is you are hitting a breakpoint, this stops all of
your threads and prevents the client from responding to heartbeat
requests the backend sends. When this occurs the backend closes the
connection. A live only subscription will handle reconnects by default
for varying times the connection is lost, a live connection will not
(you would have to resubscribe).
In order to prevent this from happening you can either
a) handle reconnecting the live subscription the same way the catchup
subscription does though its possible to lose messages over it
b) prevent the timeouts from occurring with the debugger. To do this
in your client set a higher heartbeat timeout and use the server
option ExtTcpHeartbeatTimeout command line --ext-tcp-heartbeat-timeout
Cheers,
Greg
Thanks for an awesome reponse Greg. But did you write 100 % correct, or am I misunderstanding?
“A live only subscription will handle reconnects by default for varying times the connection is lost, a live connection will not (you would have to resubscribe).”
Did you mean the first part to be a catch up subscription handle reconnects but live subscription will not? Because the catchup subscription we have still works as expected and it uses the same connection since we want to have them in the same service.
Answer to this is just for reference, the first one is probably enough to fix my issue.
–Tomas
"Did you mean the first part to be a catch up subscription handle
reconnects but live subscription will not? Because the catchup
subscription we have still works as expected and it uses the same
connection since we want to have them in the same service."
By default yes it will handle it. The reason for the difference is it
can handle perfectly the disconnect where as a live subscription will
likely lose some messages in the process
ok. Make sense. Ended up ro “re-subscribe” again if connection drops like this:
connection.Connected += (sender, args) =>
{
connection.SubscribeToStreamAsync(eventStreamToSubscribeTo, resolveLinkTos,
(arg1, arg2) => eventAppeared(arg2), (arg1, arg2, arg3) => subscriptionDropped(arg2, arg3));
};
connection.SubscribeToStreamAsync(eventStreamToSubscribeTo, resolveLinkTos, (arg1, arg2) => eventAppeared(arg2), (arg1, arg2, arg3) => subscriptionDropped(arg2, arg3));
I think that should do it, or at least it worked to debug it now with breakpoints. Thanks!
What about using persistantsubscriptions? Then you only get one event once.
With debugging in VS its quite likely you will get it twice due to
timeouts 
its at least once semantics :
We have thought about persistentsub, but as of the moment this is good enough for us and we try to keep as simple as possible with the tools we have chosen. We might comt to a point where it makes much more sense to use persistent sub, but right now we don’t need to.
–Tomas