Discussion:
CLOSE_WAIT connections when OutOfMemoryError is thrown
Antonio Rafael Rodrigues
2018-09-04 02:20:19 UTC
Permalink
Hi
In my rest API, everytime time my request generates an OutOfMemoryError the
client doesn't get a response from server and hangs forever. If I kill the
client, I can see by lsof that a CLOSE_WAIT connection remains and it goes
away just if I restart the Spring application.
I can reproduce it easily with an plain Servlet:


public class CustomServlet extends HttpServlet {

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
System.out.println("Test");
throw new OutOfMemoryError();
}
}

Any request to this servlet hangs, if the client gives up a CLOSE_WAIT
connection remains.

I'd like to know if there is some way to get over it and if it is a bug.

Tomcat 9.0.11
SO: 4.4.0-21-generic #37-Ubuntu SMP x86_64 GNU/Linux
Tomcat embedded in spring-boot-starter-web of spring-boot 2.0.4.RELEASE
JDK: 1.8.0_121 65 bits

Thanks
Mark Thomas
2018-09-04 07:51:42 UTC
Permalink
Post by Antonio Rafael Rodrigues
Hi
In my rest API, everytime time my request generates an OutOfMemoryError the
client doesn't get a response from server and hangs forever. If I kill the
client, I can see by lsof that a CLOSE_WAIT connection remains and it goes
away just if I restart the Spring application.
public class CustomServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
System.out.println("Test");
throw new OutOfMemoryError();
}
}
Any request to this servlet hangs, if the client gives up a CLOSE_WAIT
connection remains.
I'd like to know if there is some way to get over it
No. Once an OOME occurs the JVM is in a potentially unknown / unstable
state and the only safe thing to do is to shut it down and restart it.
There are some OOMEs that are potentially recoverable but reliably
determining if this is the case is tricky.
Post by Antonio Rafael Rodrigues
and if it is a bug.
No.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Loading...