Could you please open a jira on this problem?
I'm worried about your proposed fix since it seems to me that if we
don't have enough locking/synchronization on this side then removing
idle connections could also break the other side where we are trying
to get a connection from the pool to use it. I'd rather figure out
how to have enough locking so there are no more race conditions.
thanks
david jencks
On Mar 1, 2007, at 4:38 PM, Nathanael Bruce wrote:
Hi,
I am using Jencks-1.1.3 which uses the Geronimo connector
internally. Sporadically I seem to get the following exception
after calling allocateConnection:
java.util.NoSuchElementException
java.util.HashMap$HashIterator.nextEntry(Unknown Source)
java.util.HashMap$EntryIterator.next(Unknown Source)
java.util.HashMap$EntryIterator.next(Unknown Source)
org.apache.geronimo.connector.outbound.SinglePoolMatchAllConnectionInt
erceptor.internalGetConnection
(SinglePoolMatchAllConnectionInterceptor.java:84)
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt
erceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:
71)
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get
Connection(ConnectionHandleInterceptor.java:43)
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection
(TCCLInterceptor.java:39)
org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc
ateConnection(AbstractConnectionManager.java:57)
The exception usually happens once every 30 minutes in a controlled
environment with only two max connections. Increasing the maximum
connection count seems to diminish this exception greatly. Also,
the exception usually happens after filling the pool, waiting a
little while, and then hitting the connection a couple more times.
After searching the mailing list I found another person who is
having the same type of exception in the same location, but no one
has responded to his message. The name of the message is
“NoSuchElementException when using JCAFlow” and can be found here:
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/
200611.mbox/[EMAIL PROTECTED]
I can not find any issue relating to this in JIRA.
(I am not sure if this is the write list to be talking about the
code, but…)
After looking at the code:
org.apache.geronimo.connector.outbound.SinglePoolMatchAllConnectionInt
erceptor.internalGetConnection
(SinglePoolMatchAllConnectionInterceptor.java:84)
82 : if (connectionCount == maxSize) {
83 : Iterator iterator = pool.entrySet().iterator();
84 : ManagedConnectionInfo kill = (ManagedConnectionInfo)
((Map.Entry) iterator.next()).getValue();
85 : iterator.remove();
86 : ConnectionInfo killInfo = new ConnectionInfo(kill);
87 : internalReturn(killInfo, ConnectionReturnAction.DESTROY);
88 : }
I am wondering if there is a possible race condition between the if
check on line 82 and the call to iterator.next() on line 84. In
between those two lines all of the connections in the pool could be
destroyed? (Note: This is just a wild guess without studying the
code closely.) If this is the case then shouldn’t a simply catching
of the NoSuchElementException fix this? (I presume that if the pool
is empty at this point then everything is okay.)
