[jira] [Commented] (SOLR-4818) Guice vs Solr
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728826#comment-13728826 ] Grant Ingersoll commented on SOLR-4818: --- I've started a branch for this at https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ Guice vs Solr - Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4818) Guice vs Solr
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-4818: - Assignee: Grant Ingersoll Guice vs Solr - Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4818) Guice vs Solr
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728826#comment-13728826 ] Grant Ingersoll edited comment on SOLR-4818 at 8/4/13 10:04 AM: I've started a branch for this at https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ It is totally experimental and a long ways away from being anything real. That being said, I think it solves a number of things: # It will be easier to embed Solr into whatever container, including something like Netty # More testability b/c it is is super easy to inject alternate views of the world # SOLR-5091 # SOLR-5103 # SOLR-5102 # Guice is just so much cleaner than all kinds of factories, etc. # More extensible was (Author: gsingers): I've started a branch for this at https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ Guice vs Solr - Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4818) Guice vs Solr
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728826#comment-13728826 ] Grant Ingersoll edited comment on SOLR-4818 at 8/4/13 10:05 AM: I've started a branch for this at https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ It is totally experimental and a long ways away from being anything real. That being said, I think it solves a number of things: # It will be easier to embed Solr into whatever container, including something like Netty # More testability b/c it is is super easy to inject alternate views of the world # SOLR-5091 -- Easier creation of APIs # SOLR-5103 # SOLR-5102 # Guice is just so much cleaner than all kinds of factories, etc. # More extensible was (Author: gsingers): I've started a branch for this at https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ It is totally experimental and a long ways away from being anything real. That being said, I think it solves a number of things: # It will be easier to embed Solr into whatever container, including something like Netty # More testability b/c it is is super easy to inject alternate views of the world # SOLR-5091 # SOLR-5103 # SOLR-5102 # Guice is just so much cleaner than all kinds of factories, etc. # More extensible Guice vs Solr - Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728840#comment-13728840 ] Grant Ingersoll edited comment on SOLR-5103 at 8/4/13 10:11 AM: I don't see any downside to it, but the classloader stuff can get real hairy. It could be for 4, but I don't want to worry about backporting just yet. was (Author: gsingers): I don't see any downside to it, but the classloader stuff can get real hairy. Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728840#comment-13728840 ] Grant Ingersoll commented on SOLR-5103: --- I don't see any downside to it, but the classloader stuff can get real hairy. Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5091) Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation
[ https://issues.apache.org/jira/browse/SOLR-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728842#comment-13728842 ] Grant Ingersoll commented on SOLR-5091: --- I'm working on this on a branch: https://svn.apache.org/repos/asf/lucene/dev/branches/solr_guice_restlet/ as it is pretty involved. Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation -- Key: SOLR-5091 URL: https://issues.apache.org/jira/browse/SOLR-5091 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 Attachments: SOLR-5091.patch This is an issue to track a series of sub issues related to deprecated and crufty Servlet/REST API code. I'll create sub-tasks to manage them. # Clean up all the old UI stuff (old redirects) # Kill/Simplify SolrDispatchFilter -- for instance, why not make the user always have a core name in 5.0? i.e. /collection1 is the default core ## I'd like to move to just using Guice's servlet extension to do this, which, I think will also make it easier to run Solr in other containers (i.e. non-servlet environments) due to the fact that you don't have to tie the request handling logic specifically to a Servlet. # Simplify the creation and testing of REST and other APIs via Guice + Restlet, which I've done on a number of occasions. ## It might be also possible to move all of the APIs onto Restlet and maintain back compat through a simple restlet proxy (still exploring this). This would also have the benefit of abstracting the core request processing out of the Servlet context and make that an implementation detail. ## Moving to Guice, IMO, will make it easier to isolate and test individual components by being able to inject mocks easier. I am close to a working patch for some of this. I will post incremental updates/issues as I move forward on this, but I think we should take 5.x as an opportunity to be more agnostic of container and I believe the approach I have in mind will do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4818) Guice vs Solr
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728895#comment-13728895 ] Jack Krupansky commented on SOLR-4818: -- Could somebody give this issue a more accurate and descriptive summary line? I mean it's not really Guice OR Solr is it? More like Guice AND Solr, right? Thanks. Guice vs Solr - Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5113) CollectionsAPIDistributedZkTest fails all the time
[ https://issues.apache.org/jira/browse/SOLR-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-5113: --- Priority: Blocker (was: Critical) CollectionsAPIDistributedZkTest fails all the time -- Key: SOLR-5113 URL: https://issues.apache.org/jira/browse/SOLR-5113 Project: Solr Issue Type: Bug Components: Tests Reporter: Uwe Schindler Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5113) CollectionsAPIDistributedZkTest fails all the time
[ https://issues.apache.org/jira/browse/SOLR-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-5113: --- Affects Version/s: 5.0 4.5 CollectionsAPIDistributedZkTest fails all the time -- Key: SOLR-5113 URL: https://issues.apache.org/jira/browse/SOLR-5113 Project: Solr Issue Type: Bug Components: Tests Affects Versions: 4.5, 5.0 Reporter: Uwe Schindler Priority: Blocker -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: lucene indexing and field configuration or schema
Hey Adrian: Sorry about the late reply. I somehow missed your email. We are doing some customizations with the Lucene indexing pipeline, here are some examples we ran into that we used an external configuration file to help us: 1) default payload size: we define this in our config file to avoid storing a length per posting. 2) docvalue types: we have built updatable docvalue support for fix length types, e.g. int, long etc., we store the type in the configuration file, where as with lucene, a long would be used and could be wasteful for us. Thanks -John On Tue, Jun 11, 2013 at 8:50 AM, Adrien Grand jpou...@gmail.com wrote: Hi John, On Mon, Jun 10, 2013 at 8:17 PM, John Wang john.w...@gmail.com wrote: We found having the schema information up front allows us flexibilities in designing our posting list, also makes the indexingchain logic much simpler. Can you give examples of the kind of decisions that you are able to make by having the schema up-front? -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5114) stop tracking IndexCommit in replication handler
Yonik Seeley created SOLR-5114: -- Summary: stop tracking IndexCommit in replication handler Key: SOLR-5114 URL: https://issues.apache.org/jira/browse/SOLR-5114 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Trivial It seems like indexCommitPoint tries to track the latest index commit. This doesn't seem necessary and could lead to bugs if it's not tracked correctly. We should always be able to ask the deletion policy for the latest commit (including a fallback mechanism if no IW has yet been opened) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4818) approach Guice for plugins
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-4818: --- Summary: approach Guice for plugins (was: Guice vs Solr) approach Guice for plugins -- Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4799) SQLEntityProcessor for zipper join
[ https://issues.apache.org/jira/browse/SOLR-4799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728987#comment-13728987 ] Mikhail Khludnev commented on SOLR-4799: [~jdyer] any chance you have a look? SQLEntityProcessor for zipper join -- Key: SOLR-4799 URL: https://issues.apache.org/jira/browse/SOLR-4799 Project: Solr Issue Type: New Feature Components: contrib - DataImportHandler Reporter: Mikhail Khludnev Priority: Minor Labels: dih Attachments: SOLR-4799.patch DIH is mostly considered as a playground tool, and real usages end up with SolrJ. I want to contribute few improvements target DIH performance. This one provides performant approach for joining SQL Entities with miserable memory at contrast to http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor The idea is: * parent table is explicitly ordered by it’s PK in SQL * children table is explicitly ordered by parent_id FK in SQL * children entity processor joins ordered resultsets by ‘zipper’ algorithm. Do you think it’s worth to contribute it into DIH? cc: [~goksron] [~jdyer] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Typos in Lucene exceptions for stored term vectors
I stumbled across the following Lucene exceptions that each have the same typo
– they do not output a closing quote and parenthesis:
In org.apache.lucene.index.TermVectorsConsumerPerField.start (branch_4x):
if (field.fieldType().storeTermVectorOffsets()) {
throw new IllegalArgumentException(cannot index term vector offsets when
term vectors are not indexed (field=\ + field.name());
}
if (field.fieldType().storeTermVectorPositions()) {
throw new IllegalArgumentException(cannot index term vector positions
when term vectors are not indexed (field=\ + field.name());
}
if (field.fieldType().storeTermVectorPayloads()) {
throw new IllegalArgumentException(cannot index term vector payloads
when term vectors are not indexed (field=\ + field.name());
}
}
} else {
if (field.fieldType().storeTermVectors()) {
throw new IllegalArgumentException(cannot index term vectors when field is
not indexed (field=\ + field.name());
}
if (field.fieldType().storeTermVectorOffsets()) {
throw new IllegalArgumentException(cannot index term vector offsets when
field is not indexed (field=\ + field.name());
}
if (field.fieldType().storeTermVectorPositions()) {
throw new IllegalArgumentException(cannot index term vector positions when
field is not indexed (field=\ + field.name());
}
if (field.fieldType().storeTermVectorPayloads()) {
throw new IllegalArgumentException(cannot index term vector payloads when
field is not indexed (field=\ + field.name());
}
Change:
(field=\ + field.name()
to
(field=\ + field.name() + \)
The specific exception I got from Solr:
24671 [qtp22111754-10] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:java.lang.IllegalArgumentException: cannot index term vector positions
when term vectors are not indexed (field=term_pos
at
org.apache.lucene.index.TermVectorsConsumerPerField.start(TermVectorsConsumerPerField.java:86)
-- Jack Krupansky
Re: Welcome Cassandra Targett as Lucene/Solr committer
Welcome Cassandra! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 1. aug. 2013 kl. 00:47 skrev Robert Muir rcm...@gmail.com: I'm pleased to announce that Cassandra Targett has accepted to join our ranks as a committer. Cassandra worked on the donation of the new Solr Reference Guide [1] and getting things in order for its first official release [2]. Cassandra, it is tradition that you introduce yourself with a brief bio. Welcome! P.S. As soon as your SVN access is setup, you should then be able to add yourself to the committers list on the website as well. [1] https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide [2] https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide/
[jira] [Updated] (SOLR-4818) Refactorings to simplify loading, organization, sharing of cores, etc.
[ https://issues.apache.org/jira/browse/SOLR-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-4818: -- Summary: Refactorings to simplify loading, organization, sharing of cores, etc. (was: approach Guice for plugins) Refactorings to simplify loading, organization, sharing of cores, etc. -- Key: SOLR-4818 URL: https://issues.apache.org/jira/browse/SOLR-4818 Project: Solr Issue Type: Improvement Reporter: Mikhail Khludnev Assignee: Grant Ingersoll Hello, I want to follow up IRC log from SOLR-1393. At least, questions are: - how much guice do you accept: should it load only user's plugin or fully substitute solrconfig.xml? - is there any observable stages for this migration? I'm ccing [~grant_ingers...@yahoo.com] [~rcmuir] as persons who provided an interest or/and concerns about Guice. Please vote/ban! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Threshold Checks for Replication in solrconfig.xml
Hi, I think, it would be nice to configure Solr for the threshold checks before doing the index replication. This would stop a bad index to be copied over to the slaves which are ideally the ones serving the user requests. In our case, we will have Solr Indexer which will index the documents. Before starting the indexing process we disable the replication and then index the documents. Then perform the threshold checks and if we have a reasonable index then we enable the replication. So that the Solr Query Engines will have a good index to server the user queries. I have been thinking how it would be if we have this facility in Solr (solrconfig.xml) by default for everyone. We may have something like this inside the Replication Request Handler section (either master can check before enabling replciation or slave can check against the master before downloading the index, which ever is best, I think better master does this check so that all the slaves need not check for same thing against the master) lst name=thresholdchecks str query=id:[* TO *]10/str str query=id:[* TO *] AND type:movie4/str str query=id:[* TO *] AND type:music1/str /lst I think, this is a very common task for people using Solr replication. I am interested to work on this feature and commit the same. Before that I would like to know your views on this feature. If this is something already exists or coming up, please let me know! Thanks Regards, Kranti K Parisa http://www.linkedin.com/in/krantiparisa
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_25) - Build # 6881 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/6881/ Java: 32bit/jdk1.7.0_25 -client -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrServerTest Error Message: 2 threads leaked from SUITE scope at org.apache.solr.client.solrj.impl.CloudSolrServerTest: 1) Thread[id=15, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-SendThread(localhost.localdomain:38970), state=TIMED_WAITING, group=TGRP-CloudSolrServerTest] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:86) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:937) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:993) 2) Thread[id=16, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-EventThread, state=WAITING, group=TGRP-CloudSolrServerTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:491) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE scope at org.apache.solr.client.solrj.impl.CloudSolrServerTest: 1) Thread[id=15, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-SendThread(localhost.localdomain:38970), state=TIMED_WAITING, group=TGRP-CloudSolrServerTest] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:86) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:937) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:993) 2) Thread[id=16, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-EventThread, state=WAITING, group=TGRP-CloudSolrServerTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:491) at __randomizedtesting.SeedInfo.seed([CEE187F02B542D91]:0) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrServerTest Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=15, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-SendThread(localhost.localdomain:38970), state=TIMED_WAITING, group=TGRP-CloudSolrServerTest] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:984) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=15, name=TEST-CloudSolrServerTest.testDistribSearch-seed#[CEE187F02B542D91]-SendThread(localhost.localdomain:38970), state=TIMED_WAITING, group=TGRP-CloudSolrServerTest] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:984) at __randomizedtesting.SeedInfo.seed([CEE187F02B542D91]:0) FAILED: org.apache.solr.client.solrj.impl.CloudSolrServerTest.testDistribSearch Error Message: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:38970 within 3 ms Stack Trace: java.lang.RuntimeException: java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 127.0.0.1:38970 within 3 ms at __randomizedtesting.SeedInfo.seed([CEE187F02B542D91:4F0709E85C0B4DAD]:0) at org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:130) at org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:93) at org.apache.solr.common.cloud.SolrZkClient.init(SolrZkClient.java:84) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:89) at org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:83) at org.apache.solr.cloud.AbstractDistribZkTestBase.setUp(AbstractDistribZkTestBase.java:70) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.setUp(AbstractFullDistribZkTestBase.java:190) at org.apache.solr.client.solrj.impl.CloudSolrServerTest.setUp(CloudSolrServerTest.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
