-none- 2007-08-15 - By Frank W. Zammetti
Back
Just as another tidbit in the pot, I get these errors frequently with
Websphere, both with and without a web server in front of it, and also
both with and without a proxy involved, so it's definitely not
Tomcat-specific, nor is it definitively anything involving a proxy
(although both could somehow be contributing factors in this particular
case).
One thing we did notice is that the problem was more frequent when we
started using Dojo... now, I'm not blaming Dojo, but I wonder if maybe
its something along the lines of the browser opening a connection to see
if a particular JS file is fresh, then determining the local copy is
fresh, and instead of properly closing the connection it somehow aborts
it incorrectly... that wouldn't in the least surprise me with IE...
although you'd expect to see that error all the time, so I don't know,
maybe it's the way Dojo's package/import system works. Just an
observation though.
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@(protected)
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
Rainer Jung wrote:
> Kristian Rink wrote:
>> Ronald;
>>
>> [Ronald Klop <ronald-mailinglist@(protected)> @ Wed, 15 Aug 2007 09:56:59
>> +0200 (CEST)]
>>
>>> ClientAbortException means the user canceled the download (the
>>> 'client aborted'). There is nothing you can do about that on the
>>> server.
>>
>> I thought so. However, there are two things:
>>
>> (a) I was unsure whether, in a proxied environment, a
>> "ClientAbortException" means download canceled by the actual (external)
>> "client" or by the proxy server (which is directly accessing the
>> backend tomcat).
>
> OK, the proxy in your case is a reverse proxy. The exception in the
> tomcat logs could theretically come from a communication failure back to
> the reverse proxy, or from a failure from the reverse proxy back to the
> client=browser. In the latter case, the reverse proxy would not accept
> any more traffic from the tomcat and thus indirectly lead to the same
> exception.
>
> When using mod_jk, it will log problems during sending back data to the
> client=browser. That way you would know, on which part of the net the
> original problem is located.
>
> By logging response times in your Apache access log and redundantly in
> your Tomcat access log (at least until you solved or understood the
> cause of the problem), you can also find out, how long the response took
> from the perspective of Apache and of Tomcat, and if the duration is
> close to some configured timeout interval. The pattern for response
> times if "%D", which means microseconds with Apache httpd and
> milliseocond swith Tomcat. From the mod_jk log and the access log
> duration information you might even be able to determine, which requests
> had the problem (this is not easy and if you've got high load, it's
> difficult). I would suggest using mod_jk 1.2.25. It will log millisecond
> timestamps and has a couple further stability improvements. You wrote
> about version 1.2.29 which does not exist, upgrading should be no problem.
>
> JK has a couple of timeouts additionally to the Apache httpd timeout.
> They are described at
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>
>> (b) In none of the cases I watched so far, some user consciously /
>> actively stopped a download in progress - all reported that either the
>> "download finished" but ended up with an empty / small / corrupted file
>> or an error message showed up - or nothing happened at all. :(
>>
>> I am not really sure who's to blame for that... :/
>
> I would really try to look at the response handling times, the URLs for
> which it is happening, the client IPs and User Agent types to check, if
> there are any obvious patterns.
>
> In case you can finally reproduce the problem with low load, you can
> switch jk log level to debug or even trace. Then the log file will
> include full packet and header dumps. This is not a good idea for high
> traffic production though.
>
> Regards,
>
> Rainer
>
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
> To start a new topic, e-mail: users@(protected)
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
>
>
>
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
