RE: Filter Chains slow first time it is called

[Paul Butcher <pa...@argogroup.com>]

All,

Many apologies if this isn't the correct list for this message. Please
point me in the right direction if I've made a mistake.

I've been experiencing problems with latency and filters in Tomcat 4
(both beta 1 and beta 5). A search of the mailing list archives showed
up the exchange summarised below, which I believe relates to the same
problem that I've been experiencing. I've done some further research,
however, and I have reason to believe that the problem may be a little
more serious than this exchange implies. I have an example which
demonstrates the problem reliably which I would be delighted to make
available if someone can tell me how to do so (I assume that attaching a
.war file to this message isn't the right way!).

Like Kevin, I've been experiencing approximately a 30 second latency
when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to
set up my filters, rather than filter chains. I experience the problem
reliably every time.

Also like Kevin, I experience different behaviour when connecting via IE
and Netscape. I have reason to believe that the problem is not with IE,
however; Netscape just copes with it slightly more gracefully. I have
also been using WAP 'phones to connect (my main aim is serving WML pages
to WAP 'phones) and they also experience latency problems.

When connecting to a filtered JSP with IE, the result isn't displayed
for approximately 30 seconds. Something then obviously times out and the
page is displayed correctly. The problem is definitely "after" the
filter has been called - I've added simple logging to my example filter
and its doFilter function completes almost immediately.

When connecting to the same page with Netscape 6, the results display
almost immediately. The connection to the server isn't closed, however
(the "N" in the top right continues to animate and the progress bar at
the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem
to time out after 30 seconds. I've not had the patience to wait long
enough to see when it does time out (its certainly in excess of a
minute).

When using a WAP 'phone, the 'phone times out with an error.

The problem only occurs if I use my filter on a JSP file. It does not
occur when the filter is used on a "plain" HTML file.

If there are any more details that I can provide, please let me know and
I'll do my best.

Thanks,

pbutcher->msgCount++

--
Team Leader, Argogroup plc
http://www.argogroup.com/


>From: "Kevin Jones" <ke...@develop.com> 
>Date: Wed, 31 Jan 2001 20:27:34 -0000 >To:
<to...@jakarta.apache.org> 
>Subject: RE: Filter Chains slow first time it is called 
>
>I've just taken a closer look at this, it's a browser problem.
>
>IE 5.5 has really trouble with content types. Even though I'm setting
the
>type to text/html (in a filter) but at some point I've used IE 5.5 to
get
>the data without the filter. The servlet returns text/xml. It seems
that
>IE5.5 is struggling to reconcile this (that's all I can think of).
>
>Netscape has no problems (for once :-) ),
>
>Kevin Jones
>DevelopMentor
>www.develop.com
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> Sent: 31 January 2001 19:21
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Filter Chains slow first time it is called
>
>
> Kevin Jones wrote:
>
> > Subject says it all really.
> >
> > The first time a filter chain is executed for a servlet, it
> takes about 30
> > seconds for the response to get back to the client.
> >
>
> It would be surprising if this is related to initializing the
> filter chain --
> after all, the chain is constructed for every single request (not just
the
> first one).  Are you sure there isn't anything application
> specific that takes
> a long time to initialize?
>
> >
> > This doesn't happen everytime but enough to be repeatable.
> >
> > I'm using Beta 1. I've set the app to be reloadable (with a
> reload time of
> > 3) and I'm logging to the console if that helps,
> >
>
> Logs and a test case (even if it doesn't repeat evey single time)
would be
> quite useful in investigating this.

RE: Filter Chains slow first time it is called

[Remy Maucherat <re...@betaversion.org>]

Quoting "Craig R. McClanahan" <cr...@apache.org>:

> On Wed, 30 May 2001, Craig R. McClanahan wrote:
> 
> > Hello Paul,
> > 
> > This definitely sounds like something wrong with Tomcat 4 -- most
> likely a
> > combination of things related to the browser (which can affect which
> HTTP
> > version is in use), your filters, and the ultimate servlet or JSP
> page
> > being called.  To help narrow things down a bit:
> > * Do you have a small test case we can use to investigate this?
> >   If so, you can send it either to TOMCAT-DEV or to me in private
> mail.
> > * Are your clients using HTTP/1.0 or HTTP/1.1?
> > * Does your filter create a wrapper on the servlet response, or is it
> >   just passing things through?
> > 
> > I suspect that somewhere along the line the output stream isn't
> getting
> > flushed or closed in a timely manner -- the above information will be
> > helpful to be able to identify where.
> > 
> > Craig
> 
> I just added some more unit tests that do output filtering, and they
> all
> work immediately.  I now more strongly suspect that this problem is
> related to some combination of using HTTP/1.1, the particular filters
> and
> wrappers being executed, and Tomcat not flushing something somewhere
> when
> it is supposed to -- but a real-life example would be tremendously
> helpful
> in tracking it down further.

I suspect it's a special case problem. I quickly tried with the FilterExample 
in the examples webapp (which does not actually wrap anything), and it works ok.

Remy

RE: Filter Chains slow first time it is called

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 30 May 2001, Craig R. McClanahan wrote:

> Hello Paul,
> 
> This definitely sounds like something wrong with Tomcat 4 -- most likely a
> combination of things related to the browser (which can affect which HTTP
> version is in use), your filters, and the ultimate servlet or JSP page
> being called.  To help narrow things down a bit:
> * Do you have a small test case we can use to investigate this?
>   If so, you can send it either to TOMCAT-DEV or to me in private mail.
> * Are your clients using HTTP/1.0 or HTTP/1.1?
> * Does your filter create a wrapper on the servlet response, or is it
>   just passing things through?
> 
> I suspect that somewhere along the line the output stream isn't getting
> flushed or closed in a timely manner -- the above information will be
> helpful to be able to identify where.
> 
> Craig
> 

I just added some more unit tests that do output filtering, and they all
work immediately.  I now more strongly suspect that this problem is
related to some combination of using HTTP/1.1, the particular filters and
wrappers being executed, and Tomcat not flushing something somewhere when
it is supposed to -- but a real-life example would be tremendously helpful
in tracking it down further.

Craig


> 
> On Wed, 30 May 2001, Paul Butcher wrote:
> 
> > All,
> > 
> > Many apologies if this isn't the correct list for this message. Please
> > point me in the right direction if I've made a mistake.
> > 
> > I've been experiencing problems with latency and filters in Tomcat 4
> > (both beta 1 and beta 5). A search of the mailing list archives showed
> > up the exchange summarised below, which I believe relates to the same
> > problem that I've been experiencing. I've done some further research,
> > however, and I have reason to believe that the problem may be a little
> > more serious than this exchange implies. I have an example which
> > demonstrates the problem reliably which I would be delighted to make
> > available if someone can tell me how to do so (I assume that attaching a
> > .war file to this message isn't the right way!).
> > 
> > Like Kevin, I've been experiencing approximately a 30 second latency
> > when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to
> > set up my filters, rather than filter chains. I experience the problem
> > reliably every time.
> > 
> > Also like Kevin, I experience different behaviour when connecting via IE
> > and Netscape. I have reason to believe that the problem is not with IE,
> > however; Netscape just copes with it slightly more gracefully. I have
> > also been using WAP 'phones to connect (my main aim is serving WML pages
> > to WAP 'phones) and they also experience latency problems.
> > 
> > When connecting to a filtered JSP with IE, the result isn't displayed
> > for approximately 30 seconds. Something then obviously times out and the
> > page is displayed correctly. The problem is definitely "after" the
> > filter has been called - I've added simple logging to my example filter
> > and its doFilter function completes almost immediately.
> > 
> > When connecting to the same page with Netscape 6, the results display
> > almost immediately. The connection to the server isn't closed, however
> > (the "N" in the top right continues to animate and the progress bar at
> > the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem
> > to time out after 30 seconds. I've not had the patience to wait long
> > enough to see when it does time out (its certainly in excess of a
> > minute).
> > 
> > When using a WAP 'phone, the 'phone times out with an error.
> > 
> > The problem only occurs if I use my filter on a JSP file. It does not
> > occur when the filter is used on a "plain" HTML file.
> > 
> > If there are any more details that I can provide, please let me know and
> > I'll do my best.
> > 
> > Thanks,
> > 
> > pbutcher->msgCount++
> > 
> > --
> > Team Leader, Argogroup plc
> > http://www.argogroup.com/
> > 
> > 
> > >From: "Kevin Jones" <ke...@develop.com> 
> > >Date: Wed, 31 Jan 2001 20:27:34 -0000 >To:
> > <to...@jakarta.apache.org> 
> > >Subject: RE: Filter Chains slow first time it is called 
> > >
> > >I've just taken a closer look at this, it's a browser problem.
> > >
> > >IE 5.5 has really trouble with content types. Even though I'm setting
> > the
> > >type to text/html (in a filter) but at some point I've used IE 5.5 to
> > get
> > >the data without the filter. The servlet returns text/xml. It seems
> > that
> > >IE5.5 is struggling to reconcile this (that's all I can think of).
> > >
> > >Netscape has no problems (for once :-) ),
> > >
> > >Kevin Jones
> > >DevelopMentor
> > >www.develop.com
> > >
> > > -----Original Message-----
> > > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > > Sent: 31 January 2001 19:21
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: Re: Filter Chains slow first time it is called
> > >
> > >
> > > Kevin Jones wrote:
> > >
> > > > Subject says it all really.
> > > >
> > > > The first time a filter chain is executed for a servlet, it
> > > takes about 30
> > > > seconds for the response to get back to the client.
> > > >
> > >
> > > It would be surprising if this is related to initializing the
> > > filter chain --
> > > after all, the chain is constructed for every single request (not just
> > the
> > > first one).  Are you sure there isn't anything application
> > > specific that takes
> > > a long time to initialize?
> > >
> > > >
> > > > This doesn't happen everytime but enough to be repeatable.
> > > >
> > > > I'm using Beta 1. I've set the app to be reloadable (with a
> > > reload time of
> > > > 3) and I'm logging to the console if that helps,
> > > >
> > >
> > > Logs and a test case (even if it doesn't repeat evey single time)
> > would be
> > > quite useful in investigating this.
> > 
> 
> 
> 

RE: Filter Chains slow first time it is called

["Craig R. McClanahan" <cr...@apache.org>]

Hello Paul,

This definitely sounds like something wrong with Tomcat 4 -- most likely a
combination of things related to the browser (which can affect which HTTP
version is in use), your filters, and the ultimate servlet or JSP page
being called.  To help narrow things down a bit:
* Do you have a small test case we can use to investigate this?
  If so, you can send it either to TOMCAT-DEV or to me in private mail.
* Are your clients using HTTP/1.0 or HTTP/1.1?
* Does your filter create a wrapper on the servlet response, or is it
  just passing things through?

I suspect that somewhere along the line the output stream isn't getting
flushed or closed in a timely manner -- the above information will be
helpful to be able to identify where.

Craig


On Wed, 30 May 2001, Paul Butcher wrote:

> All,
> 
> Many apologies if this isn't the correct list for this message. Please
> point me in the right direction if I've made a mistake.
> 
> I've been experiencing problems with latency and filters in Tomcat 4
> (both beta 1 and beta 5). A search of the mailing list archives showed
> up the exchange summarised below, which I believe relates to the same
> problem that I've been experiencing. I've done some further research,
> however, and I have reason to believe that the problem may be a little
> more serious than this exchange implies. I have an example which
> demonstrates the problem reliably which I would be delighted to make
> available if someone can tell me how to do so (I assume that attaching a
> .war file to this message isn't the right way!).
> 
> Like Kevin, I've been experiencing approximately a 30 second latency
> when using filters in Tomcat. Unlike Kevin, I'm using URI patterns to
> set up my filters, rather than filter chains. I experience the problem
> reliably every time.
> 
> Also like Kevin, I experience different behaviour when connecting via IE
> and Netscape. I have reason to believe that the problem is not with IE,
> however; Netscape just copes with it slightly more gracefully. I have
> also been using WAP 'phones to connect (my main aim is serving WML pages
> to WAP 'phones) and they also experience latency problems.
> 
> When connecting to a filtered JSP with IE, the result isn't displayed
> for approximately 30 seconds. Something then obviously times out and the
> page is displayed correctly. The problem is definitely "after" the
> filter has been called - I've added simple logging to my example filter
> and its doFilter function completes almost immediately.
> 
> When connecting to the same page with Netscape 6, the results display
> almost immediately. The connection to the server isn't closed, however
> (the "N" in the top right continues to animate and the progress bar at
> the bottom doesn't reach 100%). Unlike IE, the connection doesn't seem
> to time out after 30 seconds. I've not had the patience to wait long
> enough to see when it does time out (its certainly in excess of a
> minute).
> 
> When using a WAP 'phone, the 'phone times out with an error.
> 
> The problem only occurs if I use my filter on a JSP file. It does not
> occur when the filter is used on a "plain" HTML file.
> 
> If there are any more details that I can provide, please let me know and
> I'll do my best.
> 
> Thanks,
> 
> pbutcher->msgCount++
> 
> --
> Team Leader, Argogroup plc
> http://www.argogroup.com/
> 
> 
> >From: "Kevin Jones" <ke...@develop.com> 
> >Date: Wed, 31 Jan 2001 20:27:34 -0000 >To:
> <to...@jakarta.apache.org> 
> >Subject: RE: Filter Chains slow first time it is called 
> >
> >I've just taken a closer look at this, it's a browser problem.
> >
> >IE 5.5 has really trouble with content types. Even though I'm setting
> the
> >type to text/html (in a filter) but at some point I've used IE 5.5 to
> get
> >the data without the filter. The servlet returns text/xml. It seems
> that
> >IE5.5 is struggling to reconcile this (that's all I can think of).
> >
> >Netscape has no problems (for once :-) ),
> >
> >Kevin Jones
> >DevelopMentor
> >www.develop.com
> >
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
> > Sent: 31 January 2001 19:21
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: Filter Chains slow first time it is called
> >
> >
> > Kevin Jones wrote:
> >
> > > Subject says it all really.
> > >
> > > The first time a filter chain is executed for a servlet, it
> > takes about 30
> > > seconds for the response to get back to the client.
> > >
> >
> > It would be surprising if this is related to initializing the
> > filter chain --
> > after all, the chain is constructed for every single request (not just
> the
> > first one).  Are you sure there isn't anything application
> > specific that takes
> > a long time to initialize?
> >
> > >
> > > This doesn't happen everytime but enough to be repeatable.
> > >
> > > I'm using Beta 1. I've set the app to be reloadable (with a
> > reload time of
> > > 3) and I'm logging to the console if that helps,
> > >
> >
> > Logs and a test case (even if it doesn't repeat evey single time)
> would be
> > quite useful in investigating this.
>