«

Hi,
If we have a filter servlet in Tomcat for a web application, does
Tomcat pass requests to the filter object one after the other, or does
it create multiple instances of filter object and the requests are
passed to the different instances of the filter?
In other words, If Req1 is intercepted by the filter and the filter
gets into some problem, (say into a while loop waiting for some signal
to break out of it), then, do subsequent requests like Req2,Req3...
have to wait until the filter breaks out of the while loop and sends
Req1 to the servlet and returns the response?

Kindly reply,

thanks and regards,
Prashant

On 26 Sep 2005 02:48:36 -0700, wrote:

>Hi,
>If we have a filter servlet in Tomcat for a web application, does
>Tomcat pass requests to the filter object one after the other, or does
>it create multiple instances of filter object and the requests are
>passed to the different instances of the filter?

They are passed in a chain, one after the other.

>In other words, If Req1 is intercepted by the filter and the filter
>gets into some problem, (say into a while loop waiting for some signal
>to break out of it), then, do subsequent requests like Req2,Req3...
>have to wait until the filter breaks out of the while loop and sends
>Req1 to the servlet and returns the response?

Yes, if the while loop never ends, the request is stuck there.

--
now with more cowbell

Bryce wrote:
> On 26 Sep 2005 02:48:36 -0700, wrote:
>
>
>>Hi,
>>If we have a filter servlet in Tomcat for a web application, does
>>Tomcat pass requests to the filter object one after the other, or does
>>it create multiple instances of filter object and the requests are
>>passed to the different instances of the filter?
>
>
> They are passed in a chain, one after the other.
>
>
>>In other words, If Req1 is intercepted by the filter and the filter
>>gets into some problem, (say into a while loop waiting for some signal
>>to break out of it), then, do subsequent requests like Req2,Req3...
>>have to wait until the filter breaks out of the while loop and sends
>>Req1 to the servlet and returns the response?
>
>
> Yes, if the while loop never ends, the request is stuck there.
if the filter servlet implements SingleThreadModel the request is stuck
there
otherwise I don't think it will.
>
> --
> now with more cowbell

>Yes, if the while loop never ends, the request is stuck there.
Hi,
I would like to know about the requests which come after req1, I
understand that Req1 would get stuck but what about req2,3,4.....
Do they all have to wait to gain access to the same filter object?

thanks & rgds,
prashant

dnasmars wrote:
> Bryce wrote:
>
>> On 26 Sep 2005 02:48:36 -0700, wrote:
>>
>>
>>> Hi,
>>> If we have a filter servlet in Tomcat for a web application, does
>>> Tomcat pass requests to the filter object one after the other, or does
>>> it create multiple instances of filter object and the requests are
>>> passed to the different instances of the filter?
>>
>>
>>
>> They are passed in a chain, one after the other.
>>
>>
>>> In other words, If Req1 is intercepted by the filter and the filter
>>> gets into some problem, (say into a while loop waiting for some signal
>>> to break out of it), then, do subsequent requests like Req2,Req3...
>>> have to wait until the filter breaks out of the while loop and sends
>>> Req1 to the servlet and returns the response?
>>
>>
>>
>> Yes, if the while loop never ends, the request is stuck there.
>
> if the filter servlet implements SingleThreadModel the request is stuck
> there
> otherwise I don't think it will.
by request I meant request2,req3 ...
>
>>
>> --
>> now with more cowbell

In other words,
if the filter servlet implements SingleThreadModel and req1 get stuck
all other requests will wait until the filter has finished with req1,
and if the filter servlet doesn't implement SingleThreadModel
if req1 is stuck other requests will be served by the filter

I hope it's clearer then the first time

dnasmars <> said:
>if the filter servlet implements SingleThreadModel and req1 get stuck
>all other requests will wait until the filter has finished with req1,
>and if the filter servlet doesn't implement SingleThreadModel
>if req1 is stuck other requests will be served by the filter

