[jira] [Resolved] (SOLR-9592) decorateDocValues cause serious performance issue because of using slowCompositeReaderWrapper

[Yonik Seeley (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley resolved SOLR-9592.

Resolution: Fixed

Committed.  Thanks!

> decorateDocValues cause serious performance issue because of using 
> slowCompositeReaderWrapper
> -
>
> Key: SOLR-9592
> URL: https://issues.apache.org/jira/browse/SOLR-9592
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers, search
>Affects Versions: 6.0, 6.1, 6.2
>Reporter: Takahiro Ishikawa
>Assignee: Yonik Seeley
>  Labels: performance
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9592.patch, SOLR-9592.patch, SOLR-9592_6x.patch
>
>
> I have serious performance issue using AtomicUpdate (and RealtimeGet) with 
> non stored docValues.
> Because decorateDocValues try to merge each leafLeader on the fly via 
> slowCompositeReaderWrapper and it’s extremely slow (> 10sec).
> Simply access docValues via nonCompositeReader could resolve this 
> issue.(patch) 
> AtomicUpdate performance(or RealtimeGet performance)
> * Environment
> ** solr version : 6.0.0
> ** schema ~ 100 fields(90% docValues, some of those are multi valued)
> ** index : 5,000,000
> * Performance
> ** original :  > 10sec per query
> ** patched : at least 100msec per query
> This patch will also enhance search performance, because DocStreamer also 
> fetch docValues via decorateDocValues.
> Though it depends on each environment, I could take 20% search performance 
> gain.
> (This patch originally written for solr 6.0.0, and now rewritten for master)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] JIRA maintenance and response times

[Jeff Wartes]

I was thinking about this some more last night, and since I’m in software, 
here’s the software I think I’d want:

Create a list of Alerts, each of which know how to do two things: 1) Determine 
whether a given jira issue matches the alert 2) Determine an Alertee for a 
matching issue.
One of Alexandre’s examples in this context: 1) If the issue hasn’t had an 
update in a week, and the last update was by a committer, it’s a match. 2) The 
committer with the last comment is the Alertee.
Another example: 1) If the issue has a patch file or a github pull request 
comment, but isn’t assigned to anyone, it’s a match. 2) This dev mailing list 
is the Alertee

Every week, iterate through all unresolved issues, and give every Alert 
definition the chance to gather the list of matching tickets.
Then:
1. Dump each Alert’s list of issues on a web page someplace. Include diffs vs 
the last run, so you can see if a given Alert’s list is growing over time.
2. Get the distinct list of Alertee for all issues that matched any Alerts, and 
send each Alertee one email with the list of issues mapped to that Alertee, 
grouped by Alert type.

So you give periodic reminders to exactly the people who should get them, and 
you also have a place you can see this week’s status for everything. For bonus 
points, people could squelch getting the email if it only contained issues 
derived from certain Alerts.


On 10/5/16, 10:42 AM, "Alexandre Rafalovitch"  wrote:

 I believe the first 3 dashboards can be done in JIRA itself. I have
something similar, but unfortunately cannot share the dashboard (no
permission it seems).

The last one (breakdown of creation date? by year) is something that
JIRA does not seem to be able to give.

In terms of pulling data, I was able to build an API to pull up to 200
issues from JIRA at a time with full case information in the - as
Cassandra discovered - rather convoluted XML. So, it would not be too
hard to run several APIs and merge the results to get full export. And
then maybe run daily/weekly export and merge/override. Then, it is
pre-process and distribute.

It is totally doable. We just need to firm up the business
requirements. What kind of reports people feel would be useful for
_them_ to be more proactive. I've listed my ideas earlier, but not
sure if they would be useful to others.

Regards,
   Alex.
