You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Nathanael Bruce <na...@mits.com> on 2007/03/01 22:38:27 UTC
NoSuchElementException in SinglePoolMatchAllConnectionInterceptor.internalGetConnection
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.SinglePoolMatchAllConnectionInter
ceptor.internalGetConnection(SinglePoolMatchAllConnectionInterceptor.jav
a:84)
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInter
ceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:71)
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getCo
nnection(ConnectionHandleInterceptor.java:43)
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCC
LInterceptor.java:39)
org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocat
eConnection(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/20061
1.mbox/%3cC94C22F8-0025-48B4-84CD-0EA084530C07@mac.com%3e
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.SinglePoolMatchAllConnectionInter
ceptor.internalGetConnection(SinglePoolMatchAllConnectionInterceptor.jav
a: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.)
Re: NoSuchElementException in SinglePoolMatchAllConnectionInterceptor.internalGetConnection
Posted by David Jencks <da...@yahoo.com>.
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/%3cC94C22F8-0025-48B4-84CD-0EA084530C07@mac.com%3e
>
>
>
> 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.)
>
>
>
>
>
>
>
>
>
>