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.
- 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
Well... Talking about refreshing buffers, did that suffice so far? :) 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. :)
Cheers & all the best, take care.
Kristian
--
Kristian Rink
cell : +49 176 2447 2771
business: http://www.planconnect.de
personal: http://pictorial.zimmer428.net
"we command the system. calling all recievers.
we are noisy people for a better living".
(covenant - "monochrome")