On 11/16/2017 5:21 PM, Phil Steitz wrote: > That should not be possible, as once a connection has been checked > out, it is not eligible for eviction. And even if it were evicted > by the pool, the pool would set the DelegatingConnection's closed > property to true so isValid would return false rather than > throwing. It looks like the situation here is that the pool thinks > the connection is open, but the underlying physical connection has > been closed.
I am very glad to hear you describe the intended operation this way -- the gist of which seems to say that when getConnection is called, it *should* immediately mark that connection as ineligible for eviction. My current suspicion is that there is a bug, where getConnection isn't marking the connection as ineligible like it should, or maybe where there is insufficient synchronization to prevent the eviction thread from closing/evicting the connection before getConnection *does* mark the connection as ineligible. This is just a theory, but it does fit what I've seen. I have tried to investigate the code, but the project has used object inheritance and abstraction very effectively, which makes it difficult for me to follow exactly what the code is doing, because I am not familiar with all of that inheritance. I am not aware of any way for one thread in my code to close a connection obtained by another thread. My design intent is to ensure that this is completely impossible, by handling the full lifecycle of a connection in one thread and never passing connections between threads. I am not aware of any places in the program that violate this design intent ... but I've written plenty of bugs in my time, so it's always possible that I *have* made a mistake like that. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