P.s. Do we need a JIRA for this?

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 6 October 2016 at 00:06, Cassandra Targett  wrote:
> In terms of a report, I found a template that uses JIRA's API to
> import issues to a Google Sheet:
> 
http://www.littlebluemonkey.com/blog/automatically-import-jira-backlog-into-google-spreadsheet
>
> I made some modifications to the original and have shared it for
> public viewing:
> 
https://docs.google.com/spreadsheets/d/1i1_XgabWM4CFnDLGyp3xNVXcZNvGDjww3HPk2hA4uNc/edit#gid=0
>
> I was able to pull in issues with my JIRA login without asking INFRA,
> so I think committers at least already have permissions to use the
> JIRA API.
>
> The template Sheet was initially created to make a board with cards
> for planning, but I have removed those tabs and the script that
> generates the cards. So ignore anything about "story cards" that you
> might see in instructions or anywhere else.
>
> There are a few issues with the API output that makes the data a
> little difficult to work with. Most of the fields I wanted include a
> bunch of metadata JIRA uses for display. And the date field won't
> convert from a timestamp to a date. The date issue is the worst of
> these, for aging purposes, but there might be something we can do in
> the script  that pulls the data to fix this.
>
> Despite that, it's still possible to make a simple report from this.
> I've added a tab "Stats" that shows some initial (easy) calculations -
> # of Issues by Type, # older than 2016 by types, # unassigned, a
> breakdown by year.
>
> Google's flavor of javascript (Google Apps Script) runs the sheet, so
> I think we could add to the main script, or add other scripts, if we
> want to. I know pretty close to zero javascript, however, so would
> need help there.
>
> JIRA can do a lot of this same stuff in its own dashboards (especially
> basic stuff), but that's very much opt-in by individual users. It
> sounds like some folks would prefer something pushed to the community.
> We could do a combination, however - I could take a stab at a shared
> dashboard people could opt into, and also send out a summary weekly
> based on a report generated somehow.
>
> I have no ego invested in the import-to-spreadsheet example I'm
> sharing 

Re: lucene-solr:master: SOLR-9132: RulesTest must tear down collections at the end of each test

[Chris Hostetter]

It's not immediately obvious to me why these collection deletions can't be 
done in an @After method -- but if they need to live in each test method 
can we at least have an @After method that asserts no collections exist 
(via a STATUS call) so if someone writes a new test method but forgets to 
delete that collection then the @After method will catch it and give them 
a self explanatory failure instead of some future confusing/trappy error 
that depends on test order or what not?



: Date: Wed,  5 Oct 2016 14:28:21 + (UTC)
: From: romseyg...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: lucene-solr:master: SOLR-9132: RulesTest must tear down collections
: at the end of each test
: 
: Repository: lucene-solr
: Updated Branches:
:   refs/heads/master b6610b9f0 -> d398617be
: 
: 
: SOLR-9132: RulesTest must tear down collections at the end of each test
: 
: 
: Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/d398617b
: Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/d398617b
: Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/d398617b
: 
: Branch: refs/heads/master
: Commit: d398617be891c9bc4ac72f85bf6ba4bff81f4f89
: Parents: b6610b9
: Author: Alan Woodward 
: Authored: Wed Oct 5 15:18:46 2016 +0100
: Committer: Alan Woodward 
: Committed: Wed Oct 5 15:19:22 2016 +0100
: 
: --
:  .../src/test/org/apache/solr/cloud/rule/RulesTest.java| 10 ++
:  1 file changed, 10 insertions(+)
: --
: 
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/d398617b/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java
: --
: diff --git a/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java 
b/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java
: index 1b74cbe..eec3d93 100644
: --- a/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java
: +++ b/solr/core/src/test/org/apache/solr/cloud/rule/RulesTest.java
: @@ -80,6 +80,8 @@ public class RulesTest extends SolrCloudTestCase {
:  CollectionAdminRequest.createShard(rulesColl, 
"shard2").process(cluster.getSolrClient());
:  CollectionAdminRequest.addReplicaToShard(rulesColl, 
"shard2").process(cluster.getSolrClient());
:  
: +
CollectionAdminRequest.deleteCollection(rulesColl).process(cluster.getSolrClient());
: +
:}
:  
:@Test
: @@ -102,6 +104,8 @@ public class RulesTest extends SolrCloudTestCase {
:  list = (List) rulesCollection.get("snitch");
:  assertEquals(1, list.size());
:  assertEquals ( "ImplicitSnitch", ((Map)list.get(0)).get("class"));
: +
: +
CollectionAdminRequest.deleteCollection(rulesColl).process(cluster.getSolrClient());
:}
:  
:@Test
: @@ -129,6 +133,8 @@ public class RulesTest extends SolrCloudTestCase {
:  list = (List) rulesCollection.get("snitch");
:  assertEquals(1, list.size());
:  assertEquals("ImplicitSnitch", list.get(0).get("class"));
: +
: +
CollectionAdminRequest.deleteCollection(rulesColl).process(cluster.getSolrClient());
:}
:  
:  
: @@ -151,6 +157,8 @@ public class RulesTest extends SolrCloudTestCase {
:  .setSnitch("class:ImplicitSnitch")
:  .process(cluster.getSolrClient());
:  
: +
CollectionAdminRequest.deleteCollection(rulesColl).process(cluster.getSolrClient());
: +
:}
:  
:  
: @@ -192,5 +200,7 @@ public class RulesTest extends SolrCloudTestCase {
:  list = (List) rulesCollection.get("snitch");
:  assertEquals(1, list.size());
:  assertEquals("ImplicitSnitch", ((Map) list.get(0)).get("class"));
: +
: +
CollectionAdminRequest.deleteCollection(rulesColl).process(cluster.getSolrClient());
:}
:  }
: 
: 

