You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The docs don't describe resubscribing after dropped subscriptions in detail, so I came up with my own solution (for simplicity's sake I'm glossing over checkpoints here):
This works very well when I start the application and restart Event Store--resubscriptions and replays are almost instant. The problem appears when I start the application while Event Store is offline. When I bring it online, the call to SubscribeToStreamAsync hangs for around 2 minutes, maxing out a CPU core and, according to VS, allocating 1.5GB over that period (it must get collected quickly because memory used remains stable), but it does succeed in the end. Resubscribing after subsequent Event Store restarts is immediate again.
To Reproduce
Steps to reproduce the behavior:
Append some events to newstream
Shut down Event Store
Run the code above and wait for a couple of seconds
Start Event Store
Wait until event IDs are printed while observing the process's CPU usage in Task Manager.
Expected behavior SubscribeToStreamAsync yields quickly when the application is started with Event Store offline and then launched.
Actual behavior SubscribeToStreamAsync takes a couple of minutes and consumes resources when the application is started with Event Store offline and then launched.
EventStore details
EventStore server version: eventstore/eventstore:21.2.0-buster-slim image
Operating system: Win 10, Ubuntu 20.04.1 via WSL2
EventStore client version (if applicable): EventStore.Client.Grpc.Streams 21.2.0
.NET runtime 5.0.7
The text was updated successfully, but these errors were encountered:
Hi @kerams and @james-allan-lloyd thanks for the detailed report, I can reproduce this on EventStoreDB 22.6.0, and the master branch for the gRPC client.
However, I'm only seeing this issue when running EventStoreDB in insecure mode in docker.
I don't see it when running EventStoreDB locally, or when I run EventStoreDB in a secure docker container.
Can you confirm this as well?
In the logs, I always see a deadline exceeded error before the client takes a long time to resubscribe, which leads me to believe that there's a timeout that's not handled correctly internally in the client.
Describe the bug
The docs don't describe resubscribing after dropped subscriptions in detail, so I came up with my own solution (for simplicity's sake I'm glossing over checkpoints here):
This works very well when I start the application and restart Event Store--resubscriptions and replays are almost instant. The problem appears when I start the application while Event Store is offline. When I bring it online, the call to
SubscribeToStreamAsync
hangs for around 2 minutes, maxing out a CPU core and, according to VS, allocating 1.5GB over that period (it must get collected quickly because memory used remains stable), but it does succeed in the end. Resubscribing after subsequent Event Store restarts is immediate again.To Reproduce
Steps to reproduce the behavior:
newstream
Expected behavior
SubscribeToStreamAsync
yields quickly when the application is started with Event Store offline and then launched.Actual behavior
SubscribeToStreamAsync
takes a couple of minutes and consumes resources when the application is started with Event Store offline and then launched.EventStore details
The text was updated successfully, but these errors were encountered: