Hi, thanks for the reply. We're using solr 8.3.1, ZK 3.5.6 The stacktrace is below. The address on the first line "http://192.168.15.10:888/solr/mycollection"; is the "server" address in my nginx configuration, which points to 2 upstream solr nodes. There were no other solr or ZK messages in the logs.
StackTrace: (Msg = IOException occured when talking to server at: http://192.168.15.10:888/solr/mycollection) org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://192.168.15.10:888/solr/mycollection at org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:418) at org.apache.solr.client.solrj.impl.Http2SolrClient.request(Http2SolrClient.java:754) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1035) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1051) ... calls from our code ... calls from our code at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: java.nio.channels.AsynchronousCloseException at org.eclipse.jetty.http2.client.http.HttpConnectionOverHTTP2.close(HttpConnectionOverHTTP2.java:144) at org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2.onClose(HttpClientTransportOverHTTP2.java:170) at org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2$SessionListenerPromise.onClose(HttpClientTransportOverHTTP2.java:232) at org.eclipse.jetty.http2.api.Session$Listener.onClose(Session.java:206) at org.eclipse.jetty.http2.HTTP2Session.notifyClose(HTTP2Session.java:1153) at org.eclipse.jetty.http2.HTTP2Session.onGoAway(HTTP2Session.java:438) at org.eclipse.jetty.http2.parser.Parser$Listener$Wrapper.onGoAway(Parser.java:392) at org.eclipse.jetty.http2.parser.BodyParser.notifyGoAway(BodyParser.java:187) at org.eclipse.jetty.http2.parser.GoAwayBodyParser.onGoAway(GoAwayBodyParser.java:169) at org.eclipse.jetty.http2.parser.GoAwayBodyParser.parse(GoAwayBodyParser.java:108) at org.eclipse.jetty.http2.parser.Parser.parseBody(Parser.java:194) at org.eclipse.jetty.http2.parser.Parser.parse(Parser.java:123) at org.eclipse.jetty.http2.HTTP2Connection$HTTP2Producer.produce(HTTP2Connection.java:248) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132) at org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:170) at org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:125) at org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:348) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.Invocable.invokeNonBlocking(Invocable.java:68) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.invokeTask(EatWhatYouKill.java:345) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:300) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:210) ... 3 more ----------------------------- I did consider using the solrJ cloud or lb clients, but nginx gives me more flexibility in controlling how the load balancing is done. I'm still running experiments to see which one works best for me. In the meantime, if you have any clues for why I'm getting this IOException, I'd appreciate. Thanks Reinaldo On Mon, Aug 17, 2020 at 10:59 AM Dominique Bejean <dominique.bej...@eolya.fr> wrote: > Hi, > > Can you provide more information ? > - Solr and ZK version > - full error stacktrace generated by SolrJ > - any concomitant and relevant information in solr nodes logs or zk logs > > Just to know, why not use a load balanced LBHttp... Solr Client ? > > Regards. > > Dominique > > > Le lun. 17 août 2020 à 00:41, Odysci <ody...@gmail.com> a écrit : > > > Hi, > > > > We have a solrcloud setup with 2 solr nodes and 3 ZK instances. Until > > recently I had my application server always call one of the solr nodes > (via > > solrJ), and it worked just fine. > > > > In order to improve reliability I put an Nginx reverse-proxy load > balancer > > between my application server and the solr nodes. The response time > > remained almost the same but we started getting the msg: > > > > IOException occured when talking to server http://myserver.... > > > > every minute or so (very randomly but consistently). Since our code will > > just try again after a few milliseconds, the overall system continues to > > work fine, despite the delay. I tried increasing all nginx related > > timeout's to no avail. > > I've searched for this msg a lot and most replies seem to be related to > > ssl. > > We are using http2solrclient but no ssl to solr. > > Can anyone shed any light on this? > > > > Thanks! > > Reinaldo > > >
