psteitz commented on PR #230: URL: https://github.com/apache/commons-pool/pull/230#issuecomment-1644310926
Many thanks for the test and analysis. I will look at this in the next couple of days too. The test looks interesting as it is doing something that is not expected - invalidating an object after returning it to the pool. Generally, once you return an object to the pool, you should not reference it subsequently as it may have been handed out to another client. To check and invalidate idle instances in the pool, its best to enable testWhileIdle, enable the evictor and let the pool handle it. But there should be protection at the PooledObject level to prevent a deadklock here, so worth investigating. Is the Jedis code doing this? It would be good to open a JIRA for this issue and we should probably separate the deadlock issue (if it turns out there is one) from the use of intrinsic locks. A catchall issue to replace all intrinsic locks might make sense at this point. I agree with Gary on the smelliness of putting the lock in the PooledObject interface. An alternative might be to expose a lock() method and implement it in DefaultPooledObject using a ReentrantLock. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
