You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bryan Basham <bb...@stillsecure.com> on 2007/02/09 18:34:33 UTC
Deadlock in Tomcat 5.5.20
Hi all,
This might not be the right forum for this. Let em know if
I should post this to the tomcat-dev alias.
THE PROBLEM
The problem we are experience is that occasionally Tomcat (5.5.20)
is deadlocking; see the attached output from a kill -3 on the tomcat
process.
Has anyone seen this happen? Did you discover why this is happening?
And most importantly: How did you fix it?
THE BACKGROUND
I am working on a project in which our architecture requires
"pluggable" modules. In the first two iterations, we avoided that
requirement by building all modules into a single ROOT.war
webapp. Now in this iteration we are "teasing apart" these into
separately loaded moduleXYZ.war files.
This has caused lots of headaches; especially around getting
JSF to handle cross-context (cross-webapp) navigation and
bean management. We have pretty much solved the JSF issues,
some fixes required doing things like performing cross-context
dispatching and merging of JSF's RuntimeConfig objects from
each webapp ServletContext. However, I don't see how any
of these changes would cause the deadlock.
Sincere thanks,
Bryan
Re: Deadlock in Tomcat 5.5.20
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bryan,
Rainer Jung wrote:
> So where's the deadlock in this stack dump?
Yeah... there are no interesting threads in there. Did you post the
wrong thread dump?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFzMHN9CaO5/Lv0PARAtojAKCjk/PooJirr1hIMp8by//BSF/IPQCgjKGb
ACgNjifTgpVTrMwR95e8pww=
=Vjs5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deadlock in Tomcat 5.5.20
Posted by Bryan Basham <bb...@stillsecure.com>.
Upon reflection my team has decided that it is some
strange interaction between Firefox and our VMware
instance running Tomcat. If we kill Firefox, then Tomcat
resumes processing requests. How bizarre.
Sorry to waste the bandwidth.
-Bryan
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Deadlock in Tomcat 5.5.20
Posted by Rainer Jung <ra...@kippdata.de>.
So where's the deadlock in this stack dump?
Bryan Basham wrote:
> Hi all,
>
> This might not be the right forum for this. Let em know if
> I should post this to the tomcat-dev alias.
>
> THE PROBLEM
>
> The problem we are experience is that occasionally Tomcat (5.5.20)
> is deadlocking; see the attached output from a kill -3 on the tomcat
> process.
>
> Has anyone seen this happen? Did you discover why this is happening?
> And most importantly: How did you fix it?
>
> THE BACKGROUND
>
> I am working on a project in which our architecture requires
> "pluggable" modules. In the first two iterations, we avoided that
> requirement by building all modules into a single ROOT.war
> webapp. Now in this iteration we are "teasing apart" these into
> separately loaded moduleXYZ.war files.
>
> This has caused lots of headaches; especially around getting
> JSF to handle cross-context (cross-webapp) navigation and
> bean management. We have pretty much solved the JSF issues,
> some fixes required doing things like performing cross-context
> dispatching and merging of JSF's RuntimeConfig objects from
> each webapp ServletContext. However, I don't see how any
> of these changes would cause the deadlock.
>
> Sincere thanks,
> Bryan
>
>
> ------------------------------------------------------------------------
>
> "Java2D Disposer" daemon prio=1 tid=0x08af2f10 nid=0xf1d in Object.wait() [0x9bda3000..0x9bda40d0]
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa03bf8a8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
> - locked <0xa03bf8a8> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
> at sun.java2d.Disposer.run(Disposer.java:107)
> at java.lang.Thread.run(Thread.java:595)
>
> "Timer-3" daemon prio=1 tid=0x083667f8 nid=0xe9c in Object.wait() [0x9be41000..0x9be42150]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9ff8d648> (a java.util.TaskQueue)
> at java.util.TimerThread.mainLoop(Timer.java:509)
> - locked <0x9ff8d648> (a java.util.TaskQueue)
> at java.util.TimerThread.run(Timer.java:462)
>
> "TP-Monitor" daemon prio=1 tid=0x0837ab30 nid=0xe9b in Object.wait() [0x9bec2000..0x9bec2ed0]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9ff8d688> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
> at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:559)
> - locked <0x9ff8d688> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor4" daemon prio=1 tid=0x083615e8 nid=0xe9a runnable [0x9bf43000..0x9bf43e50]
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
> - locked <0x9ff8d6b0> (a java.net.SocksSocketImpl)
> at java.net.ServerSocket.implAccept(ServerSocket.java:450)
> at java.net.ServerSocket.accept(ServerSocket.java:421)
> at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:306)
> at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:660)
> at org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:870)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor3" daemon prio=1 tid=0x083603d0 nid=0xe99 in Object.wait() [0x9bfc4000..0x9bfc4fd0]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9ff8d8d8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Object.wait(Object.java:474)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:656)
> - locked <0x9ff8d8d8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Thread.run(Thread.java:595)
>
> "TP-Processor2" daemon prio=1 tid=0x0835f288 nid=0xe98 in Object.wait() [0x9c045000..0x9c045f50]
> at java.lang.Object.wait(Native Method)
> - waiting on <0x9ff8d8f8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Object.wait(Object.java:474)
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:656)
> - locked <0x9ff8d8f8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
> at java.lang.Thread.run(Thread.java:595)
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org