Tomcat and filter servlet

Discussion in 'Java' started by pvsnmp@yahoo.com, Sep 26, 2005.

  1. Guest

    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
     
    , Sep 26, 2005
    #1
    1. Advertising

  2. Bryce Guest

    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, Sep 26, 2005
    #2
    1. Advertising

  3. dnasmars Guest

    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
     
    dnasmars, Sep 26, 2005
    #3
  4. Guest

    >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
     
    , Sep 26, 2005
    #4
  5. dnasmars Guest

    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, Sep 26, 2005
    #5
  6. Juha Laiho Guest

    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, Sep 26, 2005
    #6
  7. dnasmars Guest

    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/1.5/api/javax/servlet/SingleThreadModel.html
    my apologies :)
     
    dnasmars, Sep 27, 2005
    #7
  8. Bryce Guest

    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
     
    Bryce, Sep 27, 2005
    #8
  9. Guest

    >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
     
    , Sep 27, 2005
    #9
  10. Juha Laiho Guest

    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)
     
    Juha Laiho, Sep 27, 2005
    #10
  11. Guest

    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
     
    , Sep 28, 2005
    #11
  12. Bryce Guest

    On 27 Sep 2005 10:48:58 -0700, wrote:

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


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

    --
    now with more cowbell
     
    Bryce, Sep 28, 2005
    #12
  13. Guest

    >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
     
    , Sep 28, 2005
    #13
  14. Guest

    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
     
    , Sep 29, 2005
    #14
  15. Bryce Guest

    On 28 Sep 2005 13:59:40 -0700, wrote:

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


    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.

    --
    now with more cowbell
     
    Bryce, Sep 29, 2005
    #15
  16. Guest

    >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
     
    , Sep 29, 2005
    #16
  17. Bryce Guest

    On 29 Sep 2005 06:10:18 -0700, wrote:

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


    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.

    --
    now with more cowbell
     
    Bryce, Sep 30, 2005
    #17
  18. Guest

    Hi,
    Thanks,

    rgds,
    Prashant
     
    , Sep 30, 2005
    #18
  19. Juha Laiho wrote:
    > 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..



    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

    --
    XML is the programmer's duct tape.
     
    Raymond DeCampo, Oct 3, 2005
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sean Clarke
    Replies:
    1
    Views:
    1,902
    Sudsy
    Jan 7, 2004
  2. circuit_breaker
    Replies:
    2
    Views:
    2,021
    Jack Jia
    Apr 4, 2004
  3. Doug McCann
    Replies:
    1
    Views:
    1,045
    William Brogden
    Aug 5, 2004
  4. Replies:
    0
    Views:
    849
  5. zax75
    Replies:
    1
    Views:
    1,106
Loading...

Share This Page