Caught IOException while trying to write data to a client connection: null

9
Anybody a guess how this error can happen? Should I start to worry? The error is from the standard cloud. Regards, Ronald 2013-09-20 10:27:30.028 WARNING - Connector: Caught IOException while trying to write data to a client connection: null 2013-09-20 10:27:30.028 WARNING - Connector: org.eclipse.jetty.io.EofException at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:952) at org.eclipse.jetty.http.AbstractGenerator.blockForOutput(AbstractGenerator.java:502) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:182) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:101) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1720) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1696) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1671) at je.a(SourceFile:406) at je.a(SourceFile:216) at je.b(SourceFile:198) at je.a(SourceFile:86) at je.processRequest(SourceFile:77) at jg.a(SourceFile:74) at com.mendix.core.MxRuntime.processRequest(SourceFile:910) at com.mendix.m2ee.server.handler.RuntimeHandler.handle(RuntimeHandler.java:44) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:293) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:72) at sun.nio.ch.IOUtil.write(IOUtil.java:43) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:312) at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.flush(BlockingChannelConnector.java:248) at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:891) at org.eclipse.jetty.http.AbstractGenerator.blockForOutput(AbstractGenerator.java:502) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:182) at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:101) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1720) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1696) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1671) at je.a(SourceFile:406) at je.a(SourceFile:216) at je.b(SourceFile:198) at je.a(SourceFile:86) at je.processRequest(SourceFile:77) at jg.a(SourceFile:74) at com.mendix.core.MxRuntime.processRequest(SourceFile:910) at com.mendix.m2ee.server.handler.RuntimeHandler.handle(RuntimeHandler.java:44) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:293) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) [EDIT] Update 28-6-2021 I found the root cause of this error. It is the Mendix logger that is crashing and throwing this error. The Mendix logger crashes if more than 65K characters needs to be processed. Webservices with an unlimited string attribute for instance could crash the Mendix logger while trying to catch the complete webservice call.  
asked
13 answers
5

WARNING: Caught IOException while trying to write data to a client connection: null Caused by: java.io.IOException: Broken pipe in the Production environment.

most of the time this error means that the process wants to write data to a connection that is not available anymore. For example, this could happen when a request is done, the application starts processing the request, in the meanwhile the user closes their browser (or a web service call closes the HTTP connection), and when the application is done processing the request and wants to write the response back to the HTTP connection, it's not there anymore. 

It is recommended to check what it is running to find out the root cause for the issue. For that you can use the Runing Now Metrics and also you can use Query Logging
 

answered
3

We are also getting this warning multiple times (50 - 100) per day on production (Mx 7.23.6). After reading the comment by Nikolina I’m wondering if the microflow timer widget might be a cause of this problem.

We are using two microflow timers on our main page template and have - at some times - 10 to 20 users logged in for which these timers are active.

These microflow timers trigger microflows that also do some (light) database retrieves. I think that in our case, it is quite likely that in some cases of these microflow timer executions a users might close his/her browser or log out. Might this cause the warning?

I'm wondering if others who are experiencing the same warning also use the microflow timer widget in their app at frequently used pages.

If, in our case, this is the cause of these warnings I don't see how we could fix this. It does however flood our log file which increases the chance of missing more important warnings and errors.

It would be helpful if the warning log that is created had some more context (which action and user triggered the connection / request?)

answered
3

We too experience these errors a few times a day. Mendix should really try to pinpoint and fix this...

answered
3

+1 !!!!

answered
2

Anybody with an answer on that? Our log also has a number of those errors..

answered
2

I have also created forum ticket on this recently. Read here As for my case i was trying to play a video file not supported by AudioVideoPlay/Jplayer/ web standards. you can still reproduce. So i suspect that Mendix continues to send files even when the client is refusing it and then it runs into some kind of issue where it expects some info to be returned but nothing happens,etc.

answered
2

Some issue here. I've also created a ticket for this.

answered
2

We seem to be having the same issues, any update here?

answered
2

I have checked the forum and seen more than one post about this problem, but no solution. I have the same problem and have been able to narrow it down to the following scenario. I get this error if I try to generate a PDF on IOS (not IpadOS, Ipad OS works fine) in the browser (I have tried multiple browsers but they are all based on the same infrastructure) and in the hybrid app. Does somebody recognize this scenario, could this contribute to narrow down the problem?

answered
0

We're also seeing this, unfortunately.

answered
0

Ten years have passed, the question is still not be fixed. Unbelievableļ¼

answered
0

Same issue with me Mx9.24.9

answered
0

We have the same issue.

answered