 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2005Tomcat and filter servlet
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 >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 >>Hi, >>If we have a filter servlet in Tomcat for a web application, does [quoted text clipped - 11 lines] > > 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 >>> Hi, >>> If we have a filter servlet in Tomcat for a web application, does [quoted text clipped - 15 lines] > 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 dnasmars <dnasmars@free.fr> 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)?  SignatureWolf 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) > dnasmars <dnasmars@free.fr> said: > [quoted text clipped - 8 lines] > 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 <dnasmars@free.fr> said: >>if the filter servlet implements SingleThreadModel and req1 get stuck [quoted text clipped - 7 lines] >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 pvsnmp@yahoo.com said: >>But the OP was talking about Filters not Servlets (even though he >>calls them Filter Servlets) [quoted text clipped - 5 lines] >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.. SignatureWolf 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) > pvsnmp@yahoo.com said: > [quoted text clipped - 43 lines] > 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 SignatureXML is the programmer's duct tape. >>But the OP was talking about Filters not Servlets (even though he >>calls them Filter Servlets) [quoted text clipped - 5 lines] >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 >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 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 >>Wrong assumption. Filters are not Servlets. A Filter implements the >>interface javax.servlet.Filter. There's no way to specify that its a [quoted text clipped - 7 lines] >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 >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 >>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. [quoted text clipped - 3 lines] >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 Hi, Thanks, rgds, Prashant >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 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.