Hi, This may be expected if one of the streams is closed early - does not reach to EOF tuple
Sent from my iPhone > On Jun 14, 2018, at 9:53 AM, Christian Spitzlay > <christian.spitz...@biologis.com> wrote: > > Here ist one I stripped down as far as I could: > > innerJoin(sort(search(kmm, > q="sds_endpoint_uuid:(2f927a0b\-fe38\-451e\-9103\-580914a77e82)", > fl="sds_endpoint_uuid,sds_to_endpoint_uuid", sort="sds_to_endpoint_uuid ASC", > qt="/export"), by="sds_endpoint_uuid ASC"), search(kmm, > q=ss_search_api_datasource:entity\:as_metadata, fl="sds_metadata_of_uuid", > sort="sds_metadata_of_uuid ASC", qt="/select", rows=10000), > on="sds_endpoint_uuid=sds_metadata_of_uuid") > > The exception happens both via PHP (search_api_solr / Solarium) and via the > Solr admin UI. > (version: Solr 7.3.1 on macOS High Sierra 10.13.5) > > It seems to be related to the fact that the second stream uses "select“. > - If I use "export“ the exception doesn’t occur. > - If I set the rows parameter "low enough“ so I do not get any results > the exception doesn’t occur either. > > > BTW: Do you know of any tool for formatting and/or syntax highlighting > these expressions? > > > Christian Spitzlay > > > > > >> Am 13.06.2018 um 23:02 schrieb Joel Bernstein <joels...@gmail.com>: >> >> Can your provide some example expressions that are causing these exceptions? >> >> Joel Bernstein >> http://joelsolr.blogspot.com/ >> >> On Wed, Jun 13, 2018 at 9:02 AM, Christian Spitzlay < >> christian.spitz...@biologis.com> wrote: >> >>> Hi, >>> >>> I am seeing a lot of (reproducible) exceptions in my solr log file >>> when I execute streaming expressions: >>> >>> o.a.s.s.HttpSolrCall Unable to write response, client closed connection >>> or we are shutting down >>> org.eclipse.jetty.io.EofException >>> at org.eclipse.jetty.io.ChannelEndPoint.flush( >>> ChannelEndPoint.java:292) >>> at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:429) >>> at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:322) >>> at org.eclipse.jetty.io.AbstractEndPoint.write( >>> AbstractEndPoint.java:372) >>> at org.eclipse.jetty.server.HttpConnection$SendCallback. >>> process(HttpConnection.java:794) >>> […] >>> at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run( >>> EatWhatYouKill.java:131) >>> at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ >>> ReservedThread.run(ReservedThreadExecutor.java:382) >>> at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob( >>> QueuedThreadPool.java:708) >>> at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run( >>> QueuedThreadPool.java:626) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> Caused by: java.io.IOException: Broken pipe >>> at java.base/sun.nio.ch.FileDispatcherImpl.writev0(Native Method) >>> at java.base/sun.nio.ch.SocketDispatcher.writev( >>> SocketDispatcher.java:51) >>> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:148) >>> at java.base/sun.nio.ch.SocketChannelImpl.write( >>> SocketChannelImpl.java:506) >>> at org.eclipse.jetty.io.ChannelEndPoint.flush( >>> ChannelEndPoint.java:272) >>> ... 69 more >>> >>> >>> I have read up on the exception message and found >>> http://lucene.472066.n3.nabble.com/Unable-to-write-response-client-closed- >>> connection-or-we-are-shutting-down-tt4350349.html#a4350947 >>> but I don’t understand how an early client connect can cause what I am >>> seeing: >>> >>> What puzzles me is that the response has been delivered in full to the >>> client library, including the document with EOF. >>> >>> So Solr must have already processed the streaming expression and returned >>> the result. >>> It’s just that the log is filled with stacktraces of this exception that >>> suggests something went wrong. >>> I don’t understand why this happens when the query seems to have succeeded. >>> >>> >>> Best regards, >>> Christian >>> >>> >>> >
