Detecting client-aborting request Jersey

Question

I have Jersey providing a restfull web service. It happens often that the client aborts request done via ajax, with the ajax abort methods like is explained here abort ajax request

On server side I get the following output. Which is not nice to see. Is there a way to detect an aborted request in Jersey?

SEVERE: An I/O error has occurred while writing a response message entity to the container output stream.
org.glassfish.jersey.server.internal.process.MappableException: ClientAbortException:  java.net.SocketException: Broken pipe
    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:96)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1154)
    at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:571)
    at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:378)
    at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:368)
    at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:262)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
    at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
    at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
    at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:319)
    at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:236)
    at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1028)
    at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:373)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:381)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:344)
    at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:219)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:393)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Caused by: ClientAbortException:  java.net.SocketException: Broken pipe
    at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:364)
    at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:326)
    at org.apache.catalina.connector.CoyoteOutputStream.flush(CoyoteOutputStream.java:101)
    at org.glassfish.jersey.message.internal.CommittingOutputStream.flush(CommittingOutputStream.java:292)
    at com.fasterxml.jackson.core.json.UTF8JsonGenerator.close(UTF8JsonGenerator.java:1086)
    at com.fasterxml.jackson.jaxrs.base.ProviderBase.writeTo(ProviderBase.java:544)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.invokeWriteTo(WriterInterceptorExecutor.java:263)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor$TerminalWriterInterceptor.aroundWriteTo(WriterInterceptorExecutor.java:250)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.server.internal.JsonWithPaddingInterceptor.aroundWriteTo(JsonWithPaddingInterceptor.java:103)
    at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162)
    at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:88)
    ... 37 more
Caused by: java.net.SocketException: Broken pipe
    at java.net.SocketOutputStream.socketWrite0(Native Method)
    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113)
    at java.net.SocketOutputStream.write(SocketOutputStream.java:159)
    at org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:215)
    at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:480)
    at org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:119)
    at org.apache.coyote.http11.AbstractHttp11Processor.action(AbstractHttp11Processor.java:793)
    at org.apache.coyote.Response.action(Response.java:173)
    at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:359)
    ... 48 more

See http://stackoverflow.com/a/39006980/142446 – Brett Kail Aug 17 '16 at 22:14 — Brett Kail, Aug 17 '16 at 22:14

score 4 · Answer 1 · edited Jun 20 '20 at 09:12

4

Aborted request must be logged in tomcat access log. You can find all requests and related response codes in it.

But your problem may be related with system limits. In jersey,for each request to server, I/O container sends new instance of the response writer so you should check operation system limit which is located etc/security/limits.conf. Mentioned file contains domain, type and value fields.

Domain can be an user name, a group name or any wildcard. type filed can have two values, (soft or hard), soft for enforcing the soft limits, hard for enforcing hard limits. value field is defined limit for domain :) I think if you increase limit for tomcat user, the problem will be solved.

sample conf for tomcat

tomcat soft nofile 102400

tomcat hard nofile 102400

tomcat soft nproc 102400

tomcat hard nproc 102400

edited Jun 20 '20 at 09:12

Community

1
1

answered Dec 08 '14 at 07:28

serkan kucukbay

623
7
15

So, I can NOT detect the client aborting a request? this is what you are saying…? – LMG Dec 08 '14 at 09:24
The problem is related your tomcat based **configuration** . When your server under **heavy load**, operating system can not create and allocate any processes/files to tomcat. And jersey throws mentioned exception, to overcome this problem you should increase these settings in server side. This configuration file is located at **etc/security/limits.conf** in your server. – serkan kucukbay Dec 08 '14 at 13:39
2

But you didn't answer the question how can I disable the log to Tomcat ... I have the same problem, the jersey log the exception in tomcat when the user abort the request, and I want to disable this log, because my client can abort his requests, and it is OK by me. So... How can I detecting the client aborting request in Jersey and disable the log to tomcat... – sidanmor Sep 10 '15 at 08:32
The problem is not about disabling the log to tomact, once you can intercept such event you can avoid it to be written in the log. I would like to be able to stop completely the processing job that is going on while the caller aborted the request: this allows to save some computation, which may turn into more resources to be used by other clients.. – LMG Sep 15 '15 at 14:54
@LMG So... can you answer this question ??? http://stackoverflow.com/questions/32494699/detecting-client-aborting-request-jersey-continue – sidanmor Nov 02 '15 at 15:08

Detecting client-aborting request Jersey

1 Answers1

Linked

Related