Hi Dola, right off of my head, i can't come up with a smart configuration solution that would selectively swallow the message as our approach does. Our app has two shared JSPs that are included in every JSP, one at the top and one at the bottom. The top-included JSP opens the try block (making it illegal for many IDEs such as IntelliJ or similar), the bottom-included JSP contains the catch block with the handling code. (Actually, our approach differs slightly from what i described to you: Our top/bottom JSPs take care of logging everything to a central logger class and the logger class, in turn, inspects the stack trace and avoids to perform a critical logging if the stack trace looks as i described it.)
But, yes, if your hundreds of JSPs do not have two such globally shared include JSPs, then you are in some trouble and have to introduce the two include statements, one at the top and the other at the bottom. (You may want to use smart shell scripting for this...) Then, add your two top/bottom JSPs and you are done with your JSPs. And don't forget your servlet classes: If any of your web requests are served by a servlet, you have to add the try/catch block to the servlet class, too. Robert > -----Original Message----- > From: Dola Woolfe [mailto:[EMAIL PROTECTED] > Sent: Friday, October 14, 2005 8:43 AM > To: Tomcat Users List > Subject: RE: Suppress "Connection reset by peer: socket write error". > > > Hi Robert, > > What a truly fantastic answer! Very detailed and > educational. Your timeis deeply appreciated. > > What I'd like to know is: do I have to do it in every > JSP (I have hundreds). And is there a configuration > solution as was alluded by Bill previously? > > Once again, very many thanks!!! > > Dola > > --- Robert Graf-Waczenski <[EMAIL PROTECTED]> wrote: > > > Hi! > > > > First, some background: > > > > The exception your app actually gets internally is a > > SocketException with the text you mention below. > > It occurs if the client browser prematurely cancels > > an http request before tomcat has completed sending > > the full response data to the client. > > Another manifestation may be a SocketException with > > the text "Socket closed", which *may* occur if your > > app serves big download data streams and the client > > cancels the download. > > > > The bottom line is that these two exceptions simply > > happen in real life web apps and that they can be > > "safely ignored". > > > > However, you correctly want to know how your app can > > perform the magic to "safely ignore" these two > > exceptions outomatically, right? > > > > So you will need to add some error handling that > > would > > basically consist of wrapping everyting in your app > > inside a try/catch block that would swallow the > > two variants of SocketException above. But the > > problem > > with this approach is that you must not simply > > swallow > > *all* SocketExceptions. > > > > Here's what we do in our app: > > > > catch(SocketException e) { > > String stackTrace = Util.getStackTrace(e); // > > this extracts the full > > stack trace > > if ((stackTrace.indexOf("socket write error") > -1 > > || stackTrace.indexOf("Socket closed") > -1) > > && > > > > > (stackTrace.indexOf("org.apache.tomcat.service.http.HttpRespon > seAdapter" > > ) > -1 > > || > > > stackTrace.indexOf("javax.servlet.http.HttpServlet.service(") > > > -1)) > > { > > log("Client signalled end of socket > > communication"); > > } > > else > > throw e; > > } > > > > (Note that you may have to re-construct the full > > lines > > of the source code above as my mail client may have > > introduced linebreaks at bad places...) > > > > Yes, we log an error message even if this particular > > "client > > aborted request" situation was detected. You may > > want to swallow > > this silently, but i would suggest to not do this > > because you > > (and we) never are sure if the stack trace analysis > > above is > > perfect. The other down side of this approach is > > that future > > versions of Java and/or Tomcat may change the > > exception message > > texts and/or the structure of the stack trace. But > > currently > > (JDK 1.5 / Tomcat 5.5) this approach does what was > > intended. > > > > Robert > > > > > -----Original Message----- > > > From: Dola Woolfe [mailto:[EMAIL PROTECTED] > > > Sent: Friday, October 14, 2005 3:17 AM > > > To: Tomcat Users List > > > Subject: Re: Suppress "Connection reset by peer: > > socket write error". > > > > > > > > > Hi Bill, > > > > > > Thanks for your answer and sorry for the delay in > > my > > > reply! > > > > > > I'm using standalong Tomcat 5.5 listening on port > > 80. > > > I'm using jdk 1.5 on WinXP. I'm not using any > > special > > > logging. I'm running Tomcat in a console, simply > > by > > > typing "startup" in tomcat/bin. > > > > > > What I don't want happening is for the "Connection > > > reset by peer: socket write error" to be displayed > > in > > > the console window. > > > > > > Given this detailed information, would you mind > > > refining your recommendation? > > > > > > Thank you very much in advance, > > > > > > Dola Chin > > > > > > > > > > > > --- Bill Barker <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > "Dola Woolfe" <[EMAIL PROTECTED]> wrote in > > message > > > > > > > > > > news:[EMAIL PROTECTED] > > > > > Hi, > > > > > > > > > > I apologize for asking this question again for > > I > > > > > remembering asking this question in the past, > > but > > > > I > > > > > can't find the response. > > > > > > > > > > What setting (and where) will suppress the > > > > > aforementioned exception in the tomcat log? > > > > > > > > > > > > > Including the Tomcat version helps ;-). > > > > > > > > I'm assuming that this is for the AJP/1.3 > > Connector. > > > > The answer is to > > > > change the logging level for that component to > > be > > > > one higher than the level > > > > in the message (in the latest version, it's at > > DEBUG > > > > level and I don't > > > > remember what it used to be). For example, if > > you > > > > are using JDK1.4 logging > > > > you would do something like: > > > > org.apache.jk.common.level=SEVERE > > > > > > > > in your logging.properties file. > > > > > > > > > Thank you very much in advance, again! > > > > > > > > > > Dola > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > > Yahoo! Mail - PC Magazine Editors' Choice 2005 > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > Yahoo! Music Unlimited > > > Access over 1 million songs. Try it free. > > > http://music.yahoo.com/unlimited/ > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > === message truncated === > > > > > __________________________________ > Yahoo! Music Unlimited > Access over 1 million songs. Try it free. > http://music.yahoo.com/unlimited/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
