You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Andrew Thorburn <nz...@gmail.com> on 2008/07/30 01:42:00 UTC
Getting "Deque Full" error on Connection.close()
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
:).
Thanks all,
- Andrew Thorburn
Problem loading Queue Monitor java.lang.IllegalStateException: deque
is full: contents:
[org.apache.geronimo.connector.outbound.ManagedConnectionInfo@beb543,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@174682a,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@166aaeb,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@12ac92d,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@228908,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@c9dfbc,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1972f40,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1b48369,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1d5381a,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@18ce535,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@787dae,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@9f44ce,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1637a9e,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@5e36db,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@15d46f4,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@3842c6,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@cee538,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@16a73c9,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@351ef4,
org.apache.geronimo.connector.outbound.ManagedConnectionInfo@1191845]
at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor$PoolDeque.add(SinglePoolConnectionInterceptor.java:232)
at org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor.internalReturn(SinglePoolConnectionInterceptor.java:155)
at org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor.returnConnection(AbstractSinglePoolConnectionInterceptor.java:119)
at org.apache.geronimo.connector.outbound.TransactionEnlistingInterceptor.returnConnection(TransactionEnlistingInterceptor.java:94)
at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.internalReturn(TransactionCachingInterceptor.java:109)
at org.apache.geronimo.connector.outbound.TransactionCachingInterceptor.returnConnection(TransactionCachingInterceptor.java:101)
at org.apache.geronimo.connector.outbound.ConnectionHandleInterceptor.returnConnection(ConnectionHandleInterceptor.java:71)
at org.apache.geronimo.connector.outbound.TCCLInterceptor.returnConnection(TCCLInterceptor.java:50)
at org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor.returnConnection(ConnectionTrackingInterceptor.java:82)
at org.apache.geronimo.connector.outbound.GeronimoConnectionEventListener.connectionClosed(GeronimoConnectionEventListener.java:67)
at org.tranql.connector.AbstractManagedConnection.connectionClosed(AbstractManagedConnection.java:102)
at org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.java:97)
at MYCLASS_5
at MYCLASS_4
at MYCLASS_3
at MYCLASS_2
at MYCLASS_1
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:397)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:104)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:59)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1530)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1482)
at org.mortbay.http.HttpServer.service(HttpServer.java:909)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Re: Getting "Deque Full" error on Connection.close()
Posted by Andrew Thorburn <nz...@gmail.com>.
Ah, that makes sense. Would it be possible to add a search option to
the browser SVN pages?
Not off the top of my head. I'll check when I get in to work tomorrow.
I don't think we have terribly high logging enabled in production, so
even if it was happening it might not be showing up in the logs. I
wouldn't be terribly surprised if it was something like that, but you
never know. Anyway, I'll try to remember to let you know if this fixes
the errors, should we ever get around to upgrading. That, or I'll be
back digging through the source code trying to understand *why*.
- Andrew Thorburn
On Wed, Jul 30, 2008 at 7:41 PM, David Jencks <da...@yahoo.com> wrote:
>
> 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.
>
> thanks
> david jencks
>
>>
>>
>> Thanks a lot,
>>
>> - Andrew Thorburn
>>
>> On Wed, Jul 30, 2008 at 5:55 PM, Kevan Miller <ke...@gmail.com>
>> 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 --
>>>
>>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.1/geronimo-connector
>>>
>>> --kevan
>>>
>
>
Re: Getting "Deque Full" error on Connection.close()
Posted by David Jencks <da...@yahoo.com>.
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.
thanks
david jencks
>
>
> Thanks a lot,
>
> - Andrew Thorburn
>
> On Wed, Jul 30, 2008 at 5:55 PM, Kevan Miller
> <ke...@gmail.com> 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 --
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.1/geronimo-connector
>>
>> --kevan
>>
Re: Getting "Deque Full" error on Connection.close()
Posted by Andrew Thorburn <nz...@gmail.com>.
I would *never* have thought to look there for the current connector
code. How does txmanager relate? 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
Thanks a lot,
- Andrew Thorburn
On Wed, Jul 30, 2008 at 5:55 PM, Kevan Miller <ke...@gmail.com> 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 --
> https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.1/geronimo-connector
>
> --kevan
>
Re: Getting "Deque Full" error on Connection.close()
Posted by Kevan Miller <ke...@gmail.com>.
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 -- https://svn.apache.org/repos/asf/geronimo/components/txmanager/tags/geronimo-txmanager-parent-2.1.1/geronimo-connector
--kevan