Re: All worker threads of my tomcat have been occupied!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Benimaur, On 1/3/14, 1:16 AM, Benimaur Gao wrote: gotcha! I moved tomcat home directory to another partition by using 'cp -r' at that time. That's why tomcat start to reload. Since you didn't use the -p switch, all of your timestamps were probably updated. If you did this while Tomcat was watching the destination, then Tomcat might have reloaded on you. Note that using Context in your server.xml file is a bad idea. There are lots of other ways to do it that aren't so problematic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSyK+nAAoJEBzwKT+lPKRY8moP/AswxxAXGzmULlfLzni82YeV i6EqmQMorrWzVLdQN/in4J47l6xh9X2pGgxhC1Cv0SNMGgspPj75Im1GRGeN9gpB hwnyFe8bszFUfNRa/9ChBWhcxD8BowLAXaO/ob0Hceqz/TrHtaJG6JoG3q4ARlEV 9JaHpN0g7RjrupNhBG1jiDDR4j2E++KUayNks+UmC5BMonZmcsSPkJgxXLBcIsXr IJ78oXTU/LU9DUlwzADzmx713MzB7p2Mvxfo39zSPurRDFl/YHmuDmP38WIJFUxo 1Gyp8ZBnuFoFWiN38VqtnJSESp4GByQP049O+R0y6IszHBRmOhrYPghTK6DAyQgr zReg03svA1lN0PCYBMKR18isCIOg8j36EITFFGd7ckJClgPtEFhD/ptWNiNjvMUx zY8WCVguf9ju/W14yjwPO3KeOwNhYdZwT6NScpYUXfUiBySzp5IcHKQ/aCJ6V2qJ XMIlXDvGHQUS5azdY0Qo88rZK5Wi9BNvVrHy/VUs9b0J76wCbERnBTggdEZQUsMD /cD3zZKOrhSdn+sUHuiq4Z4h2kAzl20+Q7+ADrmBnAuleTGa6CZrH/a0QXd+AOtw yeer0KaBdZWj6GHLy3kVsnNqnWTGLJ0ieosKqAARqfe9M2zlJyhgawlwJm2s/iY9 1XWjf/KFGdRjFsBO4jSh =M66V -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: All worker threads of my tomcat have been occupied!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Benimaur,
On 1/2/14, 5:20 AM, Benimaur Gao wrote:
I found my tomcat refusing to work this morning. I tried jstack to
get some info, and then I found a lot of thread call stack like:
http-8082-154 daemon prio=10 tid=0x7f711c21f800 nid=0x5b0a
waiting on
condition [0x7f70dc887000] java.lang.Thread.State:
TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native
Method) at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:132)
Your
context (aka web application) is reloading. That's the only time
StandardContextValve calls Thread.sleep() -- and only in Tomcat 6.
Tomcat 7 and 8 don't do this.
The request coming from the remote client (indicated by the use of the
http-- thread name) is waiting on the webapp to complete its
reload. You'll see one of these threads in this state for each request
you got since the webapp started reloading.
It seems all of the 200 JIoEndpoint$Worker threads had been
occupied. and I guess that's why tomcat refuse to serve any
incoming request.
Sounds about right.
After I got a copy of the source of my tomcat. I found $ grep -B3
-A8 context.getPaused\(\)
/home/benimaur/workspace/eclipse/tomcat/src/org/apache/catalina/core/StandardContextValve.java
126- 127-// Wait if we are reloading 128-boolean
reloaded = false; 129:while (context.getPaused()) { 130-
reloaded = true; 131-try { 132-
Thread.sleep(1000); 133-} catch (InterruptedException
e) { 134-; 135-} 136-} 137-
It seems context had been set to reload state at some time, but I
can't figure out under what circumstance would put tomcat into
such state. does any one here could give me more clue? thanks in
advance.
Do you use the manager app? What are your Engine settings for things
like reloading, etc. from server.xml?
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSxaYzAAoJEBzwKT+lPKRY7FAP/1UHDzaui8CrPV2E5JvCRDvF
QlMagAJmIN0+2Lm9LwTNG05ExmOTiH3AEf3hfiBC+YrzWc+jDYbCasDwjoCYMEuS
ZYgRIMO+nfzVyMhDEK8e9/AHfEg7YN/4R6EmWH4bv8MvMmnS9px1JzGI78BfggkT
v550utxeKGIS/C21YRwJWsqFg16TdfRWhBLe/TZYbdpoNzkHjTstTJ+18iAZZZpC
0rkqpT4QW/KL28CGFNdo4hmN459zFBoLte1p3ZfMXBmvg4WmOavaGBlyblNQWD8k
BMlaidAjRdkZXdI9zXGqz9NVGPP87+YAPPQxAXw2zcnqYyNTHhtA62mn3keq3gS7
cMuyrTXezFvdkOS+pQn3NtEQeI57S8GEO/WZnmNHpQYOQEyUVKPGBiyK3tYmcDVf
3bWIRykp7kP6HG2gxHaeIZWhwo6ub6UtFiSSW413NzX4x4k4EuP7bWO5rdMwgK2i
bIZTV8KLwkF7x8xsxDAIZdkhBgydQRzN1XtO+nB6mNql7v/hl5kf1ncHQK8ed2FW
jy2qzgqI43XF3gtnTrk6FLUeMYxDfaavTB/6Ge7d7AQHKClAy9Qc4WPdjANu6zkC
jJ/pu1BBD85Aa2pkswYwnCmnGUgtfjBLCmMeSrkhLSPqxvll/oQkoF0Qz4wGkOJL
2UARqAHN6uEn7c6XZ4Yb
=gfWU
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: All worker threads of my tomcat have been occupied!
From: Benimaur Gao [mailto:benim...@gmail.com] Subject: All worker threads of my tomcat have been occupied! I tried jstack to get some info, and then I found a lot of thread call stack like: http-8082-154 daemon prio=10 tid=0x7f711c21f800 nid=0x5b0a waiting on condition [0x7f70dc887000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:132) It seems all of the 200 JIoEndpoint$Worker threads had been occupied. It seems context had been set to reload state at some time, but I can't figure out under what circumstance would put tomcat into such state. Try looking at the threads _not_ doing the wait from StandardContextValve; one of those should be involved in reloading the webapp and perhaps you can find out what it's waiting for. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: All worker threads of my tomcat have been occupied!
From: Benimaur Gao [mailto:benim...@gmail.com] Subject: Re: All worker threads of my tomcat have been occupied! Don't top post - it makes the conversation very difficult to follow. that's very strange. I failed to find any thread stack relevant to tomcat reloading. Perhaps you could post the stack trace somewhere we could look at it (e.g., pastebin). All settings in my server.xml are just using the default value, except one modification to Context block to set the real deployment path. ?? Please elaborate on that (be specific). what's the condition to trigger tomcat redeployment, and how to avoid it? The redeployment triggers are specified by WatchedResource elements nested inside Context elements. By default, WEB-INF/web.xml is the only monitored file, specified in the global conf/context.xml. Any chance someone did a touch on your webapp's web.xml? Does it leave me no choice but upgrading my tomcat? Always good to stay up to date, but it's not likely to be relevant here. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: All worker threads of my tomcat have been occupied!
gotcha! I moved tomcat home directory to another partition by using 'cp -r' at that time. That's why tomcat start to reload. Thank you! the whole stack trace is post here http://pastebin.com/KB9cWMFw On Fri, Jan 3, 2014 at 1:32 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: Benimaur Gao [mailto:benim...@gmail.com] Subject: Re: All worker threads of my tomcat have been occupied! Don't top post - it makes the conversation very difficult to follow. that's very strange. I failed to find any thread stack relevant to tomcat reloading. Perhaps you could post the stack trace somewhere we could look at it (e.g., pastebin). All settings in my server.xml are just using the default value, except one modification to Context block to set the real deployment path. ?? Please elaborate on that (be specific). what's the condition to trigger tomcat redeployment, and how to avoid it? The redeployment triggers are specified by WatchedResource elements nested inside Context elements. By default, WEB-INF/web.xml is the only monitored file, specified in the global conf/context.xml. Any chance someone did a touch on your webapp's web.xml? Does it leave me no choice but upgrading my tomcat? Always good to stay up to date, but it's not likely to be relevant here. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
