tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Tomcat hangs when reloading context if user is logged in
Date Mon, 02 Nov 2009 19:01:52 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James,

On 11/2/2009 1:32 PM, James Murphy wrote:
>> Here are a couple of thread dumps of tomcat, the first taken about 5
>> seconds after the hang, and the second a couple of minutes later, while
>> still hung.

Okay.

>> Note that in the main methods, there is one stack frame with some XX's
>> in it. I put those there to cover the name of a method which could
>> identify our company. Nothing personal, I'm just not allowed to let that
>> information leak out.

No problem: this is always good practice. Thanks for mentioning it,
though :)

>> After seeing that stack frame, however, I looked into the method which
>> it referenced. It appears to be sending a HTTP POST message to a servlet
>> which we have running, which is supposed to log the user out when it
>> recieves said message. Could the problem be that the servlet is shut
>> down before the message reaches it?


Most of these all look the same. That is, they are just waiting for
requests to come in:

>> "http-80-6" daemon prio=6 tid=0x0322a400 nid=0xb10 in Object.wait()
>> [0x03d5f000..0x03d5fb18]
>>   java.lang.Thread.State: WAITING (on object monitor)
>>    at java.lang.Object.wait(Native Method)
>>    - waiting on <0x181530c0> (a

[snip]

>> "main" prio=6 tid=0x00297000 nid=0xb18 runnable [0x0088f000..0x0088fe58]
>>   java.lang.Thread.State: RUNNABLE
>>    at java.net.SocketInputStream.socketRead0(Native Method)
>>    at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>>    at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
>>    at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
>>    - locked <0x1698bc98> (a java.io.BufferedInputStream)
>>    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:632)
>>    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
>>    at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1004)
> 
>>    - locked <0x16981bd0> (a sun.net.www.protocol.http.HttpURLConnection)
>>    at com.oreilly.servlet.HttpMessage.sendPostMessage(HttpMessage.java:141)
>>    at
>> com.XXXXXXX.bean.XXXXSessionListener.valueUnbound(XXXXSessionListener.java:44)
> 
>>    at
>> org.apache.catalina.session.StandardSession.removeAttributeInternal(StandardSession.java:1654)
> 
>>    at
>> org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1507)
> 
>>    at
>> org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:959)
> 
>>    at
>> org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:517)

It looks like the StandardManager is trying to persist your sessions,
which is proper behavior (unless you have disabled it). You have a
listener that, as you mentioned, is making an outgoing HTTP connection.

Is it connecting to another webapp, or to the same webapp? If you're
trying to connect to the same webapp, then it's possible that Tomcat has
paused all your <Connector>s, and they aren't accepting any connections.
In that case, you'll wait for a long time (and possibly repeatedly
attempt connections) before your POST fails.

If the above describes your situation, may I recommend that, instead of
making an HTTP POST back to your own webapp, you instead make a regular
Java method call to process this logout stuff? It shouldn't be that
tough to refactor your code to allow your logout logic to be called
either from an HTTP request or from an explicit method call.

Your second thread dump shows the "main" thread stuck in the same place:

>> "main" prio=6 tid=0x00297000 nid=0xb18 runnable [0x0088f000..0x0088fe58]
>>   java.lang.Thread.State: RUNNABLE
>>    at java.net.SocketInputStream.socketRead0(Native Method)
>>    at java.net.SocketInputStream.read(SocketInputStream.java:129)
>>    at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
>>    at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
>>    at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
>>    - locked <0x1698bc98> (a java.io.BufferedInputStream)
>>    at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:632)
>>    at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:577)
>>    at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1004)
> 
>>    - locked <0x16981bd0> (a sun.net.www.protocol.http.HttpURLConnection)
>>    at com.oreilly.servlet.HttpMessage.sendPostMessage(HttpMessage.java:141)
>>    at
>> com.XXXXXXX.bean.XXXXSessionListener.valueUnbound(XXXXSessionListener.java:44)

Yup: still waiting.

Try calling your logout logic without using an HTTP POST and I think
you'll find that things start working more reasonably for you.

Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrvLKAACgkQ9CaO5/Lv0PCuZwCgrpXZFpDQKvWcHXqy3eqw/Ra2
sAIAnjnhp5a8eeK/vf3sBsTtCeJg3hCZ
=dILD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message