[jira] [Commented] (SOLR-6191) Self Describing SearchComponents, RequestHandlers, params. etc.
[ https://issues.apache.org/jira/browse/SOLR-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083889#comment-14083889 ] Noble Paul commented on SOLR-6191: -- I guess it is better to use java annotations to describe the params than using interfaces. The problem with interfaces is that you need to instantiate a class to get the details. I shall take another stab at this and post a patch > Self Describing SearchComponents, RequestHandlers, params. etc. > --- > > Key: SOLR-6191 > URL: https://issues.apache.org/jira/browse/SOLR-6191 > Project: Solr > Issue Type: Bug >Reporter: Vitaliy Zhovtyuk > Labels: features > Attachments: SOLR-6191.patch > > > We should have self describing parameters for search components, etc. > I think we should support UNIX style short and long names and that you should > also be able to get a short description of what a parameter does if you ask > for INFO on it. > For instance, &fl could also be &fieldList, etc. > Also, we should put this into the base classes so that new components can add > to it. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083888#comment-14083888
]
Shai Erera commented on SOLR-912:
-
One other thing, how important is it to be able to store {{null}} names? I
haven't dug deep through the code -- do we actually use it? This doesn't
prevent us from using a Map internally, as we can use our own key, something
like "$$NULL_STRING!!" (or pick some other constant) and map the null-name
requests to this key.
> org.apache.solr.common.util.NamedList - Typesafe efficient variant -
> ModernNamedList introduced - implementing the same API as NamedList
>
>
> Key: SOLR-912
> URL: https://issues.apache.org/jira/browse/SOLR-912
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies
>Reporter: Karthik K
>Priority: Minor
> Attachments: NLProfile.java, SOLR-912.patch, SOLR-912.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> The implementation of NamedList - while being fast - is not necessarily
> type-safe. I have implemented an additional implementation of the same -
> ModernNamedList (a type-safe variation providing the same interface as
> NamedList) - while preserving the semantics in terms of ordering of elements
> and allowing null elements for key and values (keys are always Strings ,
> while values correspond to generics ).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083884#comment-14083884
]
Shai Erera edited comment on SOLR-912 at 8/3/14 6:22 AM:
-
Resurrecting that issue, I reviewed NamedList and I don't understand why it has
to be so complicated:
* Its {{}} generic results in TONS of warnings in eclipse, for no good
reason. I don't buy this comment made on the issue that it's better to make it
generic than not. If we have a generic API which isn't used like that, it calls
for a bad API IMO. From what I can see, NamedList is not supposed to be generic
at all, as its main purpose is to allow you to store a heterogeneous list of
{{}} pairs, where name is always String, and the type of {{value}}
may differ. If we want to make it more convenient for people who know e.g. all
values are Strings, we can add sugar methods like {{getInt(), getString()...}}.
I've also briefly reviewed some classes that use NamedList (outside of tests),
and none seem to rely on {{}} at all. So I'd rather we remove that generic
from the API signature.
* There is what seems to be a totally redundant {{SimpleOrderedMap}} class,
which has contradicting documentation in its class-jdocs:
** _a {{NamedList}} where access by key is more important than maintaining
order_
** _This class does not provide efficient lookup by key_
But the class doesn't add any additional data structures, contains only 3 ctors
which delegate as-is to NamedList and offers a clone() which is identical to
NamedList.clone(). Yet there are 574 references to it (per-eclipse) ... I think
this class is just confusing and has to go away.
Leaving performance aside for a second, NamedList could simply hold an internal
{{Map>}} to enable efficient access by key, remove all
values of a key, access a key's values in order etc. It doesn't allow accessing
the {{}} pairs in any order though, i.e. {{getVal\(i\)}}. I don't
know how important is this functionality though .. i.e. if we replaced it with
a {{namesIterator()}}, would it not allow roughly the same thing? I'm kind of
sure it does, but there are so many uses of NamedList across the Solr code base
that I might be missing a case which won't like it. So I'd like to ask the Solr
folks who know this code better than me -- how important is
{{getName/Val\(i\)}}?
Now back to performance, for a sec, in order to not always allocate a
{{List}} when NamedList is used to hold only one value per parameter,
we can either:
* Use Collections.singletonList() on first _add_, and change to a concrete List
on the second _add_ only.
* Use an {{Object[]}}, it's less expensive than a List object.
* Use a Map internally and do instanceof checks on add/get as
appropriate.
BUT, if accessing/removing values by name is not important and it's OK if
get\(i\) is run on O(N), we can simply simplify the class, like Yonik's
proposal above, to hold an Object[] array (instead of List). But I think we
should remove the generic anyway.
Maybe we should break this down into 3 issues:
* Get rid of SimpleOrderedMap -- if it's important to keep in 4x, I can
deprecate and move all uses of it to NamedList directly.
* Remove the generics from NamedList's API. We can add sugar getters for
specific types if we want.
* Simplify NamedList internal implementation. On the performance side -- how
critical is NamedList on the execution path? I don't like micro-benchmarks too
much, so if NamedList is only a fraction of an entire execution path, I'd
rather it's even a tad slower but readable and easier to use/maintain, than if
it's overly complicated only to buy us a few nanos in the overall request.
was (Author: shaie):
Resurrecting that issue, I reviewed NamedList and I don't understand why it has
to be so complicated:
* Its {{}} generic results in TONS of warnings in eclipse, for no good
reason. I don't buy this comment made on the issue that it's better to make it
generic than not. If we have a generic API which isn't used like that, it calls
for a bad API IMO. From what I can see, NamedList is not supposed to be generic
at all, as its main purpose is to allow you to store a heterogeneous list of
{{}} pairs, where name is always String, and the type of {{value}}
may differ. If we want to make it more convenient for people who know e.g. all
values are Strings, we can add sugar methods like {{getInt(), getString()...}}.
I've also briefly reviewed some classes that use NamedList (outside of tests),
and none seem to rely on {{}} at all. So I'd rather we remove that generic
from the API signature.
* There is what seems to be a totally redundant {{SimpleOrderedMap}} class,
which has contradicting documentation in its class-jdocs:
** _a {{NamedList}} where access by key is more important than maintaining
order_
** _This class does not provide efficient lookup by key_
But the cla
[jira] [Comment Edited] (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083884#comment-14083884
]
Shai Erera edited comment on SOLR-912 at 8/3/14 6:21 AM:
-
Resurrecting that issue, I reviewed NamedList and I don't understand why it has
to be so complicated:
* Its {{}} generic results in TONS of warnings in eclipse, for no good
reason. I don't buy this comment made on the issue that it's better to make it
generic than not. If we have a generic API which isn't used like that, it calls
for a bad API IMO. From what I can see, NamedList is not supposed to be generic
at all, as its main purpose is to allow you to store a heterogeneous list of
{{}} pairs, where name is always String, and the type of {{value}}
may differ. If we want to make it more convenient for people who know e.g. all
values are Strings, we can add sugar methods like {{getInt(), getString()...}}.
I've also briefly reviewed some classes that use NamedList (outside of tests),
and none seem to rely on {{}} at all. So I'd rather we remove that generic
from the API signature.
* There is what seems to be a totally redundant {{SimpleOrderedMap}} class,
which has contradicting documentation in its class-jdocs:
** _a {{NamedList}} where access by key is more important than maintaining
order_
** _This class does not provide efficient lookup by key_
But the class doesn't add any additional data structures, contains only 3 ctors
which delegate as-is to NamedList and offers a clone() which is identical to
NamedList.clone(). Yet there are 574 references to it (per-eclipse) ... I think
this class is just confusing and has to go away.
Leaving performance aside for a second, NamedList could simply hold an internal
{{Map>}} to enable efficient access by key, remove all
values of a key, access a key's values in order etc. It doesn't allow accessing
the {{}} pairs in any order though, i.e. {{getVal(i)}}. I don't
know how important is this functionality though .. i.e. if we replaced it with
a {{namesIterator()}}, would it not allow roughly the same thing? I'm kind of
sure it does, but there are so many uses of NamedList across the Solr code base
that I might be missing a case which won't like it. So I'd like to ask the Solr
folks who know this code better than me -- how important is {{getName/Val(i)}}?
Now back to performance, for a sec, in order to not always allocate a
{{List}} when NamedList is used to hold only one value per parameter,
we can either:
* Use Collections.singletonList() on first _add_, and change to a concrete List
on the second _add_ only.
* Use an {{Object[]}}, it's less expensive than a List object.
* Use a Map internally and do instanceof checks on add/get as
appropriate.
BUT, if accessing/removing values by name is not important and it's OK if
get(i) is run on O(N), we can simply simplify the class, like Yonik's proposal
above, to hold an Object[] array (instead of List). But I think we should
remove the generic anyway.
Maybe we should break this down into 3 issues:
* Get rid of SimpleOrderedMap -- if it's important to keep in 4x, I can
deprecate and move all uses of it to NamedList directly.
* Remove the generics from NamedList's API. We can add sugar getters for
specific types if we want.
* Simplify NamedList internal implementation. On the performance side -- how
critical is NamedList on the execution path? I don't like micro-benchmarks too
much, so if NamedList is only a fraction of an entire execution path, I'd
rather it's even a tad slower but readable and easier to use/maintain, than if
it's overly complicated only to buy us a few nanos in the overall request.
was (Author: shaie):
Resurrecting that issue, I reviewed NamedList and I don't understand why it has
to be so complicated:
* Its {{}} generic cause nothing but TONS of warnings in eclipse, for no
good reason. I don't buy this comment made on the issue that it's better to
make it generic than not. If we have a generic API which isn't used like that,
it calls for a bad API IMO. From what I can see, NamedList is not supposed to
be generic at all, as its main purpose is to allow you to store a heterogeneous
list of {{}} pairs, where name is always String, and the type of
{{value}} may differ. If we want to make it more convenient for people who know
e.g. all values are Strings, we can add sugar methods like {{getInt(),
getString()...}}. I've also briefly reviewed some classes that use NamedList
(outside of tests), and none seem to rely on {{}} at all. So I'd rather we
remove that generic from the API signature.
* There is what seems to be a totally redundant {{SimpleOrderedMap}} class,
which has contradicting documentation in its ctor:
** _a {{NamedList}} where access by key is more important than maintaining
order_
** _This class does not provide efficient lookup by key_
But the class does
[jira] [Commented] (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083884#comment-14083884
]
Shai Erera commented on SOLR-912:
-
Resurrecting that issue, I reviewed NamedList and I don't understand why it has
to be so complicated:
* Its {{}} generic cause nothing but TONS of warnings in eclipse, for no
good reason. I don't buy this comment made on the issue that it's better to
make it generic than not. If we have a generic API which isn't used like that,
it calls for a bad API IMO. From what I can see, NamedList is not supposed to
be generic at all, as its main purpose is to allow you to store a heterogeneous
list of {{}} pairs, where name is always String, and the type of
{{value}} may differ. If we want to make it more convenient for people who know
e.g. all values are Strings, we can add sugar methods like {{getInt(),
getString()...}}. I've also briefly reviewed some classes that use NamedList
(outside of tests), and none seem to rely on {{}} at all. So I'd rather we
remove that generic from the API signature.
* There is what seems to be a totally redundant {{SimpleOrderedMap}} class,
which has contradicting documentation in its ctor:
** _a {{NamedList}} where access by key is more important than maintaining
order_
** _This class does not provide efficient lookup by key_
But the class doesn't add any additional data structures, contains only 3 ctors
which delegate as-is to NamedList and offers a clone() which is identical to
NamedList.clone(). Yet there are 574 references to it (per-eclipse) ... I think
this class is just confusing and has to go away.
Leaving performance aside for a second, NamedList could simply hold an internal
{{Map>}} to enable efficient access by key, remove all
values of a key, access a key's values in order etc. It doesn't allow accessing
the {{}} pairs in any order though, i.e. {{getVal(i)}}. I don't
know how important is this functionality though .. i.e. if we replaced it with
a {{namesIterator()}}, would it not allow roughly the same thing? I'm kind of
sure it does, but there are so many uses of NamedList across the Solr code base
that I might be missing a case which won't like it. So I'd like to ask the Solr
folks who know this code better than me -- how important is {{getName/Val(i)}}?
Now back to performance, for a sec, in order to not always allocate a
{{List}} when NamedList is used to hold only one value per parameter,
we can either:
* Use Collections.singletonList() on first _add_, and change to a concrete List
on the second _add_ only.
* Use an {{Object[]}}, it's less expensive than a List object.
* Use a Map internally and do instanceof checks on add/get as
appropriate.
BUT, if accessing/removing values by name is not important and it's OK if
get(i) is run on O(N), we can simply simplify the class, like Yonik's proposal
above, to hold an Object[] array (instead of List). But I think we should
remove the generic anyway.
Maybe we should break this down into 3 issues:
* Get rid of SimpleOrderedMap -- if it's important to keep in 4x, I can
deprecate and move all uses of it to NamedList directly.
* Remove the generics from NamedList's API. We can add sugar getters for
specific types if we want.
* Simplify NamedList internal implementation. On the performance side -- how
critical is NamedList on the execution path? I don't like micro-benchmarks too
much, so if NamedList is only a fraction of an entire execution path, I'd
rather it's even a tad slower but readable and easier to use/maintain, than if
it's overly complicated only to buy us a few nanos in the overall request.
> org.apache.solr.common.util.NamedList - Typesafe efficient variant -
> ModernNamedList introduced - implementing the same API as NamedList
>
>
> Key: SOLR-912
> URL: https://issues.apache.org/jira/browse/SOLR-912
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies
>Reporter: Karthik K
>Priority: Minor
> Attachments: NLProfile.java, SOLR-912.patch, SOLR-912.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> The implementation of NamedList - while being fast - is not necessarily
> type-safe. I have implemented an additional implementation of the same -
> ModernNamedList (a type-safe variation providing the same interface as
> NamedList) - while preserving the semantics in terms of ordering of elements
> and allowing null elements for key and values (keys are always Strings ,
> while values correspond to generics ).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
--
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_20-ea-b23) - Build # 4226 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4226/ Java: 64bit/jdk1.8.0_20-ea-b23 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:64978/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:64978/collection1 at __randomizedtesting.SeedInfo.seed([1B8F8D519FD8E272:9A690349E887824E]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:561) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:68) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:54) at org.apache.solr.schema.TestCloudSchemaless.doTest(TestCloudSchemaless.java:140) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:865) at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[jira] [Updated] (SOLR-6283) Add support for Interval Faceting in SolrJ
[ https://issues.apache.org/jira/browse/SOLR-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe updated SOLR-6283: Attachment: SOLR-6283.patch Here is a patch for this. I'm planning to add more javadocs > Add support for Interval Faceting in SolrJ > -- > > Key: SOLR-6283 > URL: https://issues.apache.org/jira/browse/SOLR-6283 > Project: Solr > Issue Type: Improvement >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson > Attachments: SOLR-6283.patch > > > Interval Faceting was added in SOLR-6216. Add support for it in SolrJ -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1712 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1712/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 29 tests failed. FAILED: org.apache.solr.hadoop.LineRandomizerMapperReducerTest.testMapReduce1Item Error Message: Could not initialize class org.apache.hadoop.util.StringUtils Stack Trace: java.lang.NoClassDefFoundError: Could not initialize class org.apache.hadoop.util.StringUtils at org.apache.hadoop.conf.Configuration.getStrings(Configuration.java:1514) at org.apache.hadoop.io.serializer.SerializationFactory.(SerializationFactory.java:58) at org.apache.hadoop.mrunit.internal.io.Serialization.(Serialization.java:37) at org.apache.hadoop.mrunit.TestDriver.getSerialization(TestDriver.java:464) at org.apache.hadoop.mrunit.TestDriver.copy(TestDriver.java:608) at org.apache.hadoop.mrunit.TestDriver.copyPair(TestDriver.java:612) at org.apache.hadoop.mrunit.MapReduceDriverBase.addInput(MapReduceDriverBase.java:70) at org.apache.hadoop.mrunit.MapReduceDriverBase.withInput(MapReduceDriverBase.java:124) at org.apache.solr.hadoop.LineRandomizerMapperReducerTest.testMapReduce1Item(LineRandomizerMapperReducerTest.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12) FAILED: org.apache.solr.hadoop.LineRandomizerMapperReducerTest.testMapReduce4Items Error Message: Could not initialize class org.apache.hadoop.util.StringUtils Stack Trace: java.lang.NoClassDefFoundError: Could not initialize class org.apache.hadoop.util.StringUtils at org.apache.hadoop.conf.Configuration.getStrings(Configuration.java:1514) at org.apache.hadoop.io.serializer.SerializationFactory.(SerializationFactory.java:58) at org.apache.hadoop.mrunit.internal.io.Serialization.(Serialization.java:37) at org.apache.hadoop.mrunit.TestDriver.getSerialization(TestDriver.java:464) at org.apache.hadoop.mrunit.TestDriver.copy(TestDriver.java:608) at org.apache.hadoop.mrunit.TestDriver.copyPair(TestDriver.java:612) at org.apache.hadoop.mrunit.MapReduceDriverBase.addInput(MapReduceDriverBase.java:70) at org.apache.hadoop.mrunit.MapReduceDriverBase.addInput(MapReduceDriverBase.java:80) at org.apache.hadoop.mrunit.MapReduceDriverBase.addAll(MapReduceDriverBase.java:91) at org.apache.hadoop.mrunit.MapReduceDriverBase.withAll(MapReduceDriverBase.java:166) at org.apache.solr.hadoop.LineRandomizerMapperReducerTest.testMapReduce4Items(LineRandomizerMapperReducerTest.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4788 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4788/ 1 tests failed. FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch Error Message: Captured an uncaught exception in thread: Thread[id=58612, name=qtp1292738159-58612, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=58612, name=qtp1292738159-58612, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Caused by: java.lang.OutOfMemoryError: unable to create new native thread at __randomizedtesting.SeedInfo.seed([375F71D63CFE4C1E]:0) at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:714) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1047) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:665) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11942 lines...] [junit4] Suite: org.apache.solr.cloud.MultiThreadedOCPTest [junit4] 2> Creating dataDir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/build/solr-core/test/J0/./temp/solr.cloud.MultiThreadedOCPTest-375F71D63CFE4C1E-001/init-core-data-001 [junit4] 2> 3334949 T58528 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (true) and clientAuth (true) [junit4] 2> 3334949 T58528 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: / [junit4] 2> 3334954 T58528 oas.SolrTestCaseJ4.setUp ###Starting testDistribSearch [junit4] 2> 3334954 T58528 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 1> client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 3334955 T58529 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2> 3335055 T58528 oasc.ZkTestServer.run start zk server on port:11080 [junit4] 2> 3335056 T58528 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 3335059 T58535 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@6ebfbb6c name:ZooKeeperConnection Watcher:127.0.0.1:11080 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 3335059 T58528 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 3335059 T58528 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2> 3335062 T58528 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 3335063 T58537 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@ffd0739 name:ZooKeeperConnection Watcher:127.0.0.1:11080/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 3335063 T58528 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 3335063 T58528 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2> 3335065 T58528 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2> 3335067 T58528 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2> 3335068 T58528 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2> 3335070 T58528 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 3335070 T58528 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2> 3335073 T58528 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [junit4] 2> 3335073 T58528 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2> 3335174 T58528 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 3335175 T58528 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 3335177 T58528 oasc.AbstractZkTestCase
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 596 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/596/ 1 tests failed. FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch Error Message: Captured an uncaught exception in thread: Thread[id=23276, name=qtp1841195327-23276, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=23276, name=qtp1841195327-23276, state=RUNNABLE, group=TGRP-MultiThreadedOCPTest] Caused by: java.lang.OutOfMemoryError: unable to create new native thread at __randomizedtesting.SeedInfo.seed([933813625380C6F5]:0) at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:714) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1047) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323) at org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:665) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 12577 lines...] [junit4] Suite: org.apache.solr.cloud.MultiThreadedOCPTest [junit4] 2> Creating dataDir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J1/./temp/solr.cloud.MultiThreadedOCPTest-933813625380C6F5-001/init-core-data-001 [junit4] 2> 4033473 T21591 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (true) and clientAuth (true) [junit4] 2> 4033474 T21591 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: /wx/t [junit4] 2> 4033477 T21591 oas.SolrTestCaseJ4.setUp ###Starting testDistribSearch [junit4] 2> 4033477 T21591 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 1> client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 4033478 T21592 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2> 4033578 T21591 oasc.ZkTestServer.run start zk server on port:41849 [junit4] 2> 4033584 T21591 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 4033588 T21598 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@516ecc1b name:ZooKeeperConnection Watcher:127.0.0.1:41849 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 4033588 T21591 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 4033589 T21591 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2> 4033612 T21591 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 4033613 T21600 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@36a00096 name:ZooKeeperConnection Watcher:127.0.0.1:41849/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 4033613 T21591 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 4033613 T21591 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2> 4033615 T21591 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2> 4033617 T21591 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2> 4033618 T21591 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2> 4033620 T21591 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 4033620 T21591 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2> 4033623 T21591 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/core/src/test-files/solr/collection1/conf/schema.xml to /configs/conf1/schema.xml [junit4] 2> 4033624 T21591 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2> 4033626 T21591 oasc.AbstractZkTestCase.putConfig put /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 4033626 T21591 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 4033628 T21591 oasc.AbstractZ
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1747 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1747/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.solr.cloud.OverseerTest.testOverseerFailure Error Message: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed Stack Trace: org.apache.solr.common.SolrException: Could not register as the leader because creating the ephemeral registration node in ZooKeeper failed at __randomizedtesting.SeedInfo.seed([2261C2321782AA10:26694DC105274531]:0) at org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:144) at org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:163) at org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:125) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:314) at org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:221) at org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:155) at org.apache.solr.cloud.OverseerTest.testOverseerFailure(OverseerTest.java:660) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.
[jira] [Commented] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083726#comment-14083726
]
Vamsee Yarlagadda commented on SOLR-6314:
-
Thanks @Erick. I was able to replicate the issue on Solr trunk (5.0)
Let me know if there is anything I can do to help in the process.
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
Re: [jira] [Created] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
Thanks @Erick. I was able to replicate the issue on Solr trunk (5.0)
Let me know if there is anything I can do to help in the process.
On Saturday, August 2, 2014, Erick Erickson (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083620#comment-14083620
> ]
>
> Erick Erickson commented on SOLR-6314:
> --
>
> I know something about that code so I'll try to take a look.
>
> I'm not entirely sure when I'll get to it though, I'm slammed. So
> if someone wants to look at it instead, please feel free.
>
> Vamsee:
>
> What version of Solr are you seeing this on?
>
> > Multi-threaded facet counts differ when SolrCloud has >1 shard
> > --
> >
> > Key: SOLR-6314
> > URL: https://issues.apache.org/jira/browse/SOLR-6314
> > Project: Solr
> > Issue Type: Bug
> > Components: SearchComponents - other, SolrCloud
> >Affects Versions: 5.0
> >Reporter: Vamsee Yarlagadda
> >Assignee: Erick Erickson
> >
> > I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> > I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> >
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> > Setup:
> > - *Indexed 50 docs into SolrCloud.*
> > - *If the SolrCloud has only 1 shard, the facet field query has the
> below output (which matches with the expected upstream test output - #
> facet fields ~ 50).*
> > {code}
> > $ curl "
> http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml
> "
> >
> >
> >
> > 0
> > 21
> >
> > true
> > id
> > true
> > id:*
> > -1
> > 1000
> >
> > f0_ws
> > f0_ws
> > f0_ws
> > f0_ws
> > f0_ws
> > f1_ws
> > f1_ws
> > f1_ws
> > f1_ws
> > f1_ws
> > f2_ws
> > f2_ws
> > f2_ws
> > f2_ws
> > f2_ws
> > f3_ws
> > f3_ws
> > f3_ws
> > f3_ws
> > f3_ws
> > f4_ws
> > f4_ws
> > f4_ws
> > f4_ws
> > f4_ws
> > f5_ws
> > f5_ws
> > f5_ws
> > f5_ws
> > f5_ws
> > f6_ws
> > f6_ws
> > f6_ws
> > f6_ws
> > f6_ws
> > f7_ws
> > f7_ws
> > f7_ws
> > f7_ws
> > f7_ws
> > f8_ws
> > f8_ws
> > f8_ws
> > f8_ws
> > f8_ws
> > f9_ws
> > f9_ws
> > f9_ws
> > f9_ws
> > f9_ws
> >
> > xml
> > 1
> >
> >
> >
> >
> > 0.0
> >
> >
> >
> >
> >
> > 25
> > 25
> >
> >
> > 25
> > 25
> >
> >
> > 25
> > 25
> >
> >
> > 25
> > 25
> >
> >
> > 25
> > 25
> >
> >
> > 33
> > 17
> >
> >
> > 33
> > 17
> >
> >
> > 33
> > 17
> >
> >
> > 33
> > 17
> >
> >
> > 33
> > 17
> >
> >
> > 37
> > 13
> >
> >
> > 37
> > 13
> >
> >
> > 37
> > 13
> >
> >
> > 37
> > 13
> >
> >
> > 37
> > 13
> >
> >
> > 40
> > 10
> >
> >
> > 40
> > 10
> >
> >
> > 40
> > 10
> >
> >
> > 40
> > 10
> >
> >
> > 40
> > 10
> >
> >
> > 41
> > 9
> >
> >
> > 41
> > 9
> >
> >
> > 41
> > 9
> >
> >
> > 41
> > 9
> >
> >
> > 41
> > 9
> >
> >
> > 42
> >
[jira] [Resolved] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array
[
https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-6294.
--
Resolution: Fixed
> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
> Issue Type: Bug
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6294-6304.patch
>
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> [
> {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6302) Add implicit update request handlers
[
https://issues.apache.org/jira/browse/SOLR-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083670#comment-14083670
]
ASF subversion and git services commented on SOLR-6302:
---
Commit 1615347 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1615347 ]
SOLR-6294 ,SOLR-6302
> Add implicit update request handlers
>
>
> Key: SOLR-6302
> URL: https://issues.apache.org/jira/browse/SOLR-6302
> Project: Solr
> Issue Type: Sub-task
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 4.10
>
>
> like we add implicit responseWriters lets add implicit updatehandlers also
> and get rid of the following from solrconfig.xml
> {code:xml}
>
>
>
>
>
>
>
> application/json
>
>
>
>
>
> application/json
> doc
>
>
>
>
> application/csv
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6302) Add implicit update request handlers
[
https://issues.apache.org/jira/browse/SOLR-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-6302:
-
Fix Version/s: 4.10
> Add implicit update request handlers
>
>
> Key: SOLR-6302
> URL: https://issues.apache.org/jira/browse/SOLR-6302
> Project: Solr
> Issue Type: Sub-task
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 4.10
>
>
> like we add implicit responseWriters lets add implicit updatehandlers also
> and get rid of the following from solrconfig.xml
> {code:xml}
>
>
>
>
>
>
>
> application/json
>
>
>
>
>
> application/json
> doc
>
>
>
>
> application/csv
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6302) Add implicit update request handlers
[
https://issues.apache.org/jira/browse/SOLR-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-6302.
--
Resolution: Fixed
> Add implicit update request handlers
>
>
> Key: SOLR-6302
> URL: https://issues.apache.org/jira/browse/SOLR-6302
> Project: Solr
> Issue Type: Sub-task
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> like we add implicit responseWriters lets add implicit updatehandlers also
> and get rid of the following from solrconfig.xml
> {code:xml}
>
>
>
>
>
>
>
> application/json
>
>
>
>
>
> application/json
> doc
>
>
>
>
> application/csv
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array
[
https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083669#comment-14083669
]
ASF subversion and git services commented on SOLR-6294:
---
Commit 1615347 from [~noble.paul] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1615347 ]
SOLR-6294 ,SOLR-6302
> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
> Issue Type: Bug
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6294-6304.patch
>
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> [
> {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk7) - Build # 10826 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10826/
Java: 64bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION:
org.apache.lucene.analysis.phonetic.TestPhoneticFilter.testRandomStrings
Error Message:
Stack Trace:
java.lang.NullPointerException
at
org.apache.lucene.codecs.lucene49.Lucene49NormsConsumer$NormMap.add(Lucene49NormsConsumer.java:226)
at
org.apache.lucene.codecs.lucene49.Lucene49NormsConsumer.addNumericField(Lucene49NormsConsumer.java:95)
at
org.apache.lucene.index.NumericDocValuesWriter.flush(NumericDocValuesWriter.java:92)
at
org.apache.lucene.index.DefaultIndexingChain.writeNorms(DefaultIndexingChain.java:190)
at
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:94)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:441)
at
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:504)
at
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3270)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3246)
at
org.apache.lucene.index.IndexWriter.closeInternal(IndexWriter.java:1038)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:982)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:944)
at
org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:373)
at org.apache.lucene.util.IOUtils.close(IOUtils.java:77)
at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:541)
at
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:432)
at
org.apache.lucene.analysis.phonetic.TestPhoneticFilter.testRandomStrings(TestPhoneticFilter.java:90)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:619)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array
[
https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083659#comment-14083659
]
ASF subversion and git services commented on SOLR-6294:
---
Commit 1615345 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1615345 ]
SOLR-6294 ,SOLR-6302
> The JsonLoader should accept a single doc without wrapping in an array
> --
>
> Key: SOLR-6294
> URL: https://issues.apache.org/jira/browse/SOLR-6294
> Project: Solr
> Issue Type: Bug
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-6294-6304.patch
>
>
> This is the multi document input command
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> [
> {"id" : "TestDoc1", "title" : "test1"},
> ]'
> {noformat}
> The following also should be a valid update command for a single doc
> {noformat}
> curl http://localhost:8983/solr/update/json -H
> 'Content-type:application/json' -d '
> {"id" : "TestDoc1", "title" : "test1"},
> '
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6302) Add implicit update request handlers
[
https://issues.apache.org/jira/browse/SOLR-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083660#comment-14083660
]
ASF subversion and git services commented on SOLR-6302:
---
Commit 1615345 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1615345 ]
SOLR-6294 ,SOLR-6302
> Add implicit update request handlers
>
>
> Key: SOLR-6302
> URL: https://issues.apache.org/jira/browse/SOLR-6302
> Project: Solr
> Issue Type: Sub-task
> Components: update
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> like we add implicit responseWriters lets add implicit updatehandlers also
> and get rid of the following from solrconfig.xml
> {code:xml}
>
>
>
>
>
>
>
> application/json
>
>
>
>
>
> application/json
> doc
>
>
>
>
> application/csv
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5850) Constants#LUCENE_MAIN_VERSION can have broken values
[ https://issues.apache.org/jira/browse/LUCENE-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083636#comment-14083636 ] Shai Erera commented on LUCENE-5850: Thanks Uwe for adding the docs, they are crystal clear. > Constants#LUCENE_MAIN_VERSION can have broken values > - > > Key: LUCENE-5850 > URL: https://issues.apache.org/jira/browse/LUCENE-5850 > Project: Lucene - Core > Issue Type: Bug > Components: general/build >Affects Versions: 4.3.1, 4.5.1 >Reporter: Simon Willnauer > Fix For: 5.0, 4.10 > > Attachments: LUCENE-5850.patch, LUCENE-5850.patch, LUCENE-5850.patch, > LUCENE-5850.patch, LUCENE-5850.patch, LUCENE-5850.patch, > LUCENE-5850_bomb.patch, LUCENE-5850_smoketester.patch > > > Constants#LUCENE_MAIN_VERSION is set to the Lucene Main version and should > not contain minor versions. Well this is at least what I thought and to my > knowledge what the comments say too. Yet in for instance 4.3.1 and 4.5.1 we > broke this such that the version from SegmentsInfo can not be parsed with > Version#parseLeniently. IMO we should really add an assertion that this > constant doesn't throw an error and / or make the smoketester catch this. to > me this is actually a index BWC break. Note that 4.8.1 doesn't have this > problem... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6300) facet.mincount fails to work if SolrCloud distrib=true is set
[
https://issues.apache.org/jira/browse/SOLR-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083630#comment-14083630
]
Erick Erickson commented on SOLR-6300:
--
Since I'll be in that code anyway, I might as well take a look.
> facet.mincount fails to work if SolrCloud distrib=true is set
> -
>
> Key: SOLR-6300
> URL: https://issues.apache.org/jira/browse/SOLR-6300
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I notice that using facet.mincount in SolrCloud mode with distrib=true fails
> to filter the facets based on the count. However, the same query with
> distrib=false works as expected.
> * Indexed some data as provided by the upstream test.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L633
> * Test being run:
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L657
> * Running in SolrCloud mode with distrib=false (facet.mincount works as
> expected)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=false";
>
>
>
> 0
> 3
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> false
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 0
> 6
>
>
>
>
>
> {code}
> * SolrCloud mode with distrib=true (facet.mincount fails to show effect)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=true";
>
>
>
> 0
> 12
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> true
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 0
> 0
> 2
> 2
> 2
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 1
> 0
> 2
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 1
> 11
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-6300) facet.mincount fails to work if SolrCloud distrib=true is set
[
https://issues.apache.org/jira/browse/SOLR-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-6300:
Assignee: Erick Erickson
> facet.mincount fails to work if SolrCloud distrib=true is set
> -
>
> Key: SOLR-6300
> URL: https://issues.apache.org/jira/browse/SOLR-6300
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I notice that using facet.mincount in SolrCloud mode with distrib=true fails
> to filter the facets based on the count. However, the same query with
> distrib=false works as expected.
> * Indexed some data as provided by the upstream test.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L633
> * Test being run:
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/SimpleFacetsTest.java#L657
> * Running in SolrCloud mode with distrib=false (facet.mincount works as
> expected)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=false";
>
>
>
> 0
> 3
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> false
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 1
> 1
> 1
> 1
> 1
> 1
> 1
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 0
> 6
>
>
>
>
>
> {code}
> * SolrCloud mode with distrib=true (facet.mincount fails to show effect)
> {code}
> $ curl
> "http://search-testing-c5-3.ent.cloudera.com:8983/solr/simple_faceting_coll/select?facet.date.start=1976-07-01T00%3A00%3A00.000Z&facet=true&facet.mincount=1&q=*%3A*&facet.date=bday&facet.date.other=all&facet.date.gap=%2B1DAY&facet.date.end=1976-07-01T00%3A00%3A00.000Z%2B1MONTH&rows=0&indent=true&wt=xml&distrib=true";
>
>
>
> 0
> 12
>
> 1976-07-01T00:00:00.000Z
> true
> true
> 1
> *:*
> bday
> true
> +1DAY
> all
> xml
> 1976-07-01T00:00:00.000Z+1MONTH
> 0
>
>
>
>
>
>
>
>
>
> 0
> 0
> 2
> 2
> 2
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 1
> 0
> 2
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 0
> 1
> 0
> +1DAY
> 1976-07-01T00:00:00Z
> 1976-08-01T00:00:00Z
> 2
> 1
> 11
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene versioning logic
Another proposal that I made on LUCENE-5859 is to get rid of Version (for Analyzers) and follow the solution we have with Codecs. If an Analyzer changes its runtime behavior, and e.g not marked @experimental, it can create a Foo49Analyzer with the new behavior. That way, apps are still safe when they upgrade, since their Foo45Analyzer still exists (but deprecated). And they can always copy a Foo45Analyzer when they upgrade to Lucene 6.0 where it no longer exists... with this approach, there's no single version across the app - it just uses the specific Analyzer impls. Anyway, +1 to make bugfix release first class citizens. That's also the only way to make sure we support back compat if a bug is fixed in an Analyzer in e.g. 4.8.2. Shai On Sat, Aug 2, 2014 at 11:54 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > +1, this sounds like a great solution. It simplifies the APIs (no > more required Version to Analyzer), it consolidates the version logic > to a "single source", dot releases are first class. > > Mike McCandless > > http://blog.mikemccandless.com > > > On Fri, Aug 1, 2014 at 7:47 PM, Ryan Ernst wrote: > > There has been a lot of heated discussion recently about version > > tracking in Lucene [1] [2]. I wanted to have a fresh discussion > > outside of jira to give a full description of the current state of > > things, the problems I have heard, and a proposed solution. > > > > CURRENT > > > > We have 2 pieces of code that handle “versioning.” The first is > > Constants.LUCENE_MAIN_VERSION, which is written to the SegmentsInfo > > for each segment. This is a string version which is used to detect > > when the current version of lucene is newer than the version that > > wrote the segment (and how/if an upgrade to to a newer codec should be > > done). There is some complication with the “display” version and > > non-display version, which are distinguished by whether the version of > > lucene was an official release, or an alpha/beta version (which was > > added specifically for the 4.0.0 release ramp up). This string > > version also has its own parsing and comparison methods. > > > > The second piece of versioning code is in Version.java, which is an > > enum used by analyzers to maintain backwards compatible behavior given > > a specific version of lucene. The enum only contains values for dot > > releases of lucene, not bug fixes (which was what spurred the recent > > discussions over version). Analyzers’ constructors take a required > > Version parameter, which is only actually used by the few analyzers > > that have changed behavior recently. Version.java contains a separate > > version parsing and comparison methods. > > > > > > CONCERNS > > > > * Having 2 different pieces of code that do very similar things is > > confusing for development. Very few developers appear to really > > understand the current system (especially when trying to understand > > the alpha/beta setup). > > > > * Users are generally confused by the Version passed to analyzers: I > > know I was when I first started working with Lucene, and > > Version.CURRENT_VERSION was deprecated because users used that without > > understanding the implications. > > > > * Most analyzers currently have dead code constructors, since they > > never make use of Version. There are also a lot of classes used by > > analyzers which contain similar dead code. > > > > * Backwards compatibility needs to be handled in some fashion, to > > ensure users have a path to upgrade from one version of lucene to > > another, without requiring immediate re-indexing. > > > > > > PROPOSAL > > > > I propose the following: > > > > * Consolidate all version related enumeration, including reading and > > writing string versions, into Version.java. Have a static method that > > returns the current lucene version (replacing > > Constants.LUCENE_MAIN_VERSION). > > > > * Make bug fix releases first class in the enumeration, so that they > > can be distinguished for any compatibility issues that come up. > > > > * Remove all snapshot/alpha/beta versioning logic. Alpha/beta was > > really only necessary for 4.0 because of the extreme changes that were > > being made. The system is much more stable now, and 5.0 should not > > require preview releases, IMO. I don’t think snapshots should be a > > concern because any user building an index from an unreleased build > > (which they built themselves) is just asking for trouble. They do so > > at their own risk (of figuring out how to upgrade their indexes if > > they are not trash-able). Backwards compatibility can be handled by > > adding the alpha/beta/final versions of 4.0 to the enum (and special > > parsing logic for this). If lucene changes so much that we need > > alpha/beta type discrimination in the future, we can revisit the > > system if simply having extra versions in the enum won't work. > > > > * Analyzers constructors should have Version removed, and a setter > > should be added
[jira] [Commented] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083620#comment-14083620
]
Erick Erickson commented on SOLR-6314:
--
I know something about that code so I'll try to take a look.
I'm not entirely sure when I'll get to it though, I'm slammed. So
if someone wants to look at it instead, please feel free.
Vamsee:
What version of Solr are you seeing this on?
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
>
[jira] [Commented] (LUCENE-5861) CachingTokenFilter should use ArrayList not LinkedList
[ https://issues.apache.org/jira/browse/LUCENE-5861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14083617#comment-14083617 ] Paul Elschot commented on LUCENE-5861: -- TeeSinkTokenFilter.SinkTokenStream in the analysis comon module (o.a.l.analysis.sinks) uses a LinkedList, too. I also prefer an ArrayList, but I used a LinkedList also in the PrefillTokenStream of LUCENE-5687 because the existing code uses it and I don't know of any existing performance tests for this. To grow an ArrayList would it be good to use ArrayUtil.oversize() ? > CachingTokenFilter should use ArrayList not LinkedList > -- > > Key: LUCENE-5861 > URL: https://issues.apache.org/jira/browse/LUCENE-5861 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/analysis >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > > CachingTokenFilter, to my surprise, puts each new AttributeSource.State onto > a LinkedList. I think it should be an ArrayList. On large fields that get > analyzed, there can be a ton of State objects to cache. > I also observe that State is itself a linked list of other State objects. > Perhaps we could take this one step further and do parallel arrays of > AttributeImpl, thereby bypassing State. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk7) - Build # 10825 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10825/
Java: 32bit/ibm-j9-jdk7
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION: org.apache.solr.update.HardAutoCommitTest.testCommitWithin
Error Message:
Exception during query
Stack Trace:
java.lang.RuntimeException: Exception during query
at
__randomizedtesting.SeedInfo.seed([DB40B62D4BAC950E:6192D955C8827B1B]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:706)
at
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:619)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:853)
Caused by: java.lang.Runti
[jira] [Assigned] (SOLR-6314) Multi-threaded facet counts differ when SolrCloud has >1 shard
[
https://issues.apache.org/jira/browse/SOLR-6314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson reassigned SOLR-6314:
Assignee: Erick Erickson
> Multi-threaded facet counts differ when SolrCloud has >1 shard
> --
>
> Key: SOLR-6314
> URL: https://issues.apache.org/jira/browse/SOLR-6314
> Project: Solr
> Issue Type: Bug
> Components: SearchComponents - other, SolrCloud
>Affects Versions: 5.0
>Reporter: Vamsee Yarlagadda
>Assignee: Erick Erickson
>
> I am trying to work with multi-threaded faceting on SolrCloud and in the
> process i was hit by some issues.
> I am currently running the below upstream test on different SolrCloud
> configurations and i am getting a different result set per configuration.
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/test/org/apache/solr/request/TestFaceting.java#L654
> Setup:
> - *Indexed 50 docs into SolrCloud.*
> - *If the SolrCloud has only 1 shard, the facet field query has the below
> output (which matches with the expected upstream test output - # facet fields
> ~ 50).*
> {code}
> $ curl
> "http://localhost:8983/solr/collection1/select?facet=true&fl=id&indent=true&q=id%3A*&facet.limit=-1&facet.threads=1000&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f0_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f1_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f2_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f3_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f4_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f5_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f6_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f7_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f8_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&facet.field=f9_ws&rows=1&wt=xml";
>
>
>
> 0
> 21
>
> true
> id
> true
> id:*
> -1
> 1000
>
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f0_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f1_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f2_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f3_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f4_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f5_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f6_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f7_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f8_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
> f9_ws
>
> xml
> 1
>
>
>
>
> 0.0
>
>
>
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 25
> 25
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 33
> 17
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 37
> 13
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 40
> 10
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 41
> 9
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 42
> 8
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 43
> 7
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 44
> 6
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
> 45
> 5
>
>
>
>
>
>
> {c
[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 2045 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/2045/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings Error Message: some thread(s) failed Stack Trace: java.lang.RuntimeException: some thread(s) failed at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:535) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:437) at org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK.testRandomHugeStrings(TestICUTokenizerCJK.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 6276 lines...] [junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerCJK [junit4] 2> TEST FAIL: useCharFilter=false text='dRCgl \ufe5c\ufe57\ufe59\ufe64 p rw glpnydoimb \uabd4\uabe7\uabe0\uabf8\uabf2\uabec\uabc6\uabd0 z < qrRCGb nmhegacernj kdbpkj \ue4f00);\u0614\u0014 \u4dca\u4ded\u4dc3\u4de6\u4df1\u4df9\u4dfc
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_65) - Build # 4225 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4225/ Java: 32bit/jdk1.7.0_65 -server -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([84E68F1F4902F7E1]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([84E68F1F4902F7E1]:0) Build Log: [...truncated 11205 lines...] [junit4] Suite: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest [junit4] 2> Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\temp\solr.cloud.ChaosMonkeySafeLeaderTest-84E68F1F4902F7E1-001\init-core-data-001 [junit4] 2> 2538648 T6719 oas.SolrTestCaseJ4.buildSSLConfig Randomized ssl (true) and clientAuth (true) [junit4] 2> 2538648 T6719 oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext system property: / [junit4] 2> 2538654 T6719 oas.SolrTestCaseJ4.setUp ###Starting testDistribSearch [junit4] 2> 2538657 T6719 oasc.ZkTestServer.run STARTING ZK TEST SERVER [junit4] 1> client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 2538660 T6720 oasc.ZkTestServer$ZKServerMain.runFromConfig Starting server [junit4] 2> 2538749 T6719 oasc.ZkTestServer.run start zk server on port:53339 [junit4] 2> 2538750 T6719 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 2538756 T6726 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@1b7bd1d name:ZooKeeperConnection Watcher:127.0.0.1:53339 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2538756 T6719 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 2538756 T6719 oascc.SolrZkClient.makePath makePath: /solr [junit4] 2> 2538762 T6721 oazs.NIOServerCnxn.doIO WARN caught end of stream exception EndOfStreamException: Unable to read additional data from client sessionid 0x14796d6c87b, likely client has closed socket [junit4] 2>at org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228) [junit4] 2>at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208) [junit4] 2>at java.lang.Thread.run(Thread.java:745) [junit4] 2> [junit4] 2> 2538764 T6719 oascc.ConnectionManager.waitForConnected Waiting for client to connect to ZooKeeper [junit4] 2> 2538767 T6728 oascc.ConnectionManager.process Watcher org.apache.solr.common.cloud.ConnectionManager@180a49a name:ZooKeeperConnection Watcher:127.0.0.1:53339/solr got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 2538767 T6719 oascc.ConnectionManager.waitForConnected Client is connected to ZooKeeper [junit4] 2> 2538767 T6719 oascc.SolrZkClient.makePath makePath: /collections/collection1 [junit4] 2> 2538772 T6719 oascc.SolrZkClient.makePath makePath: /collections/collection1/shards [junit4] 2> 2538776 T6719 oascc.SolrZkClient.makePath makePath: /collections/control_collection [junit4] 2> 2538780 T6719 oascc.SolrZkClient.makePath makePath: /collections/control_collection/shards [junit4] 2> 2538784 T6719 oasc.AbstractZkTestCase.putConfig put C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 2538784 T6719 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.xml [junit4] 2> 2538792 T6719 oasc.AbstractZkTestCase.putConfig put C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml to /configs/conf1/schema.xml [junit4] 2> 2538793 T6719 oascc.SolrZkClient.makePath makePath: /configs/conf1/schema.xml [junit4] 2> 2538797 T6719 oasc.AbstractZkTestCase.putConfig put C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 2538797 T6719 oascc.SolrZkClient.makePath makePath: /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 2538802 T6719 oasc.AbstractZkTestCase.putConfig put C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 2538804 T6719 oascc.SolrZkClient.makePath makePath: /configs/conf1/stopwords.txt [junit4]
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1177: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1177/ 5 tests failed. REGRESSION: org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.testChildDoctransformer Error Message: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR: 500 Problem accessing /solr/collection1/select. Reason: Server Error Powered by Jetty:// Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. Error 500 Server Error HTTP ERROR: 500 Problem accessing /solr/collection1/select. Reason: Server Error Powered by Jetty:// at __randomizedtesting.SeedInfo.seed([A75E228EB47ED8A4:D4843D143866AFA2]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:513) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.client.solrj.SolrExampleTests.testChildDoctransformer(SolrExampleTests.java:1373) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner
[jira] [Updated] (LUCENE-4396) BooleanScorer should sometimes be used for MUST clauses
[
https://issues.apache.org/jira/browse/LUCENE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Da Huang updated LUCENE-4396:
-
Attachment: LUCENE-4396.patch
This is a patch based on git mirror commit
67d17eb81b754fa242bb91e1b91070fd8b38ecd9
In this patch, I go further based on the last patch.
Firstly, I move all scorer choosing logics to .bulkScorer(), so that there's no
need to wrap scorer in .bulkScorer().
Secondly, I have tried to use BooleanScorer for some cases with MUST.
However, it seems that there's something wrong with my test on BS before.
The perf. of BS can just beat DAAT on 2 cases, and BS perfs worse than other
explored scorers on these 2 cases.
Ther perf of BQ(the merged scorer) and BS is showed as follows.
{code}
BQ
TaskQPS baseline StdDevQPS my_version StdDev
Pct diff
HighAndTonsLowNot5.01 (3.5%)4.29 (2.7%)
-14.3% ( -19% - -8%)
HighAndSomeLowNot 15.33 (5.1%) 13.71 (5.4%)
-10.6% ( -20% -0%)
LowAndSomeLowOr 240.72 (2.5%) 217.73 (2.5%)
-9.6% ( -14% - -4%)
LowAndSomeLowNot 269.51 (1.4%) 244.76 (2.3%)
-9.2% ( -12% - -5%)
HighAndTonsLowOr5.19 (5.3%)4.94 (2.0%)
-4.8% ( -11% -2%)
HighAndSomeHighNot1.60 (2.0%)1.57 (2.6%)
-1.9% ( -6% -2%)
HighAndSomeLowOr6.65 (11.5%)6.77 (4.1%)
1.8% ( -12% - 19%)
PKLookup 96.93 (2.3%) 99.72 (4.1%)
2.9% ( -3% -9%)
LowAndSomeHighNot 59.45 (1.5%) 61.63 (2.4%)
3.7% ( 0% -7%)
LowAndSomeHighOr 40.78 (2.0%) 42.75 (3.0%)
4.8% ( 0% - 10%)
HighAndSomeHighOr2.11 (2.8%)2.44 (3.0%)
16.1% ( 10% - 22%)
LowAndTonsLowNot 17.45 (1.3%) 20.88 (2.5%)
19.6% ( 15% - 23%)
LowAndTonsHighOr2.76 (1.6%)3.34 (3.1%)
21.0% ( 16% - 26%)
LowAndTonsLowOr 15.36 (1.2%) 19.83 (3.1%)
29.2% ( 24% - 33%)
HighAndTonsHighOr0.08 (0.7%)0.21 (5.1%)
159.8% ( 152% - 166%)
LowAndTonsHighNot1.69 (1.5%)5.14 (5.9%)
204.0% ( 193% - 214%)
HighAndTonsHighNot0.09 (0.7%)0.41 (11.0%)
359.9% ( 345% - 374%)
BooleanScorer
TaskQPS baseline StdDevQPS my_version StdDev
Pct diff
LowAndSomeHighOr 51.38 (1.7%)1.47 (0.4%)
-97.1% ( -97% - -96%)
LowAndTonsHighOr2.79 (1.5%)0.10 (0.5%)
-96.5% ( -97% - -95%)
LowAndTonsHighNot1.71 (2.0%)0.17 (0.7%)
-90.3% ( -91% - -89%)
LowAndSomeHighNot 32.69 (2.2%)3.18 (0.6%)
-90.3% ( -91% - -89%)
LowAndSomeLowOr 258.50 (1.7%) 91.84 (1.6%)
-64.5% ( -66% - -62%)
HighAndSomeLowOr 12.66 (9.1%)5.89 (2.3%)
-53.5% ( -59% - -46%)
LowAndSomeLowNot 252.33 (2.1%) 124.57 (1.1%)
-50.6% ( -52% - -48%)
HighAndTonsLowOr3.13 (7.5%)1.57 (2.3%)
-49.7% ( -55% - -43%)
LowAndTonsLowOr 14.17 (0.8%)7.32 (2.6%)
-48.4% ( -51% - -45%)
HighAndSomeLowNot 18.01 (5.6%) 10.03 (2.8%)
-44.3% ( -49% - -37%)
LowAndTonsLowNot 17.17 (1.1%) 11.33 (1.5%)
-34.0% ( -36% - -31%)
HighAndTonsLowNot6.29 (2.5%)4.73 (2.4%)
-24.9% ( -29% - -20%)
HighAndSomeHighOr1.66 (3.1%)1.28 (7.5%)
-22.7% ( -32% - -12%)
HighAndSomeHighNot2.11 (1.4%)1.83 (3.4%)
-13.5% ( -18% - -8%)
PKLookup 96.92 (4.0%) 94.94 (2.5%)
-2.0% ( -8% -4%)
HighAndTonsHighOr0.07 (0.5%)0.09 (18.2%)
38.3% ( 19% - 57%)
HighAndTonsHighNot0.04 (1.9%)0.16 (24.4%)
263.0% ( 232% - 294%)
{code}
By the perf. table of BQ, it looks that BQ perfs low on the first 4 cases.
However, when I run these cases one by one, they're just worse than the trunk
within 2%.
I'm not sure what makes this happen?
> BooleanScorer should sometimes be used for MUST clauses
> ---
>
> Key: LUCENE-4396
> URL: https://issues.apache.org/jira/browse/LUCENE-4396
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Michael McCandless
> Attachments: And.tasks, AndOr.tasks, AndOr.tasks, LUCENE-4396.patch,
>
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1711 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1711/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.schema.TestCloudSchemaless.testDistribSearch Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:56561/hshk/pc/collection1 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:56561/hshk/pc/collection1 at __randomizedtesting.SeedInfo.seed([140AFFDEFFA5A911:95EC71C688FAC92D]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:559) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:210) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:206) at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:68) at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:54) at org.apache.solr.schema.TestCloudSchemaless.doTest(TestCloudSchemaless.java:140) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:867) at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[JENKINS] Lucene-Solr-NightlyTests-4.x - Build # 589 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-4.x/589/ 1 tests failed. FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.testDistribSearch Error Message: We have a failed SPLITSHARD task Stack Trace: java.lang.AssertionError: We have a failed SPLITSHARD task at __randomizedtesting.SeedInfo.seed([1498AB7BD9E81E86:957E2563AEB77EBA]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.MultiThreadedOCPTest.testTaskExclusivity(MultiThreadedOCPTest.java:125) at org.apache.solr.cloud.MultiThreadedOCPTest.doTest(MultiThreadedOCPTest.java:71) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:867) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomize
Re: Lucene versioning logic
+1, this sounds like a great solution. It simplifies the APIs (no more required Version to Analyzer), it consolidates the version logic to a "single source", dot releases are first class. Mike McCandless http://blog.mikemccandless.com On Fri, Aug 1, 2014 at 7:47 PM, Ryan Ernst wrote: > There has been a lot of heated discussion recently about version > tracking in Lucene [1] [2]. I wanted to have a fresh discussion > outside of jira to give a full description of the current state of > things, the problems I have heard, and a proposed solution. > > CURRENT > > We have 2 pieces of code that handle “versioning.” The first is > Constants.LUCENE_MAIN_VERSION, which is written to the SegmentsInfo > for each segment. This is a string version which is used to detect > when the current version of lucene is newer than the version that > wrote the segment (and how/if an upgrade to to a newer codec should be > done). There is some complication with the “display” version and > non-display version, which are distinguished by whether the version of > lucene was an official release, or an alpha/beta version (which was > added specifically for the 4.0.0 release ramp up). This string > version also has its own parsing and comparison methods. > > The second piece of versioning code is in Version.java, which is an > enum used by analyzers to maintain backwards compatible behavior given > a specific version of lucene. The enum only contains values for dot > releases of lucene, not bug fixes (which was what spurred the recent > discussions over version). Analyzers’ constructors take a required > Version parameter, which is only actually used by the few analyzers > that have changed behavior recently. Version.java contains a separate > version parsing and comparison methods. > > > CONCERNS > > * Having 2 different pieces of code that do very similar things is > confusing for development. Very few developers appear to really > understand the current system (especially when trying to understand > the alpha/beta setup). > > * Users are generally confused by the Version passed to analyzers: I > know I was when I first started working with Lucene, and > Version.CURRENT_VERSION was deprecated because users used that without > understanding the implications. > > * Most analyzers currently have dead code constructors, since they > never make use of Version. There are also a lot of classes used by > analyzers which contain similar dead code. > > * Backwards compatibility needs to be handled in some fashion, to > ensure users have a path to upgrade from one version of lucene to > another, without requiring immediate re-indexing. > > > PROPOSAL > > I propose the following: > > * Consolidate all version related enumeration, including reading and > writing string versions, into Version.java. Have a static method that > returns the current lucene version (replacing > Constants.LUCENE_MAIN_VERSION). > > * Make bug fix releases first class in the enumeration, so that they > can be distinguished for any compatibility issues that come up. > > * Remove all snapshot/alpha/beta versioning logic. Alpha/beta was > really only necessary for 4.0 because of the extreme changes that were > being made. The system is much more stable now, and 5.0 should not > require preview releases, IMO. I don’t think snapshots should be a > concern because any user building an index from an unreleased build > (which they built themselves) is just asking for trouble. They do so > at their own risk (of figuring out how to upgrade their indexes if > they are not trash-able). Backwards compatibility can be handled by > adding the alpha/beta/final versions of 4.0 to the enum (and special > parsing logic for this). If lucene changes so much that we need > alpha/beta type discrimination in the future, we can revisit the > system if simply having extra versions in the enum won't work. > > * Analyzers constructors should have Version removed, and a setter > should be added which allows production users to set the version used. > This way any analyzers can still use version if it is set to something > other than current (which would be the default), but users simply > prototyping do not need to worry about it. > > * Classes that analyzers use, which take Version, should have Version > removed, and the analyzers should choose which settings/variants of > those classes to use based on the version they have set. In other > words, all version variant logic should be contained within the > analyzers. For example, Lucene47WordDelimiterFilter, or > StandardAnalyzer can take the unicode version. > Factories could still take Version (e.g. TokenizerFactory, > TokenFilterFactory, etc) to produce the correct component (so nothing > will change for solr in this regard). > > I’m sure not everyone will be happy with what I have proposed, but I’m > hoping we can work out a solution together, and then implement in a > team-like fashion, the way I have seen the community work i
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_65) - Build # 10823 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/10823/ Java: 64bit/jdk1.7.0_65 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 45246 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:467: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:63: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:212: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:548: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/common-build.xml:2367: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/docs/changes/jiraVersionList.json Total time: 107 minutes 37 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0_65 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1746 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1746/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 44935 lines...] BUILD FAILED /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:467: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/build.xml:63: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:212: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build.xml:548: The following error occurred while executing this line: /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2367: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/docs/changes/jiraVersionList.json Total time: 206 minutes 43 seconds Build step 'Invoke Ant' marked build as failure [description-setter] Description set: Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-Artifacts-trunk - Build # 2477 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2477/ No tests ran. Build Log: [...truncated 17135 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/build.xml:434: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/build.xml:332: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/solr/test-framework/build.xml:94: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:511: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:508: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/build.xml:548: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/common-build.xml:2367: Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to /usr/home/hudson/hudson-slave/workspace/Solr-Artifacts-trunk/lucene/build/docs/changes/jiraVersionList.json Total time: 6 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Sending artifact delta relative to Solr-Artifacts-trunk #2476 Archived 3 artifacts Archive block size is 32768 Received 0 blocks and 34858850 bytes Compression is 0.0% Took 36 sec Publishing Javadoc Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #668: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/668/ 3 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandlerBackup.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=27119, name=Thread-7867, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=27119, name=Thread-7867, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) at __randomizedtesting.SeedInfo.seed([1408C4EEF7527A5E]:0) FAILED: org.apache.solr.handler.TestReplicationHandlerBackup.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: There are still zombie threads that couldn't be terminated: 1) Thread[id=27119, name=Thread-7867, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.java:180) at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:652) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:314) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=27119, name=Thread-7867, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at sun.net.NetworkClient.doConnect(NetworkClient.j
