 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005Tomcat , filter and persistent connections
Hi, What will happen in the following scenario, A client establishes HTTP/1.1 persistent connection with Tomcat. The web application to which the request is destined has a filter configured . The client sends multiple requests over the same socket connection to Tomcat server. Will tomcat invoke the doFilter() method of the filter code multiple times for the different requests or will the Filter code also get the requests in a pipelined fashion? Another question is , a client sends a request to Tomcat, and the requested application has a filter configured for it, When the filter code is being executed if the client disconnects the connection to Tomcat , what will happen to the execution of filter code, will it stop? rgds, Prashant > Hi, > What will happen in the following scenario, A client establishes [quoted text clipped - 13 lines] > rgds, > Prashant > What will happen in the following scenario, A client establishes > HTTP/1.1 persistent connection with Tomcat. The web application to [quoted text clipped - 3 lines] > code multiple times for the different requests or will the Filter code > also get the requests in a pipelined fashion? The HTTP transport level is irrelevant in the behavior of a servlet container with respect to servlets. Therefore, the Filter will be invoked and complete separately for each request. Because the requests are serialized on one connection, you do get the guarantee that each one will complete before the next one. However, you really shouldn't design for this condition. > Another question is , a client sends a request to Tomcat, and the > requested application has a filter configured for it, When the filter > code is being executed if the client disconnects the connection to > Tomcat , what will happen to the execution of filter code, will it > stop? What will typically happen (filter or not) is that an IOException will be thrown on the next attempt to read from or write to the underlying request/response streams.  Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >What will typically happen (filter or not) is that an IOException will >be thrown on the next attempt to read from or write to the underlying >request/response streams. >Chris Smith - Lead Software Developer/Technical Trainer >MindIQ Corporation Hi, Thanks very much for the explanation rgds, Prashant > >What will typically happen (filter or not) is that an IOException will > >be thrown on the next attempt to read from or write to the underlying > >request/response streams. > Thanks very much for the explanation I'm afraid I was a little inaccurate, though. Let me expand. The IOException will be thrown on the next attempt to read from or write to the underlying sockets. That may or may not be the next attempt to read/write the streams. If the streams are buffered, then the exception may occur at any point in the future. If you don't mind committing the response and you have some special reason that a disconnect may have occurred such as after a long delay, you could just flush the output stream to be sure. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation 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.