HI Chris,
Sorry for a delayed response.
Here is few information that you asked for:
1. Tomcat Native Library version is 1.1.30 and APR version is 1.4.8
2. I am running my tomcat 6.0.41 on Windows 7 system with Java 7.
As you said that if APR is not available the Java BIO (blocking I/O) connector
will be used. For me this connector is working.
I am still not able to pinpoint to exact difference between these two types of
connectors, which might be causing/solving the issue.
Here is the thread dump for the stuck thread:
"http-8080-2" - Thread t@55
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
- locked <1559b4d1> (a java.io.BufferedInputStream)
at
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
at
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1118)
at
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1373)
at
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
at
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
at
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
at
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
at
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at
org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:364)
at
org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at
org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at
org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at
org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:75)
at org.codehaus.xfire.client.Client.invoke(Client.java:335)
at
org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at com.sun.proxy.$Proxy62.query(Unknown Source)
at
com.XXXXXXXX.XXX.web.services.client.XXXXXXXXXX.sendMessageToServer(XXXXXXXXXXX.java:53)
.
.
.
Thanks,
Ravi Ranjan
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Saturday, February 06, 2016 4:18 AM
To: Tomcat Users List
Subject: Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ravi,
On 2/4/16 2:15 AM, Ranjan, Ravi wrote:
> I am new to this user list and this is the first email I am sending
> out to you. Hope you will let me know if more
> information/logs/dump/test case/clarity is required.
Welcome.
> So I am working with Tomcat 6.0.41 (both 64bit and 32 bit). In my
> Tomcat environment I am using APR (Apache Portable
> Runtime<http://ivf.dlr.de/docs/apr.html>)Listener: (by configuring
> below property in server.xml) <Listener
> className="org.apache.catalina.core.AprLifecycleListener"
> SSLEngine="on" />
So far, so good. The only think you didn't mention was the versions of APR and
tcnative you were using, and your OS.
> I am using below connector, which i assume is a blocking type:
> <Connector port="8080" protocol="HTTP/1.1" maxThreads="150"
> connectionTimeout="20000" redirectPort="8443" />
If you have APR available, then that configuration will give you the APR
connector. If APR is not available, you'll get the Java BIO (blocking I/O)
connector.
> In one of my webapp i am running a dll as a Java Process to validate
> some data. This dll is accessed as a Process whenever is required. I
> have separate Thread to terminate this Process if not used for few
> minutes.
(DLL: So this is Microsoft Windows?)
> Now i am facing a weired issue where with Apache Tomcat 6.0.43 (both
> 64 and 32 bit), the http thread that has started this process gets
> stuck. From thread dump i get this stack trace:
>
> "http-8080-2" - Thread t@55 java.lang.Thread.State: RUNNABLE at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.read(SocketInputStream.java:152) at
> java.net.SocketInputStream.read(SocketInputStream.java:122) at
> java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at
> java.io.BufferedInputStream.read(BufferedInputStream.java:254) -
> locked <1559b4d1> (a java.io.BufferedInputStream) at
> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:7
7)
>
>
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105
)
> at
> org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.j
ava:1118)
>
>
.
> . .
Hmm. The thread name doesn't say what type of connector it is. I might just be
used to seeing thread names from Tomcat 7+, where it's clear whether
nio/bio/apr is in use.
But! The stack trace above is not Tomcat's code. This is your code calling-out
through commons HttpClient to another server. None of your <Connector>
configuration has any bearing on how that connection is handled.
> To ascertain that the native process is not causing the issue, i ran
> few other external exe's (both 64 bit and 32 bit) with same result.
>
> During my research i found that if i comment the above listed
> AprLifecycleListener property from the server.xml, things start
> working. This behavior is very inconsistent across different versions
> of Tomcat, e.g. in Tomcat 6.0.10, i am not facing the issue. Then i
> upgraded to Tomcat 8, i faced this issue. I have tried with many
> versions of Tomcat and all result in same behavior.
>
> So, is this APR interfering with my own process calls? Or is there
> something that i am missing. Anyone who have seen any such tomcat bugs
> or fixes can point me as well.
I'm not convinced this has anything to do with Tomcat at all, actually. If your
code is stuck calling another service, there's nothing Tomcat can do about it.
Can you show us more of that stack trace?
Something many programmers forget is that any time you are making a call that
touches the network, it's vitally important to set appropriate timeouts. Many
APIs default to "no timeout: wait forever"
which means if there's some kind of network lag or whatever, your web
application will become unresponsive if you make requests to some other
unreliable service. If you timeout after 2-3 seconds, at least your application
can tell the user "sorry, that *other* service is down", instead of locking
everything up.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAla1JoIACgkQ9CaO5/Lv0PDEqACguX5Mi+XmVMKj1+C7K4hy6rQv
I+QAn0qnJm+82GiA0F5kdPesL5THEAAo
=J4DD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
_____________
The information contained in this message is proprietary and/or confidential.
If you are not the intended recipient, please: (i) delete the message and all
copies; (ii) do not disclose, distribute or use the message in any manner; and
(iii) notify the sender immediately. In addition, please be aware that any
message addressed to our domain is subject to archiving and review by persons
other than the intended recipient. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
