Tomcat and filter servlet

[pvsnmp]

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

 

[Bryce]

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.

 

[dnasmars]

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




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.

 

[pvsnmp]

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]

if the filter servlet implements SingleThreadModel the request is stuck
there
otherwise I don't think it will.

by request I meant request2,req3 ...
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

 

[Juha Laiho]

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)?

 

[dnasmars]

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/1.5/api/javax/servlet/SingleThreadModel.html
my apologies

 

[Bryce]

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)

 

[pvsnmp]

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

 

[Juha Laiho]

(e-mail address removed) said:

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..

 

[eunever32]

I would think you have a pool of Tomcat threads
each of which will get stuck (depending on the type of requests being
submitted)

Eventually when all threads get stuck the server will be unavailable

 

[Bryce]

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.

Wrong assumption. Filters are not Servlets. A Filter implements the
interface javax.servlet.Filter. There's no way to specify that its a
single threaded model, or otherwise.

If you get into an infinite loop, that request will never make it to
the Servlet (or back to the requestor if you are stuck after the
doFilter()).

 

[pvsnmp]

Wrong assumption. Filters are not Servlets. A Filter implements the

interface javax.servlet.Filter. There's no way to specify that its a
single threaded model, or otherwise.
If you get into an infinite loop, that request will never make it to
the Servlet (or back to the requestor if you are stuck after the
doFilter()).

Hi ,
thanks for correcting me,
But can you please tell me what happens with the subsequent requests
after the filter gets into infinite loop?

thanks and rgds,
Prashant

 

[pvsnmp]

Hi,
This is what I am trying to do . Can someone tell me if i will ever see
the counter increase to more than 1. There are no other filters. The
chain.doFilter(req,res) will send the request to the destined servlet.
.......................................................................................
import java.lang.*;
import java.net.*;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;

public class Chameleon implements Filter{
static ThreaCounter tc;

public void init(FilterConfig conf) throws ServletException{
tc=new ThreadCounter();
}

public void doFilter(ServletRequest req, ServletResponse
res,FilterChain chain) throws IOException, ServletException{
tc.thrd_Incre(true);
chain.doFilter(req,res);
tc.thrd_Incre(false);
}

public void destroy(){
}
}


class ThreadCounter{
int thrd_num;

public ThreadCounter(){
thrd_num=0;
}

synchronized void thrd_Incre(boolean add){
if(add){
thrd_num++;
}
else{
thrd_num--;
}
}
}
..................................................................................

rgds,
Prashant

 

[Bryce]

Hi ,
thanks for correcting me,
But can you please tell me what happens with the subsequent requests
after the filter gets into infinite loop?

I've never used the Single THreaded Model, so I don't konw about that.
In a Normal Servlet, each request is handled by its own thread.
Subsequent requests will get through..

Note: There's a finite number of threads, so if it happens on every
request, eventually, it will make your app non-responsive.

 

[pvsnmp]

I've never used the Single THreaded Model, so I don't konw about that.

In a Normal Servlet, each request is handled by its own thread.
Subsequent requests will get through..

Hi,
Does your explanation above apply to the case when there is a filter
before the servlet?I am not using SingleThreadedModel either.

rgds,
Prashant

 

[Bryce]

Hi,
Does your explanation above apply to the case when there is a filter
before the servlet?I am not using SingleThreadedModel either.

Yes.

A filter wraps around a servlet. Take the following Filter:

public class MyFilter implements Filter {
public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain) {

System.out.println("Before Servlet");

chain.doChain(request, response);

System.out.println("After Servlet");
}
}

The first part is executed before the servlet is run, and the last
part after.

Do this experiment.

1. Load the FIlter and Servlet in your favorite IDE.
2. Run Tomcat in Debug mode.
3. Put a break point somewhere in your Servlet.
4. Take a look at the stack trace.

You should see your Filter down in the stack trace... What does this
tell you?

With a Filter you can:
Do processing prior to executing the Servlet
Do post processing on the response after executing the servlet.

Hope this helps.

 

[pvsnmp]

Hi,
Thanks,

rgds,
Prashant

 

[Raymond DeCampo]

(e-mail address removed) said:



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..

The specification guarantees (in the non-SingelThreadModel) that only
one instance of the servlet is instantiated (per configuration in web.xml).

So you do not need to worry about multiple destroy() calls.

HTH,
Ray