-
-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transient error drops the subscription. (Connection reset by peer) #307
Comments
I will accept the PR if you add this error to the list you mentioned. I am not sure that SQL error number will be 35 though. |
Look also here dotnet/SqlClient#2103 (comment), it seems that on Windows it will produce 10053, but on Linux it's impossible to figure out. |
Strangely enough, the only thing that should have happened is that the subscription would drop and resubscribe. |
I've tested again by running the app locally and stopping the SqlServer instance. I see the "Dropped" message in the logs but it doesn't resubscribe, and the health check keeps outputting "Healthy". It makes sense, as the Resubscribe() method is only called from Dropped(), which is not called when the polling connection fails. eventuous/src/SqlServer/src/Eventuous.SqlServer/Subscriptions/SqlServerSubscriptionBase.cs Lines 63 to 96 in b7352bb
It is only called from HandleInternal, and only in the case of an OperationCanceledException eventuous/src/Core/src/Eventuous.Subscriptions/EventSubscriptionWithCheckpoint.cs Lines 41 to 54 in b7352bb
|
Ah that's too bad. Thanks for looking into that! I suppose we should focus on getting the SQL subscription to resubscribe when the connection drops, that should also fix this issue? |
Looking at the ESDB AllStreamSubscription, I see that Could it be that we just need to replace Edit: it looks like this is already fixed in dev, where eventuous/src/Relational/src/Eventuous.Sql.Base/Subscriptions/SqlSubscriptionBase.cs Lines 51 to 83 in 0be1656
|
Describe the bug
We noticed that a subscription had stopped processing. We discovered that it was due to a SqlException with inner exception SocketException with message:
"A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 35 - An internal exception was caught) Unable to read data from the transport connection: Connection reset by peer. Connection reset by peer".
I believe this should be recognized as a transient error and retried, like the other error numbers listed in
eventuous/src/SqlServer/src/Eventuous.SqlServer/Subscriptions/SqlServerSubscriptionBase.cs
Line 61 in b7352bb
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The error is recognized as transient and the message is retried.
Screenshots
N/A
Desktop (please complete the following information):
Additional context
There is no additional logging because this didn't occur during the processing of a message, it was in the middle of the night and nobody was using the system. So we assume it was just a hiccup on the Azure side.
Full stack trace:
The text was updated successfully, but these errors were encountered: