users@glassfish.java.net

Re: (mod_jk?) ClientAbortException again.

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Mon, 15 Sep 2008 12:47:04 -0400

Salut,

Kristian Rink wrote:
> Salut Jeanfrancois;
>
> well, here we go again. :)
>
> Jeanfrancois Arcand schrieb:
> [...]
>> Just to (1) refresh my buffer and (2) see if I can find something :-)
>
> To refresh your buffer on that very issue and provide some info on the
> latest state of this thing, a few information:
>
> - I noticed a whole load of "ClientAbortException"s occuring in my
> application log using glassfishv2u2 and apache2+mod_proxy_http, same as it
> happened before using tomcat6+apache2+mod_jk. While some of them seem to be
> caused by MSIE 6 connection ending misbehaviour without doing any harm, some
> of them seem to cause actual trouble, blocking or ending downloads
> prematurely on user side.
>
> - After discussing this issue and trying different things more or less
> successfully, the last we did so far was to make glassfish give up on keepalive:
>
> [...]
>> It might also be caused by mod_proxy not able to buffer the file
>> completely in memory? Is mod_proxy configured to buffer files from
>> GlassFish or flush it on the fly? I think you just found something
>> interesting. Can you set the
> [...]
>> <keep-alive .. timeout-in-seconds="0"/>
> [...]
>
> ... which did indeed provide some help.
>
>
> - Using something like
>
> BrowserMatch "MSIE 6\." nokeepalive downgrade-1.0 force-response-1.0
>
> in apache2 configuration turned on or off reliably makes the error
> reproducable - having this line commented out in apache2 (mod_setenvif)
> configuration makes my MSIE browser spit out a message like "site or
> resource not available" instead of downloading the file. So keepalive seems
> part of the problem, somehow...
>
>
> - Doin' some statistics on that:
>
> * 27 ClientAbortException's captured today between 8:40 and 11:11
>
> * UAs involved: 3x Firefox 3.0.1, the rest: MSIE 6 and 7
>
> * some of them connecting using squid, some others using arcane
> (broken) proxies like my special friend AVM Ken! (...),
> most of them either using a transparent or no proxy on the
> client side
>
> * An interesting amount of downloads seems to end in this
> exception after having either 256k or 512k of data sent by
> by our severs, no matter the size of the actual file requested.

This is interesting....


>
>
> - Asides the very exceptions of course, there's no evidence of something
> awry here either in server.log or in the apache2 access / error logs.
>
>
> - To end things, the ClientAbortException as of recently seems to appear
> merrily along with this friend happening then and now when users are trying
> to upload files to our system, though I am not sure they are related to each
> other:
>
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
> Processing of multipart/form-data request failed. Stream ended unexpectedly
> [...]
> Caused by:
> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> Stream ended unexpectedly
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:964)
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
> at java.io.InputStream.read(InputStream.java:85)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
> at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> at
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:354)
> ... 48 more

OK that one I suspect is related to the same one...a time out happens
caused by either a proxy or a firewall...pouaaaa not simple to debug!


>
>
> Well... Talking about refreshing buffers, did that suffice so far? :)

This is quite good info!

Please
> feel surely free asking whenever I can provide you with more information
> helpful in tracking this down... Though it seems people aren't really
> bothered so far, I'd surely like to have it out of the way sooner or later. :)

The best thing (get ready to have a gigantic log) might be to use
wireshark or ngrep to monitor the tcp transaction between apache2 and
gf, and see if we can correlate java exception with the tcp stack
information. That's the last thing I can think of :-(


A+

-- Jeanfrancois



>
> Cheers & all the best, take care.
> Kristian
>
>