You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Howard W. Smith, Jr." <sm...@gmail.com> on 2013/11/10 15:14:39 UTC
Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Using Tomcat 7.0.47 via TomEE 1.6.0 along with MyFaces 2.1.13
Recently, I have been experiencing the SocketTimeoutException when web
application is serving resources to 'mobile clients'. Yesterday, user was
attempting to login from mobile iPad via an internal wireless phone
connection. Since my web application is accessed by mobile clients and
since I started using TomEE (tomcat7 and myfaces), I have seen the 'Error
trying to load resource ...' (below), but I have not seen the
SocketTimeoutException until I recently started using Tomcat 7.0.47 and
MyFaces 2.1.13.
I saved the first occurrence (Nov 8, 2013) of this exception on gist[1] and
saved Nov 9, 2013 occurrence on gist as well. I do have a web/servlet
filter in place, and I assume that I can catch the SocketTimeoutException
(when client is mobile) to prevent the stacktrace in the log, but this
exception is 'now' being logged to tomcat7-stderr, but this
SocketTimeoutException was not logged with previous versions of Tomcat
7.0.x and MyFaces 2.1.x. I assume that this is new logging behavior of
MyFaces 2.1.13 (or there is something new about Tomcat 7.0.47) but I may be
mistaking.
Please see all below, and advise how I can prevent this exception, if I can
adjust some tomcat settings to increase the socket timeout value, or
recommendations about serving resources to 'mobile clients'. I'm thinking
that I can increase the expiration of client resources from my web/servlet
filter, so this will not occur as often. This exception does not occur
everytime, but i'm sure you can understand that this 'can' happen
frequently and sporadically, depending on the connection between server and
mobile-device-via-wireless-phone-connection.
localhost_access_log shows the follow (please note the filenames and time
difference between the 1, 2, and 3rd lines below)
x.x.x.x - - [09/Nov/2013:13:08:25 -0500] "GET
/webapp/javax.faces.resource/primefaces.css.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 10036
x.x.x.x - - [09/Nov/2013:13:09:00 -0500] "GET
/webapp/javax.faces.resource/jquery/jquery.js.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 -
x.x.x.x - - [09/Nov/2013:13:09:00 -0500] "GET
/webapp/javax.faces.resource/jquery/jquery-plugins.js.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 -
tomcat7-stderr
Nov 09, 2013 1:09:00 PM org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery.js with library
primefaces :null
ClientAbortException: java.net.SocketTimeoutException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
Caused by: java.net.SocketTimeoutException
at
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
at
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
at
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
Nov 09, 2013 1:09:00 PM org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery-plugins.js with library
primefaces :null
ClientAbortException: java.net.SocketTimeoutException
Caused by: java.net.SocketTimeoutException
at
org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
at
org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
at
org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
[1] https://gist.github.com/smithh032772/7380812
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Nov 11, 2013 at 5:41 AM, André Warnier <aw...@ice-sa.com> wrote:
> Howard W. Smith, Jr. wrote:
>
>> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
>> smithh032772@gmail.com> wrote:
>>
>> Caused by: java.net.SocketTimeoutException
>>> at
>>> org.apache.tomcat.util.net.NioBlockingSelector.write(
>>> NioBlockingSelector.java:127)
>>> at
>>> org.apache.tomcat.util.net.NioSelectorPool.write(
>>> NioSelectorPool.java:174)
>>> at
>>> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(
>>> InternalNioOutputBuffer.java:163)
>>>
>>>
>> my apologies, based on this exception (above), I decided to provide you
>> with the following from my tomee/conf/server.xml:
>>
>>
>> <Connector port="8080"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="150" connectionTimeout="20000"
>> acceptorThreadCount="2"
>> redirectPort="8443" socket.directBuffer="false"/>
>>
>>
>> I guess the answer may be the connectionTimeout="..." (above), but still
>> would like to know recommendations of others based on experience with web
>> application serving mobile clients. thanks.
>>
>>
> AFAIK, the "connectionTimeout" above applies specifically to this :
> - the client opens a TCP connection to the server
> - but then the client does not send any request over that connection
> (so the server waits and waits, until that timeout strikes).
> This is a classic way of doing a DoS attack : many clients connect and
> don't send a request (or do it very slowly), tying up server resources
> until the server is overwhelmed.
> In some Connector configurations, this does not necessarily tie up a
> Thread (only a TCP socket), but it does have the potential to tie up
> limited resources.
> The value of 20000 above is in milliseconds, so after a connection is
> established, the server will wait up to 20 seconds for a request to be
> received.
> I would not expect nowadays that any client, on any type of connection,
> would take that long to send a request on an established connection. So I
> would certainly not make it larger, and you can probably reduce it
> significantly, and save resources.
>
>
>
Great, thank you!
I left it as-is and given the situation (which I communicated earlier), I
saw no need to increase the connectionTimeout value. Noted your
recommendation about decreasing the value...for now.
thanks again!
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 11/11/13, 5:41 AM, André Warnier wrote:
> Howard W. Smith, Jr. wrote:
>> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
>> smithh032772@gmail.com> wrote:
>>
>>> Caused by: java.net.SocketTimeoutException at
>>> org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
>>>
>>>
>>>
at
>>> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
>>>
>>>
>>>
at
>>> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
>>>
>>>
>>
>>
>>>
my apologies, based on this exception (above), I decided to provide you
>> with the following from my tomee/conf/server.xml:
>>
>>
>> <Connector port="8080"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="150" connectionTimeout="20000"
>> acceptorThreadCount="2" redirectPort="8443"
>> socket.directBuffer="false"/>
>>
>>
>> I guess the answer may be the connectionTimeout="..." (above),
>> but still would like to know recommendations of others based on
>> experience with web application serving mobile clients. thanks.
>>
>
> AFAIK, the "connectionTimeout" above applies specifically to this
> : - the client opens a TCP connection to the server - but then the
> client does not send any request over that connection (so the
> server waits and waits, until that timeout strikes).
More specifically, it's the timeout within which the client must send
the *request line* of the request. The whole request can take 10
minutes (e.g. huge streaming upload) for all Tomcat cares, as long as
the initial request line arrives within that 20 seconds.
> This is a classic way of doing a DoS attack : many clients connect
> and don't send a request (or do it very slowly), tying up server
> resources until the server is overwhelmed. In some Connector
> configurations, this does not necessarily tie up a Thread (only a
> TCP socket), but it does have the potential to tie up limited
> resources. The value of 20000 above is in milliseconds, so after a
> connection is established, the server will wait up to 20 seconds
> for a request to be received. I would not expect nowadays that any
> client, on any type of connection, would take that long to send a
> request on an established connection. So I would certainly not
> make it larger, and you can probably reduce it significantly, and
> save resources.
+1
If a client doesn't send the request within about 5 seconds, I don't
think it's going to send it at all. (Probably less than 5 seconds,
honestly, but I've never bothered to collect the data on my servers to
substantiate that assertion).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSgPe8AAoJEBzwKT+lPKRYDH0QAMnXTmInl/aRqYQY8nONf16K
2Scj1Jk4r2X9fjRaGXnO9p5A3vmnrTnUEruaKBl1Jym8Y0nMFbPtSBsxXaKTfRBH
uvIZAj0jyKkuS7oaXBGAjCkRP8ZGNWyHgjB/e+EBWg7dinAl3zfe6Ims4EBIUxc5
GL3fdbyX6uMhV7snMilYXT3OJcp8vPXDGTG6apOLoepfbMxCiBdYpV0MEKO6FEu1
v5lSoN5Clk3g1d9i7utxrfV/cegsABxRDxNpo56SrjdajVkfrOOzr9Wf1Qqy+bIe
nxMcK+AT/V/SNxpHjQ07grK5lBMjqd/vA4AgKDCQGX+qgfoF+6q7lA6YAk6wP7M9
QrBEe9Vj7Q9TLNE+DhClh/BZV5WYcXjUq6q4PI+G0XJYxwYHNcEGEj/ror5+Rqdg
af7iru3koQUFXqIHCblvjESmDsxLTmuI+Bh3NEZrm/VLdM2BiLAnnJQeILIhy2Ez
YZPq1LlbQojYBGITgii72wD9eS1TR309quFT5YQXd1GsTbCUU2Z/uOxPAJ9BZDJF
6nZZLvdRh0sBptqtomzgaYMcSrVBbBanoRwWxE2Gwo2iKHkpnhkWlG1mdyLEjeNk
Rq2+HzdEOHNPLXB9i528huvQKPP1BTPlUtuWd5d3aAVIb9yHoG5oesTsidPsXoLY
scuBEQREmP7qMtaOSGq5
=tEDl
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by André Warnier <aw...@ice-sa.com>.
Howard W. Smith, Jr. wrote:
> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
> smithh032772@gmail.com> wrote:
>
>> Caused by: java.net.SocketTimeoutException
>> at
>> org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
>> at
>> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
>> at
>> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
>>
>
> my apologies, based on this exception (above), I decided to provide you
> with the following from my tomee/conf/server.xml:
>
>
> <Connector port="8080"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" connectionTimeout="20000"
> acceptorThreadCount="2"
> redirectPort="8443" socket.directBuffer="false"/>
>
>
> I guess the answer may be the connectionTimeout="..." (above), but still
> would like to know recommendations of others based on experience with web
> application serving mobile clients. thanks.
>
AFAIK, the "connectionTimeout" above applies specifically to this :
- the client opens a TCP connection to the server
- but then the client does not send any request over that connection
(so the server waits and waits, until that timeout strikes).
This is a classic way of doing a DoS attack : many clients connect and don't send a
request (or do it very slowly), tying up server resources until the server is overwhelmed.
In some Connector configurations, this does not necessarily tie up a Thread (only a TCP
socket), but it does have the potential to tie up limited resources.
The value of 20000 above is in milliseconds, so after a connection is established, the
server will wait up to 20 seconds for a request to be received.
I would not expect nowadays that any client, on any type of connection, would take that
long to send a request on an established connection. So I would certainly not make it
larger, and you can probably reduce it significantly, and save resources.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sun, Nov 10, 2013 at 8:54 PM, Igor Cicimov <ic...@gmail.com> wrote:
> >
>
Also you didn't say anything about any load balancer or proxy fronting your
> application. It is worth checking the timeouts there as well and align them
> with the
> connection timeout on your server (in case you do use one of course).
>
there is no load balancer or proxy fronting the web application. thanks.
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sun, Nov 10, 2013 at 8:54 PM, Igor Cicimov <ic...@gmail.com> wrote:
> There is heaps of articles and questions in various forums
>
you're right... i searched google for ClientAbortException in tomcat nabble
archive, and saw many posts.
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by Igor Cicimov <ic...@gmail.com>.
On Mon, Nov 11, 2013 at 11:22 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> On Sun, Nov 10, 2013 at 5:08 PM, Igor Cicimov <ic...@gmail.com> wrote:
>
> > For Sun Java for example you can try the following:
> >
> > -Dsun.net.client.defaultReadTimeout=1800000
> >
> > which will increase the socket timeout to 30 minutes lets say if the
> > default one is not enough in case or slow client. Another thing to check
> is
> > your OS socket timeout setting, on linux systems for example:
> >
> > net.ipv4.tcp_keepalive_time = 300
> >
> > and try adjusting it according to your needs.
> >
> > Would love to hear some other people experiences and thoughts regarding
> > this as well, this is really annoying one to troubleshoot.
> >
>
> I like the following that was mentioned in a stackoverflow answer[1]:
>
> > It just means the client isn't sending. You don't need to worry about it.
> Browser clients come and go in all sorts of strange ways.
>
> Correct, and IE is worst with their tradition of not complying to the
standards. Especially if your app is using AJAX http POST requests in
shoert succession and gets worse in case if this id done over SSL. There is
heaps of articles and questions in various forums like this one for example:
http://stackoverflow.com/questions/4796305/why-does-internet-explorer-not-send-http-post-body-on-ajax-call-after-failure
which talks about timeout in case of re-posting POST requests in case of
failure (IE 6,7,8 send only the header with payload missing so the server
timeouts). The remedy is disabling the keep-alive on the server side but
this comes with the expense of every AJAX call opening new connection.
> I wouldn't put the server read timeout too high: it ties up a thread. If
> a client opens a connection to the server and doesn't send anything
> immediately it is misbehaving pretty badly.
>
> I agree with all of that and based on that, I will not modify the NIO
> connectiontimeout value. I would like to prevent the stacktrace from being
> logged in tomcat7-stderr log file, so I think I will catch the exception in
> my servlet filter.
>
> I agree with this one too, no matter how high or low you set your timeout
it will eventually strike since the client simply is not sanding the
complete http request in some particular cases. Also you didn't say
anything about any load balancer or proxy fronting your application. It is
worth checking the timeouts there as well and align them with the
connection timeout on your server (in case you do use one of course).
>
> [1] http://stackoverflow.com/a/17079991/933054
>
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sun, Nov 10, 2013 at 5:08 PM, Igor Cicimov <ic...@gmail.com> wrote:
> For Sun Java for example you can try the following:
>
> -Dsun.net.client.defaultReadTimeout=1800000
>
> which will increase the socket timeout to 30 minutes lets say if the
> default one is not enough in case or slow client. Another thing to check is
> your OS socket timeout setting, on linux systems for example:
>
> net.ipv4.tcp_keepalive_time = 300
>
> and try adjusting it according to your needs.
>
> Would love to hear some other people experiences and thoughts regarding
> this as well, this is really annoying one to troubleshoot.
>
I like the following that was mentioned in a stackoverflow answer[1]:
> It just means the client isn't sending. You don't need to worry about it.
Browser clients come and go in all sorts of strange ways.
> I wouldn't put the server read timeout too high: it ties up a thread. If
a client opens a connection to the server and doesn't send anything
immediately it is misbehaving pretty badly.
I agree with all of that and based on that, I will not modify the NIO
connectiontimeout value. I would like to prevent the stacktrace from being
logged in tomcat7-stderr log file, so I think I will catch the exception in
my servlet filter.
[1] http://stackoverflow.com/a/17079991/933054
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sun, Nov 10, 2013 at 5:08 PM, Igor Cicimov <ic...@gmail.com> wrote:
>
> In my experience SocketTimeoutException comes up in case of misbehaving
> browser (read IE 8 and older), i.e. the client fails to send the complete
> request and the socket timeout strikes.
interesting, thanks. This error occurs when different endusers are
accessing web application via Google Chrome on Android tablet or phone, and
Google Chrome (or Safari) on iPad.
>
> You don't provide information about the Java and OS version you are running
> your app on since this might be related to one of them (or maybe I missed
> that info).
my apologies,
JVM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08, mixed mode)
Java: version 1.7.0_45, vendor Oracle Corporation
OS: Microsoft Windows Server 2008 R2 64-bit
> For Sun Java for example you can try the following:
>
> -Dsun.net.client.defaultReadTimeout=1800000
>
> which will increase the socket timeout to 30 minutes lets say if the
> default one is not enough in case or slow client. Another thing to check is
> your OS socket timeout setting, on linux systems for example:
>
> net.ipv4.tcp_keepalive_time = 300
>
> and try adjusting it according to your needs.
>
noted, thanks.
>
> Would love to hear some other people experiences and thoughts regarding
> this as well, this is really annoying one to troubleshoot.
>
agreed/ditto. thanks for your response.
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by Igor Cicimov <ic...@gmail.com>.
On Mon, Nov 11, 2013 at 1:25 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
> smithh032772@gmail.com> wrote:
>
> > Caused by: java.net.SocketTimeoutException
> > at
> >
> org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
> > at
> >
> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
> > at
> >
> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
> >
>
> my apologies, based on this exception (above), I decided to provide you
> with the following from my tomee/conf/server.xml:
>
>
> <Connector port="8080"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" connectionTimeout="20000"
> acceptorThreadCount="2"
> redirectPort="8443" socket.directBuffer="false"/>
>
>
> I guess the answer may be the connectionTimeout="..." (above), but still
> would like to know recommendations of others based on experience with web
> application serving mobile clients. thanks.
>
In my experience SocketTimeoutException comes up in case of misbehaving
browser (read IE 8 and older), i.e. the client fails to send the complete
request and the socket timeout strikes. In this case you can't fix anything
on the server side but you say your application is used by mobile clients
so this might not be the case.
You don't provide information about the Java and OS version you are running
your app on since this might be related to one of them (or maybe I missed
that info). For Sun Java for example you can try the following:
-Dsun.net.client.defaultReadTimeout=1800000
which will increase the socket timeout to 30 minutes lets say if the
default one is not enough in case or slow client. Another thing to check is
your OS socket timeout setting, on linux systems for example:
net.ipv4.tcp_keepalive_time = 300
and try adjusting it according to your needs.
Would love to hear some other people experiences and thoughts regarding
this as well, this is really annoying one to troubleshoot.
Cheers,
Igor
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Mon, Nov 11, 2013 at 10:23 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Howard,
>
>
> I might recommend using a Filter like this:
>
> filter() {
> try {
> chain.doFilter();
> } catch (SocketTimeoutException ste) {
> application.log("Got STE for request " + request.getRequestURI()
> + with client " + request.getHeader("User-Agent"));
> }
> }
>
> ... or something like that. It might help uncover patterns in dropped
> connections.
agreed, i decided to do this (below) yesterday evening (to prevent the
stacktrace in the log file; noted your recommendation/usage of catching
SocketTimeoutException, thanks),
try {
chain.doFilter(req, res);
} catch (org.apache.catalina.connector.ClientAbortException e) {
logger.error("caught
org.apache.catalina.connector.ClientAbortException: " + e.getMessage());
}
since I already know the culprit(s); see details/explanation, below.
> Maybe Igor is right and the problem is some browser (e.g. MSIE 8) and not
> necessarily mobile clients.
>
it is the mobile device phone/internet connection that is lost, recycled,
recovered (or however you want to explain it). see below (and saved a copy
on gist[1], too).
user1 (iPad, internal verizon wireless 4G phone/internet connection)
connects and accesses login.xhtml page
70.215.84.34 - - [09/Nov/2013:13:08:20 -0500] "GET /webapp/index.jsf
HTTP/1.1" 302 -
70.215.84.34 - - [09/Nov/2013:13:08:22 -0500] "GET /webapp/login.jsf
HTTP/1.1" 200 1445
70.215.84.34 - - [09/Nov/2013:13:08:25 -0500] "GET
/webapp/javax.faces.resource/primefaces.css.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 10036
user1 (iPad); note localhost_access_log and tomcat7-stderr log lines below;
note the request filenames, date/time, and exceptions
70.215.84.34 - - [09/Nov/2013:13:09:00 -0500] "GET
/webapp/javax.faces.resource/jquery/jquery.js.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 -
70.215.84.34 - - [09/Nov/2013:13:09:00 -0500] "GET
/webapp/javax.faces.resource/jquery/jquery-plugins.js.jsf?ln=primefaces&v=4.0.3
HTTP/1.1" 200 -
Nov 09, 2013 1:09:00 PM org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery.js with library
primefaces :null
ClientAbortException: java.net.SocketTimeoutException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
Nov 09, 2013 1:09:00 PM org.apache.myfaces.application.ResourceHandlerImpl
handleResourceRequest
SEVERE: Error trying to load resource jquery/jquery-plugins.js with library
primefaces :null
ClientAbortException: java.net.SocketTimeoutException
at
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
user1 (iPad, different IP address) clicks Login button on login.xhtml, POST
to server, successful login, server redirects to index.xhtml
70.208.164.166 - - [09/Nov/2013:13:09:52 -0500] "POST /webapp/login.jsf
HTTP/1.1" 302 -
70.208.164.166 - - [09/Nov/2013:13:09:52 -0500] "GET /webapp/index.jsf
HTTP/1.1" 200 7008
Nov 09, 2013 1:09:52 PM pf.ApplicationScopeBean login
INFO: sessionId = user1B4584B981555A703B8E0DA189D2294F5
Nov 09, 2013 1:09:52 PM jsf.users.pf_UsersController loginUser
INFO: user1 (iPad) logged in at 11/09/2013 01:09 PM
user1 (iPad) GET resource, user2 initiate/GET websocket, user1 initiate/GET
websocket, respectively
70.208.164.166 - - [09/Nov/2013:13:09:53 -0500] "GET
/webapp/resources/images/loading_circleThickBox.gif?pfdrid_c=true HTTP/1.1"
304 -
166.137.105.198 - - [09/Nov/2013:13:09:53 -0500] "GET
/webapp/primepush/user27BF5C51CF354C1F4926B835CB7F2083E?X-Atmosphere-Transport=close&X-Atmosphere-tracking-id=f2a3916c-62a0-477e-b226-539857827c2e
HTTP/1.1" 200 -
70.208.164.166 - - [09/Nov/2013:13:09:54 -0500] "GET
/webapp/primepush/user1B4584B981555A703B8E0DA189D2294F5?X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.0.3-jquery&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&X-atmo-protocol=true
HTTP/1.1" 101 -
[1]
https://gist.github.com/smithh032772/7380812#file-2013-11-11-discussion_details-txt
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Howard,
On 11/10/13, 9:25 AM, Howard W. Smith, Jr. wrote:
> On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
> smithh032772@gmail.com> wrote:
>
>> Caused by: java.net.SocketTimeoutException at
>> org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
>>
>>
at
>> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
>>
>>
at
>> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
>>
>
>>
> my apologies, based on this exception (above), I decided to provide
> you with the following from my tomee/conf/server.xml:
>
>
> <Connector port="8080"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" connectionTimeout="20000" acceptorThreadCount="2"
> redirectPort="8443" socket.directBuffer="false"/>
>
>
> I guess the answer may be the connectionTimeout="..." (above), but
> still would like to know recommendations of others based on
> experience with web application serving mobile clients. thanks.
I might recommend using a Filter like this:
filter() {
try {
chain.doFilter();
} catch (SocketTimeoutException ste) {
application.log("Got STE for request " + request.getRequestURI()
+ with client " + request.getHeader("User-Agent"));
}
}
... or something like that. It might help uncover patterns in dropped
connections. Maybe Igor is right and the problem is some browser (e.g.
MSIE 8) and not necessarily mobile clients.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSgPZaAAoJEBzwKT+lPKRYhQoQAKgd26kNQJzv+9GDrJLlDTWk
1c0GCYjLT6ckC4J5cUbnStznl8OeGg6Qyxvk9uN02WKUNtAqfWbbd7LE7B/0zoZp
UiM88GmhMWZNG2ezsX2pn9yJ0CNqTLkVmPPLf6vyxC/FACXb10ACM0MOeCKHQ+pb
+IsX0IPfyvz3TieLWM89cJboHAHn/4Pt6yBvdi/6IBzD8jKzOk1XsGcfwP2Qwq6j
up1U6oer2T6AidhNIrZ1yUStFe1vIujh3FwCmRM9FIgDNeeIrBPkOzMG8TTDju7a
Z7Q1h3xu7gtbh6r/zSM9uj9q2SaunJorOVISrwINZTRSm19UMafzUEzUz6Mz3KNw
XJzVV7Q3gez2pbKwwxOkBlmqXx2JTFPk2Q6Llwddcg7rx5XWg7MOyM/JuYOaQcby
h/ZIkOltZDP9AA2JJMaitay+GJIZiZu0B9ZXtD4snGkZt4+4VouRQi0LE9lNOVgH
8I4W3tcQAo/CExufvtQVJQk/QwE+DFbBtPdNua99qBrtiubtBOHJHTMMMseaj6Ic
cyzGzGR6Y7xOGHb4RzxnjLTFuBLTfsmNC9P2f3362MICIMnMpGQBIrkIydzhIsPI
KEC+gvoS9J1V1JUzwCjwCY3AZc6d7YjF0ubChdjcN5Is3dLECkE1UCiPCNXRiTS/
0YR4TBnfnzIBMlvqY5+D
=ogzq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Avoiding/Handling SocketTimeoutException(s) when web application
serving resources to mobile clients
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Sun, Nov 10, 2013 at 9:14 AM, Howard W. Smith, Jr. <
smithh032772@gmail.com> wrote:
> Caused by: java.net.SocketTimeoutException
> at
> org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:127)
> at
> org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:174)
> at
> org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:163)
>
my apologies, based on this exception (above), I decided to provide you
with the following from my tomee/conf/server.xml:
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" connectionTimeout="20000"
acceptorThreadCount="2"
redirectPort="8443" socket.directBuffer="false"/>
I guess the answer may be the connectionTimeout="..." (above), but still
would like to know recommendations of others based on experience with web
application serving mobile clients. thanks.