You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Ranjan, Ravi" <Ra...@fisglobal.com> on 2016/02/04 08:15:29 UTC
Tomcat 6 | Tomcat with APR causing Thread Blocking
Hi Guys,
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.
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" />
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" />
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.
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:77)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1118)
.
.
.
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.
Thanks and Regards,
Ravi Ranjan
_____________
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.
Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ravi,
On 2/10/16 1:43 AM, Ranjan, Ravi wrote:
> Yes the stack trace was taken on server.
> Anyway thanks for your valuable replies, I will continue my
> research in this direction. Since tomcat is out of picture now, I
> will concentrate on my external Process or any redesign that might
> be required. I will share my findings, if hopefully I am able to
> crack this one.
It's not rocket science: just set a connection/read timeout on the
HTTP client. Something like this:
AbstractHttpMessage message = <your HTTP message>;
HttpParams params=message.getParams();
HttpConnectionParams.setConnectionTimeout(params, 5000); // 5s
HttpConnectionParams.setSoTimeout(params, 5000); // 5s
Hope that helps,
- -chris
> -----Original Message----- From: Christopher Schultz
> [mailto:chris@christopherschultz.net] Sent: Tuesday, February 09,
> 2016 7:42 PM To: Tomcat Users List Subject: Re: Tomcat 6 | Tomcat
> with APR causing Thread Blocking
>
> Ravi,
>
> On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
>> 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:
7
>
>>
7)
>
> This
>
> stack trace was taken on the server, not the client, right?
>
> If so, this has nothing whatsoever to do with Tomcat. This is a
> problem with your web application making a connection to an outside
> service that is taking a long time to respond.
>
> Set your timeouts appropriately and you won't have this stuck
> thread anymore. But you will have to handle error situations, of
> course.
>
> -chris
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAla7VcAACgkQ9CaO5/Lv0PAwrACeOZXkok7crxHSYO/jHO9mZuOX
LioAn35Kd4PPQ3jrmdUBg89L8t/gMcmt
=W3QV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6 | Tomcat with APR causing Thread Blocking
Posted by "Ranjan, Ravi" <Ra...@fisglobal.com>.
Chris,
Yes the stack trace was taken on server.
Anyway thanks for your valuable replies, I will continue my research in this direction. Since tomcat is out of picture now, I will concentrate on my external Process or any redesign that might be required. I will share my findings, if hopefully I am able to crack this one.
Regards,
Ravi Ranjan
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Tuesday, February 09, 2016 7:42 PM
To: Tomcat Users List
Subject: Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ravi,
On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
> 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:7
7)
This
>
stack trace was taken on the server, not the client, right?
If so, this has nothing whatsoever to do with Tomcat. This is a problem with your web application making a connection to an outside service that is taking a long time to respond.
Set your timeouts appropriately and you won't have this stuck thread anymore. But you will have to handle error situations, of course.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAla588EACgkQ9CaO5/Lv0PBRGQCfR9Loo2m5rvQSmva7BYTar7JQ
8fUAn1uKghqYKTjbKE99ahnxGtlTaWza
=Vip6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ravi,
On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
> 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:7
7)
This
>
stack trace was taken on the server, not the client, right?
If so, this has nothing whatsoever to do with Tomcat. This is a
problem with your web application making a connection to an outside
service that is taking a long time to respond.
Set your timeouts appropriately and you won't have this stuck thread
anymore. But you will have to handle error situations, of course.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAla588EACgkQ9CaO5/Lv0PBRGQCfR9Loo2m5rvQSmva7BYTar7JQ
8fUAn1uKghqYKTjbKE99ahnxGtlTaWza
=Vip6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 6 | Tomcat with APR causing Thread Blocking
Posted by "Ranjan, Ravi" <Ra...@fisglobal.com>.
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:chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 6 | Tomcat with APR causing Thread Blocking
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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