geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Getting "Deque Full" error on Connection.close()
Date Wed, 30 Jul 2008 07:41:08 GMT

On Jul 29, 2008, at 11:17 PM, Andrew Thorburn wrote:

> I would *never* have thought to look there for the current connector
> code. How does txmanager relate?

Some other projects were using our transaction manager and connector  
code so we moved it to a "component" that doesn't include the geronimo  
specific service management code.  Tx manager and connection  
management are very closely related.... the tx manager basically only  
works with connections.

> Anyway, that suggests that my problem
> is fixed thanks to your change to an ArrayList and the removal of any
> sort of length checking on the doAdd method (which I assume replaces
> the PoolDeqeue.add method?). I'll recommend upgrading to 2.1.1 to fix
> that problem. The joys of OpenSource! :D

Did you see any connection errors in the logs?  The bug whose fix  
prompted the switch to ArrayList involved bad handling of connection  
errors.  I didn't think it would have been present in 1.1.1 but you  
never know until something goes wrong.

Please let us know if 2.1.1 fixes the problem.

david jencks

> Thanks a lot,
> - Andrew Thorburn
> On Wed, Jul 30, 2008 at 5:55 PM, Kevan Miller  
> <> wrote:
>> On Jul 29, 2008, at 7:42 PM, Andrew Thorburn wrote:
>>> This is a bit strange - I seem to be getting a Deque Full error  
>>> when I
>>> try and close a connection. It doesn't happen all the time, and I  
>>> only
>>> just saw it for the first time a few days ago (in production...),  
>>> and
>>> bouncing Geronimo (stop/start) seemed to fix it. I can understand  
>>> why
>>> it might happen when I try to get a connection, but it shouldn't be
>>> happening when I try and close one, surely? Doesn't seem terribly
>>> logical.
>>> Anyway, this occurred on Geronimo 1.1.1 while connected to a DB2
>>> database, and the stack trace follows. I've replaced the names of  
>>> the
>>> classes we've written my MYCLASS_*, just to be on the safe side with
>>> regards to confidentiality policies and whatnot.
>>> My initial thought is that it's maybe a threading issue? If Thread A
>>> tries to close a connection, but gets interrupted part-way through  
>>> by
>>> Thread B, which creates a connection, is that a potential way for  
>>> this
>>> to happen?  Also, is it likely to have been fixed in a later version
>>> of Geronimo? Given how much trouble I've had finding
>>> "SinglePoolConnectionInterceptor", I'd say it's at least moved
>>> somewhere else...
>>> Anyway, I've been told to find an answer today, and I guess I'm just
>>> posting this in the hope that I'll get lucky and someone will answer
>>> :).
>> Hi Andrew,
>> I don't recall this specific problem, but there have been changes  
>> and fixes
>> made to our connector code...
>> You'll find the current source here --
>> --kevan

View raw message