Hi All,
I've met that problem before and was able to overcome it with a few
solutions.
One is what Peter Fournier mentioned about increasing the timeout.
Here's the thing though. When you implement a socket. That socket listens
forever by default (by calling getXXX on the socket). Therefore, you are in
a wait state forever, (notice any socket programs that hangs and theirs ur
culprit. Therefore, it isnt really increasing the timeout, it's DECREASING
it. Set the SO_TIMEOUT to do this.
2. When sending a stream, sometimes the socket doesnt send
termination. The reader will then try to read and end up having an error.
So, use the ready method of the BufferedReader before doing a read. This
will test for a closed socket as well (I think). If it does end up being
close (could be lack of resources as mentioned before) you may want to
reopen it.
3. You might consider using JMS instead of sockets when handling
alot of sockets. Everytime that a client socket connects to the Server
socket, you are creating a thread for that socket (presumably) this could
cause problems with system resources. I wrote a load tester for one of my
socket apps and it started giving me the errors that you saw by about 1000
threads on a 128MB server machine. On the client side, we were seeing
outofmemory exceptions. But when I changed to the JMS way of doing it, I
could handle 2000 no problems.
Of course there's a learning curve with JMS but there are alot of
ready made JMS chat applications.
I realize that might not be a consideration for you're company but
it's definitely worth the research.
I think javaworld had an article on that versus the sockets approach
just a while back.
With the above, it should solve it. Of course, you need to implement
some type of error handling but it will help you track down where the
breakdown in communication is.
If those above steps dont work, I would recommend that u post a
simple broken version of ur code to a java list (I dont know if this topic
really applies to Servlets). Let me know if you post it somewhere so that I
can take a look at it as well.
-Tim
============
Gin-Ting Chen
NMR
Senior Application Technical Specialist
SCP, SCWCD, BCD
-----Original Message-----
From: Ross Lambert [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 11:54 AM
To: [EMAIL PROTECTED]
Subject: Re: Connection reset by peer... Me, too!
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
___________________________________________________________________________
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
