+1 for sequential failing Am Mi., 19. Jan. 2022 um 10:50 Uhr schrieb Julian Feinauer < [email protected]>:
> Hi Chris, > > excellent question (and worth discussing). > In the java pool there currently is NO automatic reconnection (lazy > connection). > I have no backup strategy there (but makes sense to have one although this > may depend on specific situations). > > I currently fail one connection at a time after their specific timeout. > > If e.g. you set the timeout for the connection request to 1 second then > you could easily have one connection failing but the next attempt working. > > So I personally would go for sequential failing when their limit is due > but I think the other alternative is fine as well. > > Julian > > Von: Christofer Dutz <[email protected]> > Datum: Mittwoch, 19. Januar 2022 um 10:21 > An: [email protected] <[email protected]> > Betreff: [DISCUSS] Behaviour of a ConnectionPool? > Hi all, > > I'm currently working on the go connection-pool. Now while in general I > would assume the functionality of a connection pool to be quite clearly > defined, there still are some special cases where I want to make sure we > consistently implement them. > > Right now, I'm implementing it so there is only one connection for one > given connection string ... we can later adjust this. Reasoning here is > that in general connections to plcs can be considered highly limited so we > won't be going much over 2 or 3 anyway. > > The thing that I'm currently working on are the edge-cases. So, what > happens if: > > > * The connection itself fails. > * Should the pool try automatically reconnecting? > * If yes, should it do it as fast as possible? > * Should there be an increasing back-off delay between attempts? > * Should there be a maximum number of retries? > * What happens to other waiting clients in case of a connection > failure? > * Do all instantly get a "connection-error"? > * Does the connection get retried for each client in the queue > independently? > > Right now, I would opt for a delay between attempts of 1s at first, the > number doubling between each attempt and giving up after 3 times and then > failing all waiting clients simultaneously. But I would make the limits > configurable in the pool (reconnectInitialDelay, reconnectMaxAttempts, > reconnectBackoffStrategy, reconnectFailureStrategy). > > I think if I run into any other situations where I'm unsure, I'll continue > this thread. > > Chris >
