Salut Jeanfrancois, all;
Jeanfrancois Arcand schrieb:
> 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?
For what I see, the default behaviour is sending it out on the fly but I
will check back on that the next days.
> I think you just found something
> interesting. Can you set the
>
> <keep-alive .. timeout-in-seconds="0"/>
>
> in domain.xml. What it will do is to force mod_proxy to not re-use the
> connection, but instead open a new connection on every request. This is
> not the perfect configuration (increase network latency), but at least
> mod_proxy will not close a connection when GlasFish is writing some bytes.
Overally, I seem to have made some progression:
- I managed to get hold of a customers technician who reported that, on a
client machine on which MSIE used to cause this issue, Firefox did work fine.
- Disabling the KeepAlive in glassfish made things drastically better
inasmuch as that by then it seems that (a) less users and (b) only a few
MSIE browsers are affected by that problem.
- Playing around with the SetEnvIf module in apache2, doing strict settings
for "older" MSIE browsers according to some resources out there on the web,
I seem to have almost eliminated problems by today - just 19 of these
exceptions during the past six hours, and so far it seems no one really
complained (after all MSIE seems to cause ClientAbortExceptions sometimes
also in situations in which the transmission has successfully finished):
BrowserMatch "MSIE 6\." nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "MSIE 5\." nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "MSIE 4\." nokeepalive downgrade-1.0 force-response-1.0
So hope again after all? I'm carefully optimistic, gonna watch things the
next couple of days, talk to some users and see how we will come along.
Surely hoping for the best. Adding to that, however, it should be noted that
these issues never arose in "regular" usage (i.o.w. sending static/dynamic
HTML content, images, CSS, that kind of stuff). The issue just started to
arise as files to be transmitted somewhat increase - in case of our XLS
files, 5 .. 10 megs are pretty common these days, and, talking about some of
the document packages (.zip files created on a scratch disk space on user
request and then sent via HTTP response), we're easily next to 250 .. 300
megs per package. Pretty rough stuff I guess. :)
Anyway, so far thanks for your extensive support on that, hope to mainly be
through now. :) Let's wait and see...
Cheers & all the best,
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")