Thanks, Peter, I'll pass that on. I did talk to one of our developers, who said this about the "Connection Reset by Peer" exception...
"'Connection reset by peer' indicates that the other endpoint (the client in this case) sent a packet with the RST flag set. What we're seeing is the server sending a packet with FIN/ACK flags set, i.e. the server is closing the socket." It sounds like you're on to something. We're using Apache; why would it close an existing HTTP connection? (I'm a database guy; to me sockets are found on the wall.) == Ross == -----Original Message----- From: A mailing list for discussion about Sun Microsystem's Java Servlet API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Fournier Peter Sent: Tuesday, March 05, 2002 8:51 AM To: [EMAIL PROTECTED] Subject: Re: Connection reset by peer... Me, too! <blindfold mode=on/> Try lowering the Connection timeout on your webserver and monitor how saturated it is. Sounds like it is the webserver. Pete Fournier ----Original Message----- >From: Ross Lambert <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subj: Re: Connection reset by peer... Me, too! >Reply To: "A mailing list for discussion about Sun Microsystem's Java Servlet API Technology." <[EMAIL PROTECTED]> >Sent: Tuesday, March 05, 2002 11:29 AM > >Folks, > >This is a shot in the dark as I am not one of the developers working >directly on the issue, thus I don't have the details I know you'd need to >make serious code-level recommendations. However, this is so significant to >our company's future that I figured it was worth risking a blindfolded >exchange of gunfire in a room full of Java developers. :-) > >I guess I'm really just trolling to see if anyone has seen anything >similar... and hopefully how they fixed it. > >My company is an application service provider of eCRM and customer service >software. We use servlets and supporting classes server-side and applets >client-side (for both customer service agents and customers). Our production >environments are getting a little long in the tooth, namely JRun 2.3 and JDK >1.2.2 with Oracle 8.1.7 on the back-end. > >The problem is that under extremely heavy load, connections between the >applet clients and the servers are dropping en masse. Our company is >currently experiencing wonderful growth (we handled over two million managed >chats last month, for example), but as you can imagine this issue seriously >undermines our future potential. > >Thanks for whatever advice or even comiseration you can provide. :-) > >== Ross == > > >I just noticed Suresh's post and I am inclined to believe that we are >experiencing similar difficulties, therefore I put this message in the same >thread. > > >-----Original Message----- >From: A mailing list for discussion about Sun Microsystem's Java Servlet >API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of >Suresh Addagalla >Sent: Thursday, January 31, 2002 11:00 PM >To: [EMAIL PROTECTED] >Subject: Connection reset by peer > > >Hi, > >I am using JRun 3.0 with iPlanet 4.1 on HP-UX. It's a pure servlet based >application. I am simulating a high load on the web application. Beyond a >threshold load (of 1200 users), I am getting the following 'Connection reset >by peer' error in the default-event.log, due to which I am getting 503 >result codes at the client. > >The maximum simultaneous requests configured in iPlanet is 2500, which is >sufficient. Please let me know what could be the cause of the error. The >JRun min, active, max threads are 100, 200, 2000 respectively. > >02/01 11:06:48 error (jcp) Connection reset by peer: Connection reset by >peer [java.net.SocketException: Connection reset by peer: Connection reset >by peer] >java.net.SocketException: Connection reset by peer: Connection reset by peer > at java.net.SocketInputStream.socketRead(Native Method) > at java.net.SocketInputStream.read(Unknown Source) > at java.io.BufferedInputStream.fill(Unknown Source) > at java.io.BufferedInputStream.read1(Unknown Source) > at java.io.BufferedInputStream.read(Unknown Source) > at allaire.jrun.jrpp.ProxyEndpoint.readFully(ProxyEndpoint.java:310) > at allaire.jrun.jrpp.ProxyEndpoint.readFully(ProxyEndpoint.java:302) > at allaire.jrun.jrpp.ProxyEndpoint.readInt(ProxyEndpoint.java:320) > at >allaire.jrun.jrpp.ProxyEndpoint.readRequest(ProxyEndpoint.java:188) > at allaire.jrun.jrpp.ProxyService.swapRunnable(ProxyService.java:48) > at allaire.jrun.ThreadPool.swapRunnable(ThreadPool.java:223) > at allaire.jrun.WorkerThread.run(WorkerThread.java:77) > >Thanks in advance, >Suresh > >___________________________________________________________________________ >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body >of the message "signoff SERVLET-INTEREST". > >Archives: http://archives.java.sun.com/archives/servlet-interest.html >Resources: http://java.sun.com/products/servlet/external-resources.html >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
