Not sure what that means :) SOLR-5776 would not happen all the time, but too frequently. It also wouldn't matter the power of CPU, cores or RAM :)
Do you see fails without https is what you want to check. - mark On Mon, Oct 5, 2015 at 2:16 PM Markus Jelsma <markus.jel...@openindex.io> wrote: > Hi - no, i don't think so, it doesn't happen all the time, but too > frequently. The machine running the tests has a high powered CPU, plenty of > cores and RAM. > > Markus > > > > -----Original message----- > > From:Mark Miller <markrmil...@gmail.com> > > Sent: Monday 5th October 2015 19:52 > > To: solr-user@lucene.apache.org > > Subject: Re: Implementing AbstractFullDistribZkTestBase > > > > If it's always when using https as in your examples, perhaps it's > SOLR-5776. > > > > - mark > > > > On Mon, Oct 5, 2015 at 10:36 AM Markus Jelsma < > markus.jel...@openindex.io> > > wrote: > > > > > Hmmm, i tried that just now but i sometimes get tons of Connection > reset > > > errors. The tests then end with "There are still nodes recoverying - > waited > > > for 30 seconds". > > > > > > [RecoveryThread-collection1] ERROR > org.apache.solr.cloud.RecoveryStrategy > > > - Error while trying to > recover.:java.util.concurrent.ExecutionException: > > > org.apache.solr.client.solrj.SolrServerException: IOException occured > when > > > talking to server at: https://127.0.0.1:49146 > > > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > > > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > > > at > > > > org.apache.solr.cloud.RecoveryStrategy.sendPrepRecoveryCmd(RecoveryStrategy.java:598) > > > at > > > > org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:361) > > > at > > > org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:227) > > > Caused by: org.apache.solr.client.solrj.SolrServerException: > IOException > > > occured when talking to server at: https://127.0.0.1:49146 > > > at > > > > org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:574) > > > at > > > > org.apache.solr.client.solrj.impl.HttpSolrClient$1.call(HttpSolrClient.java:270) > > > at > > > > org.apache.solr.client.solrj.impl.HttpSolrClient$1.call(HttpSolrClient.java:266) > > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > > at > > > > org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:210) > > > at > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > > at java.lang.Thread.run(Thread.java:745) > > > Caused by: java.net.SocketException: Connection reset > > > at java.net.SocketInputStream.read(SocketInputStream.java:209) > > > at java.net.SocketInputStream.read(SocketInputStream.java:141) > > > at sun.security.ssl.InputRecord.readFully(InputRecord.java:465) > > > at sun.security.ssl.InputRecord.read(InputRecord.java:503) > > > at > > > sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954) > > > at > > > > sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343) > > > at > > > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371) > > > at > > > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355) > > > at > > > > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543) > > > at > > > > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) > > > at > > > > org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) > > > at > > > > org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) > > > at > > > > org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) > > > at > > > > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) > > > at > > > > org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) > > > at > > > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > > > at > > > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > > > at > > > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > > > at > > > > org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:465) > > > ... 7 more > > > > > > [RecoveryThread-collection1] ERROR > org.apache.solr.cloud.RecoveryStrategy > > > - Recovery failed - trying again... (1) > > > [RecoveryThread-collection1] INFO > org.apache.solr.cloud.RecoveryStrategy - > > > Wait 4.0 seconds before trying to recover again (2) > > > > > > > > > > > > -----Original message----- > > > > From:Erick Erickson <erickerick...@gmail.com> > > > > Sent: Monday 5th October 2015 15:59 > > > > To: solr-user@lucene.apache.org > > > > Subject: Re: Implementing AbstractFullDistribZkTestBase > > > > > > > > Right, I'm assuming you're creating a cluster somewhere. > > > > Try calling (from memory) waitForRecoveriesToFinish in > > > > AbstractDistribZkTestBase after creating the collection > > > > to insure that the nodes are up and running before you > > > > index to them. > > > > > > > > Shot in the dark > > > > Erick > > > > > > > > On Mon, Oct 5, 2015 at 1:36 AM, Markus Jelsma > > > > <markus.jel...@openindex.io> wrote: > > > > > Hello, > > > > > > > > > > I have several implementations of AbstractFullDistribZkTestBase of > > > Solr 5.3.0. Sometimes a test fails with either "There are still nodes > > > recoverying - waited for 30 seconds" or "IOException occured when > talking > > > to server at: https://127.0.0.1:44474/collection1";, so usually at > least > > > one of all test fails. These are very simple implementations such as : > > > > > > > > > > @Test > > > > > @ShardsFixed(num = 2) > > > > > public void testSomeStuff() throws Exception { > > > > > waitForThingsToLevelOut(30); > > > > > > > > > > del("*:*"); > > > > > indexDoc("input 1", "user_1"); > > > > > indexDoc("input 1", "user_2"); > > > > > indexDoc("input 2", "user_1"); > > > > > indexDoc("input 2", "user_2"); > > > > > commit(); > > > > > > > > > > Any idea on how to get rid of the nodes recovering issue? > > > > > Markus > > > > > > > > > -- > > - Mark > > about.me/markrmiller > > > -- - Mark about.me/markrmiller
