Re: Broken Pipe - jena-fuseki-0.2.4
On 03/10/12 21:21, Marco Neumann wrote: we've upgraded a machine from jena-fuseki-0.2.2 to jena-fuseki-0.2.4 and now receive Broken Pipe errors on some simple describe queries with jdk1.6.0_26 and a TDB backend any suggestions? It's not clear to me what's going on. If the request asks for gzip'ed results, then Jetty closes the gzip stream quite early but I don't see why that is a problem - the code is much like the result set case. Presumably, the server continues. The output looks to come from internal debugging but it should not affect anything after it cleans up (by ignoring the problem). What's the client calling code? Could the client have gone away before the end of results were read? Is it asking/allowing gzip results? A test case to reproduce this would be good. Does it happen every describe? (we should probably ignore IOExceptions, or at least only lightly log them, at this point because they are usually things like client leaving early or low-level network faults) Andy org.eclipse.jetty.io.EofException at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:921) at org.eclipse.jetty.http.AbstractGenerator.flush(AbstractGenerator.java:452) at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:94) at org.eclipse.jetty.server.HttpConnection$Output.flush(HttpConnection.java:1010) at org.apache.jena.fuseki.servlets.ResponseModel.doResponseModel(ResponseModel.java:124) at org.apache.jena.fuseki.servlets.SPARQL_Query.sendResults(SPARQL_Query.java:327) 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:28) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:247) at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.flush(BlockingChannelConnector.java:248) at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:860) ... 35 more
Re: Broken Pipe - jena-fuseki-0.2.4
thanks Andy I will stick with jena-fuseki-0.2.2 for now, it seems subjectively to be faster as well. I use the fuseki installation as a data provider for web frontends. the particular describe query that breaks works fine with the fuseki server sparql form but does not with the specific http client request. I will keep your comments in mind do some further tests with jena-fuseki-0.2.4 in the sandbox On Thu, Oct 4, 2012 at 6:56 AM, Andy Seaborne a...@apache.org wrote: On 03/10/12 21:21, Marco Neumann wrote: we've upgraded a machine from jena-fuseki-0.2.2 to jena-fuseki-0.2.4 and now receive Broken Pipe errors on some simple describe queries with jdk1.6.0_26 and a TDB backend any suggestions? It's not clear to me what's going on. If the request asks for gzip'ed results, then Jetty closes the gzip stream quite early but I don't see why that is a problem - the code is much like the result set case. Presumably, the server continues. The output looks to come from internal debugging but it should not affect anything after it cleans up (by ignoring the problem). What's the client calling code? Could the client have gone away before the end of results were read? Is it asking/allowing gzip results? A test case to reproduce this would be good. Does it happen every describe? (we should probably ignore IOExceptions, or at least only lightly log them, at this point because they are usually things like client leaving early or low-level network faults) Andy org.eclipse.jetty.io.EofException at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:921) at org.eclipse.jetty.http.AbstractGenerator.flush(AbstractGenerator.java:452) at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:94) at org.eclipse.jetty.server.HttpConnection$Output.flush(HttpConnection.java:1010) at org.apache.jena.fuseki.servlets.ResponseModel.doResponseModel(ResponseModel.java:124) at org.apache.jena.fuseki.servlets.SPARQL_Query.sendResults(SPARQL_Query.java:327) 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:28) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at org.eclipse.jetty.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:247) at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.flush(BlockingChannelConnector.java:248) at org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:860) ... 35 more -- --- Marco Neumann KONA Join us at SemTech Biz in New York City October 15-17, 2012 and save 15% with code STMN http://www.lotico.com/evt/SemTechBizNYC2012
Re: Broken Pipe - jena-fuseki-0.2.4
On 04/10/12 14:44, Marco Neumann wrote: thanks Andy I will stick with jena-fuseki-0.2.2 for now, it seems subjectively to be faster as well. Be careful! This may be because 0.2.2 was not careful enough about making data safe against crashes. Try 0.2.5-SNAPSHOT which is reported by be comparable to previous performance. Andy
Re: Broken Pipe - jena-fuseki-0.2.4
just tried the 0.2.5-SNAPSHOT same problem On Thu, Oct 4, 2012 at 9:56 AM, Andy Seaborne a...@apache.org wrote: On 04/10/12 14:44, Marco Neumann wrote: thanks Andy I will stick with jena-fuseki-0.2.2 for now, it seems subjectively to be faster as well. Be careful! This may be because 0.2.2 was not careful enough about making data safe against crashes. Try 0.2.5-SNAPSHOT which is reported by be comparable to previous performance. Andy -- --- Marco Neumann KONA Join us at SemTech Biz in New York City October 15-17, 2012 and save 15% with code STMN http://www.lotico.com/evt/SemTechBizNYC2012
Re: Broken Pipe - jena-fuseki-0.2.4
actually both, but I think you are right with your earlier suggestion about the http request. i will take it off list with you from here. On Thu, Oct 4, 2012 at 3:17 PM, Andy Seaborne a...@apache.org wrote: On 04/10/12 17:03, Marco Neumann wrote: just tried the 0.2.5-SNAPSHOT same problem DESCRIBE or speed? If it's DESCRIBE can we develop a test case? I have not seen it happen but that does not mean it doesn't. Andy -- --- Marco Neumann KONA Join us at SemTech Biz in New York City October 15-17, 2012 and save 15% with code STMN http://www.lotico.com/evt/SemTechBizNYC2012