-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9604) Pooled SSL connections are not being reused with client authentication

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549757#comment-15549757
 ] 

ASF subversion and git services commented on SOLR-9604:
---

Commit 36b3b0884a8f745bc137db1b1dc9890a59fa0895 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36b3b08 ]

Revert "SOLR-9604: Ensure SSL connections are re-used"

This reverts commit 0eb6b1c823d347319cc0894b5fea95f085d4c8d4, which was
causing test failures in ConnectionReuseTest - see SOLR-9608


> Pooled SSL connections are not being reused with client authentication
> --
>
> Key: SOLR-9604
> URL: https://issues.apache.org/jira/browse/SOLR-9604
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9604.patch, SOLR-9604.patch, fails with null.png
>
>
> Solr isn't setting user tokens on any of its HttpClientContext objects when 
> requested new http connections.  This means that when SSL + client 
> authentication is used, HttpClient is creating a new connection on every 
> request, to ensure that authentication tokens aren't shared between different 
> users.  We end up with lots of unused open connections in the connection 
> pool, leading to slowness and out-of-memory errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9608) ConnectionReuseTest failures

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549758#comment-15549758
 ] 

ASF subversion and git services commented on SOLR-9608:
---

Commit 36b3b0884a8f745bc137db1b1dc9890a59fa0895 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=36b3b08 ]

Revert "SOLR-9604: Ensure SSL connections are re-used"

This reverts commit 0eb6b1c823d347319cc0894b5fea95f085d4c8d4, which was
causing test failures in ConnectionReuseTest - see SOLR-9608


> ConnectionReuseTest failures
> 
>
> Key: SOLR-9608
> URL: https://issues.apache.org/jira/browse/SOLR-9608
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Alan Woodward
>
> My Jenkins has seen this test fail three times in the last couple hours, all 
> three reproduce for me - this is new, last failures were from May - here's 
> the first failure:
> {noformat}
> Checking out Revision 0eb6b1c823d347319cc0894b5fea95f085d4c8d4 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ConnectionReuseTest -Dtests.method=testConnectionReuse 
> -Dtests.seed=FA03A6C483303E7D -Dtests.slow=true -Dtests.locale=ga 
> -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.09s J9  | ConnectionReuseTest.testConnectionReuse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: We expected all 
> communication to use one connection! HttpSolrClient 1
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([FA03A6C483303E7D:DB3BCDAAAB786730]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.ConnectionReuseTest.testConnectionReuse(ConnectionReuseTest.java:158)
> {noformat}
> This test failed for me twice without specifying a seed, so it's likely 
> failing (close to) 100% of the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9608) ConnectionReuseTest failures

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549763#comment-15549763
 ] 

Alan Woodward commented on SOLR-9608:
-

OK, I've reverted SOLR-9604 while I try and fix this.  It's a combination of 
test bug and error in CloudSolrClient, which meant that the test randomly 
passed with CSC (which wasn't re-using its connections properly!) and failed 
when either HttpSolrClient or ConcurrentUpdateSolrClient were used.

> ConnectionReuseTest failures
> 
>
> Key: SOLR-9608
> URL: https://issues.apache.org/jira/browse/SOLR-9608
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Alan Woodward
>
> My Jenkins has seen this test fail three times in the last couple hours, all 
> three reproduce for me - this is new, last failures were from May - here's 
> the first failure:
> {noformat}
> Checking out Revision 0eb6b1c823d347319cc0894b5fea95f085d4c8d4 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=ConnectionReuseTest -Dtests.method=testConnectionReuse 
> -Dtests.seed=FA03A6C483303E7D -Dtests.slow=true -Dtests.locale=ga 
> -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 1.09s J9  | ConnectionReuseTest.testConnectionReuse <<<
>[junit4]> Throwable #1: java.lang.AssertionError: We expected all 
> communication to use one connection! HttpSolrClient 1
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([FA03A6C483303E7D:DB3BCDAAAB786730]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.ConnectionReuseTest.testConnectionReuse(ConnectionReuseTest.java:158)
> {noformat}
> This test failed for me twice without specifying a seed, so it's likely 
> failing (close to) 100% of the time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9604) Pooled SSL connections are not being reused with client authentication

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549766#comment-15549766
 ] 

