Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 96531 invoked from network); 4 Mar 2007 18:12:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2007 18:12:33 -0000 Received: (qmail 10267 invoked by uid 500); 4 Mar 2007 18:12:35 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 10258 invoked by uid 500); 4 Mar 2007 18:12:35 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 10247 invoked by uid 99); 4 Mar 2007 18:12:35 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Mar 2007 10:12:35 -0800 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=FORGED_YAHOO_RCVD,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [205.152.59.72] (HELO imf24aec.mail.bellsouth.net) (205.152.59.72) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Mar 2007 10:12:25 -0800 Received: from ibm68aec.bellsouth.net ([74.237.109.96]) by imf24aec.mail.bellsouth.net with ESMTP id <20070304181203.RRGJ22485.imf24aec.mail.bellsouth.net@ibm68aec.bellsouth.net> for ; Sun, 4 Mar 2007 13:12:03 -0500 Received: from [192.168.1.101] (really [74.237.109.96]) by ibm68aec.bellsouth.net with ESMTP id <20070304181202.EULH29772.ibm68aec.bellsouth.net@[192.168.1.101]> for ; Sun, 4 Mar 2007 13:12:02 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7A683E3E2BB57A46B9B3D1D65434DA83180F39@karona.miti> References: <7A683E3E2BB57A46B9B3D1D65434DA83180F39@karona.miti> Content-Type: multipart/alternative; boundary=Apple-Mail-4--696291521 Message-Id: <38B68213-998F-492F-9649-AA0928A11717@yahoo.com> From: David Jencks Subject: Re: NoSuchElementException in SinglePoolMatchAllConnectionInterceptor.internalGetConnection Date: Sun, 4 Mar 2007 13:12:00 -0500 To: user@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-4--696291521 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Could you please open a jira on this problem? I'm worried about your proposed fix since it seems to me that if we =20 don't have enough locking/synchronization on this side then removing =20 idle connections could also break the other side where we are trying =20 to get a connection from the pool to use it. I'd rather figure out =20 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 =20 > internally. Sporadically I seem to get the following exception =20 > 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) > =20 > org.apache.geronimo.connector.outbound.SinglePoolMatchAllConnectionInt=20= > erceptor.internalGetConnection=20 > (SinglePoolMatchAllConnectionInterceptor.java:84) > =20 > org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInt=20= > erceptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:=20= > 71) > =20 > org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.get=20= > Connection(ConnectionHandleInterceptor.java:43) > =20 > org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection=20= > (TCCLInterceptor.java:39) > =20 > org.apache.geronimo.connector.outbound.AbstractConnectionManager.alloc=20= > ateConnection(AbstractConnectionManager.java:57) > > > The exception usually happens once every 30 minutes in a controlled =20= > environment with only two max connections. Increasing the maximum =20 > connection count seems to diminish this exception greatly. Also, =20 > the exception usually happens after filling the pool, waiting a =20 > little while, and then hitting the connection a couple more times. > > > > After searching the mailing list I found another person who is =20 > having the same type of exception in the same location, but no one =20 > has responded to his message. The name of the message is =20 > =93NoSuchElementException when using JCAFlow=94 and can be found here: > > http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/=20 > 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 =20 > code, but=85) > > > > After looking at the code: > > > > org.apache.geronimo.connector.outbound.SinglePoolMatchAllConnectionInt=20= > erceptor.internalGetConnection=20 > (SinglePoolMatchAllConnectionInterceptor.java:84) > > 82 : if (connectionCount =3D=3D maxSize) { > 83 : Iterator iterator =3D pool.entrySet().iterator(); > 84 : ManagedConnectionInfo kill =3D (ManagedConnectionInfo) =20 > ((Map.Entry) iterator.next()).getValue(); > 85 : iterator.remove(); > 86 : ConnectionInfo killInfo =3D new ConnectionInfo(kill); > 87 : internalReturn(killInfo, ConnectionReturnAction.DESTROY); > 88 : } > > I am wondering if there is a possible race condition between the if =20= > check on line 82 and the call to iterator.next() on line 84. In =20 > between those two lines all of the connections in the pool could be =20= > destroyed? (Note: This is just a wild guess without studying the =20 > code closely.) If this is the case then shouldn=92t a simply catching =20= > of the NoSuchElementException fix this? (I presume that if the pool =20= > is empty at this point then everything is okay.) > > > > > > > > > > --Apple-Mail-4--696291521 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 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.=A0 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.=A0 Sporadically I seem to get the following = exception after calling allocateConnection:=A0=A0=A0=A0=A0=A0=A0 = java.util.HashMap$HashIterator.nextEntry(Unknown Source)

=A0=A0=A0=A0=A0=A0=A0 =
java.util.HashMap$EntryIterator.next(Unknown Source)
=A0=A0=A0=A0=A0=A0=A0 =
java.util.HashMap$EntryIterator.next(Unknown Source)
=A0=A0=A0=A0=A0=A0=A0 =
org.apache.geronimo.connector.outbound.SinglePoolMatchAllConnectionInterce=
ptor.internalGetConnection(SinglePoolMatchAllConnectionInterceptor.java:84=
)
=A0=A0=A0=A0=A0=A0=A0 =
org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterce=
ptor.getConnection(AbstractSinglePoolConnectionInterceptor.java:71)=

=A0=A0=A0=A0=A0=A0=A0 =
org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.getConn=
ection(ConnectionHandleInterceptor.java:43)
=A0=A0=A0=A0=A0=A0=A0 =
org.apache.geronimo.connector.outbound.TCCLInterceptor.getConnection(TCCLI=
nterceptor.java:39)
=A0=A0=A0=A0=A0=A0=A0 =
org.apache.geronimo.connector.outbound.AbstractConnectionManager.allocateC=
onnection(AbstractConnectionManager.java:57)

The exception usually happens once every 30 minutes = in a controlled environment with only two max connections.=A0 Increasing = the maximum connection count seems to diminish this exception greatly.=A0 = 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.=A0 The name of the message is = =93NoSuchElementException when using JCAFlow=94 and can be found = here:http://ma= il-archives.apache.org/mod_mbox/geronimo-servicemix-users/200611.mbox/%3cC= 94C22F8-0025-48B4-84CD-0EA084530C07@mac.com%3eI 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=85)

=A0

After looking at the code:

82 :=A0=A0=A0=A0=A0=A0=A0 if =
(connectionCount =3D=3D maxSize) {83 :=A0=A0=A0=A0=A0=A0=A0 Iterator iterator =3D =
pool.entrySet().iterator();84 :=A0=A0=A0=A0=A0=A0=A0 ManagedConnectionInfo kill =3D =
(ManagedConnectionInfo) ((Map.Entry) =
iterator.next()).getValue();85 :=A0=A0=A0=A0=A0=A0=A0 iterator.remove();
86 :=A0=A0=A0=A0=A0=A0=A0 ConnectionInfo killInfo =3D new =
ConnectionInfo(kill);
87 :=A0=A0=A0=A0=A0=A0=A0 internalReturn(killInfo, =
ConnectionReturnAction.DESTROY);88 :=A0=A0=A0=A0=A0=A0=A0 }=A0

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.=A0 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=92t a simply catching of the NoSuchElementException fix this? (I = presume that if the pool is empty at this point then everything is = okay.)

=A0

=A0

=A0



= --Apple-Mail-4--696291521--