We have to check the behavior of the innerJoin. I suspect that its closing the second stream when the first stream his finished. This would cause a broken pipe with the second stream. The export handler has specific code that eats the broken pipe exception so it doesn't end up in the logs. The select hander does not have this code.
In general you never want to use the select handler and set the rows to such a big number. If you have that many rows you'll want to use the export and handler which is designed to export the entire result set. Joel Bernstein http://joelsolr.blogspot.com/ On Thu, Jun 14, 2018 at 1:30 PM, Christian Spitzlay < christian.spitz...@biologis.com> wrote: > What does that mean exactly? If I set the rows parameter to 1000000000 > the exception still occurs. AFAICT all this happens internally during the > processing of the streaming expression. Why wouldn't the select send > the EOF tuple when it reaches the end of the documents? > Or why wouldn't the receiving end wait for it to appear? > Due to an incredibly low timeout used internally? > > > Christian Spitzlay > > > > > Am 14.06.2018 um 19:18 schrieb Susmit <shukla.sus...@gmail.com>: > > > > 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 > >>>> > >>>> > >>>> > >> > >