Hmm.. doesn't the SingleThreadModel just limit that a single instance
of a servlet is only given to a single thread at a time -- but that
simultaneously, the container is fully allowed to create multiple
instances of any given servlet (and could be especially prone to
do this for servlets implementing SingleThreadModel)?
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho wrote:
> dnasmars <> said:
>
>>if the filter servlet implements SingleThreadModel and req1 get stuck
>>all other requests will wait until the filter has finished with req1,
>>and if the filter servlet doesn't implement SingleThreadModel
>>if req1 is stuck other requests will be served by the filter
>
>
> Hmm.. doesn't the SingleThreadModel just limit that a single instance
> of a servlet is only given to a single thread at a time -- but that
> simultaneously, the container is fully allowed to create multiple
> instances of any given servlet (and could be especially prone to
> do this for servlets implementing SingleThreadModel)?

you are right it's in deed what is written in the API spec
http://java.sun.com/webservices/docs...readModel.html
my apologies

On Mon, 26 Sep 2005 20:27:50 +0000 (UTC), Juha Laiho
<> wrote:

>dnasmars <> said:
>>if the filter servlet implements SingleThreadModel and req1 get stuck
>>all other requests will wait until the filter has finished with req1,
>>and if the filter servlet doesn't implement SingleThreadModel
>>if req1 is stuck other requests will be served by the filter
>
>Hmm.. doesn't the SingleThreadModel just limit that a single instance
>of a servlet is only given to a single thread at a time -- but that
>simultaneously, the container is fully allowed to create multiple
>instances of any given servlet (and could be especially prone to
>do this for servlets implementing SingleThreadModel)?

But the OP was talking about Filters not Servlets (even though he
calls them Filter Servlets)

--
now with more cowbell

>But the OP was talking about Filters not Servlets (even though he
>calls them Filter Servlets)
Yes, I am talking about filters and i guess they are also servlets.
If the filter doesnt implement singlethreadmodel , then what will
happen?
Will multiple requests go through different copies of filter object?
What does actually happen? Some explanation with physical
interpretation (like if multiple copies of filter object are made in
memory ) would be helpful.

thanks and rgds,
Prashant

said:
>>But the OP was talking about Filters not Servlets (even though he
>>calls them Filter Servlets)
>Yes, I am talking about filters and i guess they are also servlets.
>If the filter doesnt implement singlethreadmodel , then what will
>happen?
>Will multiple requests go through different copies of filter object?
>What does actually happen? Some explanation with physical
>interpretation (like if multiple copies of filter object are made in
>memory ) would be helpful.

Ouch; didn't check the specs last time to check whether filters
are anyhow related to servlets, and actually I am too tired to do it
now, either.

Here's how it goes with servlets -- I don't know whether the
SingleThreadModel has any effect on filters.

- if the servlet does not implement SingleThreadModel, the servlet
engine most possibly creates just one copy of the servlet object
(the object will be created at latest at the point where it is
called for the first time during the lifetime of the application
instance; the engine is also free to let any servlet instance be
garbage collected whenever there are no active requests being
processed within the servnet instance)
- corollary: multiple threads of control may be simultaneously
executing within a single servlet instance - thus, servlets
must be coded to be thread-safe
- if the servlet does implement SingleThreadModel, then the servlet
engine will make sure that just one thread of control at a time is
executing within the service methods of the servlet -- however, the
engine is completely free to create multiple instances of the
servlet to provide for multiple simultaneous requests for the
same servlet; as above, the servlet engine is also free to let
the servlet instances be garbage collected
- here the container handles the thread-safety, to some extent at
least; I think there are some accesses (f.ex. to application
context objects) where thread-safety must be explicitly coded for

.... and writing this made me realize an interesting issue with the
destroy() method of servlet. It's commonly known that one cannot
trust that the destroy() is ever called. Now I also am aware that
when the destroy() is called, other instances of the same servlet
class may still be active. While this shouldn't be a concern in
most situations, I think this was a worthwhile discovery..
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)