Thread deadlock issue in GenericKeyedObjectPool borrowObject()

• Key: POOL-146
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: bhupesh bansal
• Affects Version/s: 1.5, 1.5.1
• Fix Version/s: 1.5.2

Description

I am a new user of common-pools and I was having some weird behavior with GenericKeyedObjectPool

GenericKeyedObjectPool: 1074:1077

public Object borrowObject(Object key) throws Exception {
long starttime = System.currentTimeMillis();
Latch latch = new Latch(key); ---> This object is tried to be used for managing pool size by calling wait()/notify()

My thinking is this should be a shared/global object and not created new for each call ??

Comments

[Phil Steitz]

Can you be more specific on the "weird behavior" you are observing?

[bhupesh bansal]

sure,

I am using it as a Socket pool with the KeyedPoolableObjectFactory as a socketFactory which returns a socket for each makeObject() call
and close the socket in destroyObject()

The Test scenario which causes issue is this:
Client --> socket call to server A and B (B is slow in freeing up resource where A is fast to free)

Common-Pools-1.5.1 : both A and B start throwing NoSuchElementException
Common-Pools-1.4 : only A throws NoSuchElementException and B keeps allocating resource.

I am trying to write a test case for the same will attach it once m done.

Best
Bhupesh

[bhupesh bansal]

Correction : A is slow in freeing up resource where B is fast (not vice-versa as mentioned last time)

[Mark Thomas]

Am I correct in thinking that your have a single pool of sockets that clients use to connect to either Server A or Server B?

[bhupesh bansal]

Yes...

they share the same socket pool (GenericKeyedObjectPool) keyed on nodeId for server A /B.

my understanding is threads blocked on Key A (slow server) should not cause thread blocking for Key B ?? Is this assumption correct.

[Mark Thomas]

OK, now I understand.

That is a bug although making the Latch object global is not the way to address this. I have added a test case and am working on a patch.

[Mark Thomas]

This has now been fixed. Many thanks for the report.

[bhupesh bansal]

Many Thanks Mark,

Can you attach the patch to this bug ?? I would like to see the fix I spent considerable time looking into the commons-pools code base and couldn't find the issue and yes global Latch was not a solution I understood after looking into the code later.

BTW have you looked into ArrayBlockingQueue from java 1.5.0 onwards in their concurrent package ?? I was thinking using that would clean up the code a lot ?

[Mark Thomas]

Use the "Subversion commits" tab to see the changes related to this bug.

Utilising JDK 1.5 features is one of the considerations for the Pool 2.x series. There was a thread on the commons dev list about this not that long ago.

[Paul Lindner]

Regarding ArrayBlockingQueue there is always backport-util-concurrent, seems like a logical step to me if 1.4 compatibility is desired..