Fail fast when reading/writing and keep retrying when handling subscriptions

[Darién Narváez]

Is it posible to use the same connection to fail fast when reading/writing and at the same time keep retrying forever when handling events from a subscription? The recommended pattern is to use just a single connection per app.

[Greg Young]

No because a catch up subscription might be reading as well. Using 2
connections is totally fine. The advice is more don't do using(var
conn = new EventStoreConnection(...))

> --
> You received this message because you are subscribed to the Google Groups
> "Event Store" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to event-store...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Studying for the Turing test

[Darién Narváez]

If I should not do using(var con = new ...), how can I fail fast without the need to create a whole new connection? 

[Greg Young]

you still make a new connection ^^^ was talking about a connection per request.

[Darién Narváez]

What about 

1. A lot of Concurrent requests using the same connection

2. The network is down, all requests fails at the same time

3. All requests then attempts to create a new connection at the same time to replace the old one (that is what happens to me)

4. All attemps succeeds... but is not that a waste of resources?

[Peter Hageus]

I have a single connection per role/context, with synchronised access. It’s not ‘handed out’ until it’s connected. Might be some contention there but with our load it’s not a problem at all…

/Peter

[Greg Young]

You don't seem to be understanding. You should *NOT* be using a
connection/request.

Use a connection. All operations on it are async. If operations fail
reconnect it. Operations can decide if they want to retry or not.

[Darién Narváez]

Im sorry for misunderstanding. What happens to me is that I have a connection that keeps reconnecting forever, so, when I try to read/write it NEVER fails. I dont want to disable the reconnection feature, I just want the operation to fail to let the user decide what to do, but, in the meantime let the reconnection stuff do its work to recover the lost connection, so when the user decide to try again, it will succeed

[Greg Young]

You can do this on your own.

[Greg Young]

btw there is also a retry count setting but this only applies for
actual retries (eg if network is down it won't count them)

[Darién Narváez]

Thanks Greg. I just did not wanted to write my own "framework" around Event Store. I can see why SqlConnection has a connection pool to handle this kind of problems

[Greg Young]

Connection handles most of the cases. The reason connection pool
exists has little to do with the opening/closing of connections, it is
because operations on the connection are synchronous (eg req/resp). ES
connections are async + bidirectional which removes the need of a
connection pool.

As for writing a "framework" its < 10 lines of code?! not sure how you
would consider this a framework. Set the retry count to 0 and on
connection closed try to make a new one. You get fail fast behaviour
(first failure results in exceptions to callers, you can control back
off etc, and your callers can determine their retry strategies)

[Darién Narváez]

Thanks Greg! That is the answer I wanted to get :)