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 >> >> >>
