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 6 | Tomcat with APR causing Thread Blocking
Date Fri, 05 Feb 2016 22:47:30 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message