Alan Woodward commented on SOLR-9604:
-

My commit didn't take into account CloudSolrClient, which also needs fixing 
here, and broke TestConnectionReuse (except when it selected CSC to test, which 
it obviously did when I ran things locally), so I've backed it out.

> Pooled SSL connections are not being reused with client authentication
> --
>
> Key: SOLR-9604
> URL: https://issues.apache.org/jira/browse/SOLR-9604
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9604.patch, SOLR-9604.patch, fails with null.png
>
>
> Solr isn't setting user tokens on any of its HttpClientContext objects when 
> requested new http connections.  This means that when SSL + client 
> authentication is used, HttpClient is creating a new connection on every 
> request, to ensure that authentication tokens aren't shared between different 
> users.  We end up with lots of unused open connections in the connection 
> pool, leading to slowness and out-of-memory errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-7475) Sparse norms

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549939#comment-15549939
 ] 

Adrien Grand commented on LUCENE-7475:
--

No worries, it's a good change! I was just going to ask whether you would be 
against making {{longValue()}} throw an exception. :)

> Sparse norms
> 
>
> Key: LUCENE-7475
> URL: https://issues.apache.org/jira/browse/LUCENE-7475
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE-7475.patch
>
>
> Even though norms now have an iterator API, they are still always dense in 
> practice since documents that do not have a value get assigned 0 as a norm 
> value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9604) Pooled SSL connections are not being reused with client authentication

[Mikhail Khludnev (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Khludnev updated SOLR-9604:
---
Attachment: SOLR-9604-6x.patch

attaching [^SOLR-9604-6x.patch] 
HttpSolrClient*ConPoolTest works (and fails) as expected.
ConnectionReuseTest asserts makes me wonder. It fails so far. 

> Pooled SSL connections are not being reused with client authentication
> --
>
> Key: SOLR-9604
> URL: https://issues.apache.org/jira/browse/SOLR-9604
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9604-6x.patch, SOLR-9604.patch, SOLR-9604.patch, 
> fails with null.png
>
>
> Solr isn't setting user tokens on any of its HttpClientContext objects when 
> requested new http connections.  This means that when SSL + client 
> authentication is used, HttpClient is creating a new connection on every 
> request, to ensure that authentication tokens aren't shared between different 
> users.  We end up with lots of unused open connections in the connection 
> pool, leading to slowness and out-of-memory errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-9604) Pooled SSL connections are not being reused with client authentication

[Mikhail Khludnev (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549940#comment-15549940
 ] 

Mikhail Khludnev edited comment on SOLR-9604 at 10/5/16 9:04 PM:
-

attaching [^SOLR-9604-6x.patch] 
HttpSolrClient*ConPoolTest works (and fails) as expected.
ConnectionReuseTest asserts makes me wonder (I swapped two lines to fix one 
failure for null metrics). It fails so far SOLR-9608.  


was (Author: mkhludnev):
attaching [^SOLR-9604-6x.patch] 
HttpSolrClient*ConPoolTest works (and fails) as expected.
ConnectionReuseTest asserts makes me wonder. It fails so far. 

> Pooled SSL connections are not being reused with client authentication
> --
>
> Key: SOLR-9604
> URL: https://issues.apache.org/jira/browse/SOLR-9604
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9604-6x.patch, SOLR-9604.patch, SOLR-9604.patch, 
> fails with null.png
>
>
> Solr isn't setting user tokens on any of its HttpClientContext objects when 
> requested new http connections.  This means that when SSL + client 
> authentication is used, HttpClient is creating a new connection on every 
> request, to ensure that authentication tokens aren't shared between different 
> users.  We end up with lots of unused open connections in the connection 
> pool, leading to slowness and out-of-memory errors.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_102) - Build # 6160 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6160/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Error from server at http://127.0.0.1:63531/kb/qx/collection1: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://[ff01::083]:2/kb/qx, 
http://[ff01::114]:2/kb/qx, http://127.0.0.1:63534/kb/qx/collection1, 
http://[ff01::213]:2/kb/qx]

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:63531/kb/qx/collection1: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://[ff01::083]:2/kb/qx, 
http://[ff01::114]:2/kb/qx, http://127.0.0.1:63534/kb/qx/collection1, 
http://[ff01::213]:2/kb/qx]
at 
__randomizedtesting.SeedInfo.seed([996DD9CF787E3CFA:1139E615D6825102]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:608)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:260)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:249)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:557)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:605)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:587)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:566)
at 
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:839)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1011)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at