[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly
[
https://issues.apache.org/jira/browse/SOLR-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051464#comment-16051464
]
ASF subversion and git services commented on SOLR-9565:
---
Commit e1d4ec798732b30a3bd87f72beb98465a8735376 in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e1d4ec7 ]
SOLR-9565: The name of TemplateUpdateRequestProcessorFactory' is changed to
'template' from 'Template' and the
name of 'AtomicUpdateProcessorFactory' is changed to 'atomic' from 'Atomic'
> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
> Attachments: SOLR-9565.patch
>
>
> Now that we can 'construct' the URP chains through request parameters, we
> should make all the URPs available automatically. The next challenge is to
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just
> configuration parameters e.g:
> {{processor=HTMLStripField&HTMLStripField.fieldName=}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+173) - Build # 6652 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6652/ Java: 32bit/jdk-9-ea+173 -client -XX:+UseParallelGC 2 tests failed. FAILED: org.apache.solr.handler.admin.MBeansHandlerTest.testDiff Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([ACE4830B253E0C30:69F2479035883450]:0) at org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240) at org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219) at org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187) at org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2487) at org.apache.solr.util.TestHarness.query(TestHarness.java:337) at org.apache.solr.util.TestHarness.query(TestHarness.java:319) at org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedte
Re: Junit 5?
Never mind ;) On Thu, Jun 15, 2017 at 6:49 PM, Ryan Ernst wrote: > Junit 5 hasn't been released yet, they are on milestone 4. We did add some > junit 5 behavior to LuceneTestCase last year though: > https://issues.apache.org/jira/browse/LUCENE-7009 > > On Thu, Jun 15, 2017 at 2:45 PM Erick Erickson > wrote: >> >> I may regret this, but is there any interest in moving to Junit 5? It >> requires Java 8, but so do Lucene and Solr. >> >> I have _not_ really looked at whether there are nifty new features >> that would make it worth the effort. I did notice, though, that it's >> supposed to run junit3 and junit4 tests so maybe it'd be fairly >> painless. >> >> Erick >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051365#comment-16051365
]
ASF subversion and git services commented on SOLR-10433:
Commit f6f6f113209a5766c837665a818a524d0613757e in lucene-solr's branch
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f6f6f11 ]
SOLR-10433: CollectionAdmin requests in SolrJ to support V2 calls
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7
[
https://issues.apache.org/jira/browse/SOLR-10574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051359#comment-16051359
]
Ishan Chattopadhyaya commented on SOLR-10574:
-
Thanks David, I'll add the warning part in the patch.
I've added SOLR-10902 for enabling/disabling data driven as a CREATE parameter.
Added SOLR-10903 for the edismax discussions (FYI [~yo...@apache.org],
[~arafalov]).
> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch,
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when
> collections are created using the bin/solr script and no configset is
> specified.
> However, that may not be the best choice. We need to decide which is the best
> choice, out of the box, considering many users might create collections
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property":
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10887) Add .xml extension to managed-schema
[
https://issues.apache.org/jira/browse/SOLR-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-10887:
Issue Type: Sub-task (was: Task)
Parent: SOLR-10574
> Add .xml extension to managed-schema
>
>
> Key: SOLR-10887
> URL: https://issues.apache.org/jira/browse/SOLR-10887
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
>
> Discussions here SOLR-10574.
> There is consensus to renaming managed-schema back to managed-schema.xml.
> Requires backcompat handling as mentioned in Yonik's comment:
> {code}
> there is back compat to consider. I'd also prefer that if it get changed, we
> first look for "managed-schema.xml", then "managed-schema", and then
> "schema.xml" to preserve back compat.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10903) Default configuration should use edismax for searching on all fields
Ishan Chattopadhyaya created SOLR-10903: --- Summary: Default configuration should use edismax for searching on all fields Key: SOLR-10903 URL: https://issues.apache.org/jira/browse/SOLR-10903 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya An offshoot from discussions at SOLR-10574. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10902) CREATE collection command to have parameter for turning on/off data driven nature
Ishan Chattopadhyaya created SOLR-10902: --- Summary: CREATE collection command to have parameter for turning on/off data driven nature Key: SOLR-10902 URL: https://issues.apache.org/jira/browse/SOLR-10902 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Ishan Chattopadhyaya Once SOLR-10574 is implemented, it would be good to have a CREATE collection parameter to turn on/off the data-driven nature. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7872) TopDocs.totalHits should be a long
[ https://issues.apache.org/jira/browse/LUCENE-7872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated LUCENE-7872: - Attachment: LUCENE-7872.patch updated patch with solr tweaks. the end user/solrj APIs already used "long" for numFound, so this is mainly just cleaning up some poor asumptions/casting (mostly in Spellchecker tests) Would be nice if someone else could give the solr changes a sanity check? > TopDocs.totalHits should be a long > -- > > Key: LUCENE-7872 > URL: https://issues.apache.org/jira/browse/LUCENE-7872 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7872.patch, LUCENE-7872.patch > > > Even though a single index cannot have more than 2B documents, TopDocs.merge > might merge TopDocs instances that have more than 2B documents in total. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1371 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1371/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
3 tests failed.
FAILED: org.apache.solr.core.TestDynamicLoading.testDynamicLoading
Error Message:
Could not get expected value
'org.apache.solr.core.BlobStoreTestRequestHandler' for path
'overlay/requestHandler/\/test1/class' full output: { "responseHeader":{
"status":0, "QTime":0}, "overlay":{ "znodeVersion":0,
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,
from server: null
Stack Trace:
java.lang.AssertionError: Could not get expected value
'org.apache.solr.core.BlobStoreTestRequestHandler' for path
'overlay/requestHandler/\/test1/class' full output: {
"responseHeader":{
"status":0,
"QTime":0},
"overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1, from server: null
at
__randomizedtesting.SeedInfo.seed([C70A6F89CD9BB3FC:1F4742DE3A46165C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
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(St
[jira] [Commented] (SOLR-4646) [edismax] let lowercaseOperators default to "false"
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051336#comment-16051336
]
David Smiley commented on SOLR-4646:
+1 patch looks good.
> [edismax] let lowercaseOperators default to "false"
> ---
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-4646.patch, SOLR-4646.patch
>
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10882) Restructure and Cleanup Stream Evaluators
[ https://issues.apache.org/jira/browse/SOLR-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Gove updated SOLR-10882: --- Attachment: SOLR-10882.patch Changes so far. > Restructure and Cleanup Stream Evaluators > - > > Key: SOLR-10882 > URL: https://issues.apache.org/jira/browse/SOLR-10882 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Dennis Gove > Attachments: SOLR-10882.patch > > > There are a suite of new Stream Evaluators that I'd like to cleanup and > restructure prior to the cutting of v7. This ticket is to track that progress. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Junit 5?
Junit 5 hasn't been released yet, they are on milestone 4. We did add some junit 5 behavior to LuceneTestCase last year though: https://issues.apache.org/jira/browse/LUCENE-7009 On Thu, Jun 15, 2017 at 2:45 PM Erick Erickson wrote: > I may regret this, but is there any interest in moving to Junit 5? It > requires Java 8, but so do Lucene and Solr. > > I have _not_ really looked at whether there are nifty new features > that would make it worth the effort. I did notice, though, that it's > supposed to run junit3 and junit4 tests so maybe it'd be fairly > painless. > > Erick > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4077 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4077/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([557FA98F4214A9FC:371257CE8D9AC9C2]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.handler.admin.MetricsHandlerTest.testPropertyFilter(MetricsHandlerTest.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11485 lines...] [junit4] Suite: org.apache.solr.handler.admin.MetricsHandlerTest [junit4] 2> Creating dataDir: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-cor
[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables
[
https://issues.apache.org/jira/browse/SOLR-10892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051266#comment-16051266
]
Cassandra Targett commented on SOLR-10892:
--
I've committed the first part of this effort, which replaces "easy" tables.
There are several more pages with either lots of tables ({{collections.adoc}}
is an example) or an entire page structure that is centered around the table
(such as {{faceting.adoc}}), which will be taken care of in the next phase.
> Ref Guide: Move parameters out of tables
>
>
> Key: SOLR-10892
> URL: https://issues.apache.org/jira/browse/SOLR-10892
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: master (7.0)
>
>
> We've overused a bit the concept of using tables to explain various config
> parameters. We have some tables that are massive and try to cram a ton of
> complex information into a row (see function-queries.adoc), while other
> tables are only 1 or 2 rows. It's not impossible, but it's also difficult to
> link directly to parameters when they are in a table
> AsciiDoc format now allows us to use "description lists" or "definition
> lists" which in many cases might be better. This issue would change many of
> the current tables to definition lists. However, some of them may remain,
> depending on how they work within the content.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables
[ https://issues.apache.org/jira/browse/SOLR-10892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051259#comment-16051259 ] ASF subversion and git services commented on SOLR-10892: Commit a7245d5e785fb3e60cc37b8df9d1c78a1a0699e7 in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a7245d5 ] SOLR-10892: fix trailing white space > Ref Guide: Move parameters out of tables > > > Key: SOLR-10892 > URL: https://issues.apache.org/jira/browse/SOLR-10892 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: master (7.0) > > > We've overused a bit the concept of using tables to explain various config > parameters. We have some tables that are massive and try to cram a ton of > complex information into a row (see function-queries.adoc), while other > tables are only 1 or 2 rows. It's not impossible, but it's also difficult to > link directly to parameters when they are in a table > AsciiDoc format now allows us to use "description lists" or "definition > lists" which in many cases might be better. This issue would change many of > the current tables to definition lists. However, some of them may remain, > depending on how they work within the content. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables
[ https://issues.apache.org/jira/browse/SOLR-10892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051258#comment-16051258 ] ASF subversion and git services commented on SOLR-10892: Commit bf26608f6d2b8c1281975dfb25c3cd2110ea5260 in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bf26608 ] SOLR-10892: Change easy tables to description lists > Ref Guide: Move parameters out of tables > > > Key: SOLR-10892 > URL: https://issues.apache.org/jira/browse/SOLR-10892 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett > Fix For: master (7.0) > > > We've overused a bit the concept of using tables to explain various config > parameters. We have some tables that are massive and try to cram a ton of > complex information into a row (see function-queries.adoc), while other > tables are only 1 or 2 rows. It's not impossible, but it's also difficult to > link directly to parameters when they are in a table > AsciiDoc format now allows us to use "description lists" or "definition > lists" which in many cases might be better. This issue would change many of > the current tables to definition lists. However, some of them may remain, > depending on how they work within the content. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-6.x-Windows (32bit/jdk-9-ea+173) - Build # 973 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/973/ Java: 32bit/jdk-9-ea+173 -client -XX:+UseSerialGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.OutputWriterTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001 at __randomizedtesting.SeedInfo.seed([5975AA9EB4557E0D]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 12450 lines...] [junit4] Suite: org.apache.solr.OutputWriterTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J0\temp\solr.OutputWriterTest_5975AA9EB4557E0D-001\init-core-data-001 [junit4] 2> 1611066 WARN (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1 [junit4] 2> 1611066 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.SolrTestCaseJ4 Using TrieFields [junit4] 2> 1611068 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, clientAuth=0.0/0.0) [junit4] 2> 1611069 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 1611069 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: [/C:/Users/jenkins/workspace/Lucene-Solr-6.x-Windows/solr/core/src/test-files/solr/collection1/lib, /C:/Users/jenkins/workspace/Lucene-Solr-6.x-Windows/solr/core/src/test-files/solr/collection1/lib/classes] [junit4] 2> 1611109 WARN (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.c.Config Beginning with Solr 5.5, is deprecated, use instead. [junit4] 2> 1611109 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.c.SolrConfig Using Lucene MatchVersion: 6.7.0 [junit4] 2> 168 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.s.IndexSchema [null] Schema name=test [junit4] 2> 1611120 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker) [] o.a.s.s.IndexSchema Loaded schema test/1.0 with uniqueid field id [junit4] 2> 1611124 INFO (SUITE-OutputWriterTest-seed#[5975AA9EB4557E0D]-worker
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19877 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19877/ Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.UnloadDistributedZkTest.test Error Message: Captured an uncaught exception in thread: Thread[id=8382, name=testExecutor-4246-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=8382, name=testExecutor-4246-thread-1, state=RUNNABLE, group=TGRP-UnloadDistributedZkTest] at __randomizedtesting.SeedInfo.seed([2384D03A4E629749:ABD0EFE0E09EFAB1]:0) Caused by: java.lang.RuntimeException: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:43783/_/uk at __randomizedtesting.SeedInfo.seed([2384D03A4E629749]:0) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:412) at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:43783/_/uk at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:603) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:219) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219) at org.apache.solr.cloud.UnloadDistributedZkTest.lambda$testUnloadLotsOfCores$0(UnloadDistributedZkTest.java:410) ... 4 more Caused by: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) at java.net.SocketInputStream.read(SocketInputStream.java:171) at java.net.SocketInputStream.read(SocketInputStream.java:141) at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:495) ... 8 more Build Log: [...truncated 11928 lines...] [junit4] Suite: org.apache.solr.cloud.UnloadDistributedZkTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.UnloadDistributedZkTest_2384D03A4E629749-001/init-core-data-001 [junit4] 2> 773974 WARN (SUITE-UnloadDistributedZkTest-seed#[2384D03A4E629749]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=46 numCloses=46 [junit4] 2> 773974 INFO (SUITE-UnloadDistributedZkTest-seed#[2384D03A4E629749]-worker) [] o.a.s.SolrTestCaseJ4 Using TrieFields [junit4] 2> 773975 INFO (SUITE-UnloadDistributedZkTest-seed#[2384D03A4E629749]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.Solr
[jira] [Updated] (SOLR-6671) Introduce a solr.data.home as root dir for all data
[
https://issues.apache.org/jira/browse/SOLR-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-6671:
--
Fix Version/s: (was: 6.2)
> Introduce a solr.data.home as root dir for all data
> ---
>
> Key: SOLR-6671
> URL: https://issues.apache.org/jira/browse/SOLR-6671
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
>Affects Versions: 4.10.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch,
> SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch
>
>
> Many users prefer to deploy code, config and data on separate disk locations,
> so the default of placing the indexes under
> {{$\{solr.solr.home\}/$\{solr.core.name\}/data}} is not always wanted.
> In a multi-core/collection system, there is not much help in the
> {{solr.data.dir}} option, as it would set the {{dataDir}} to the same folder
> for all collections. One workaround, if you don't want to hardcode paths in
> your {{solrconfig.xml}}, is to specify the {{dataDir}} property in each
> {{solr.properties}} file.
> A more elegant solution would be to introduce a new Java-option
> {{solr.data.home}} which would be to data the same as {{solr.solr.home}} is
> for config. If set, all collections would default their {{dataDir}} as
> {{$\{solr.data.home\)/$\{solr.core.name\}/data}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6671) Introduce a solr.data.home as root dir for all data
[
https://issues.apache.org/jira/browse/SOLR-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-6671:
--
Attachment: SOLR-6671.patch
New patch, the previous did not include all bin/solr changes.
Not tackling {{install_solr_service.sh}} in this issue, will create a followup
issue for it.
Applies to current master
> Introduce a solr.data.home as root dir for all data
> ---
>
> Key: SOLR-6671
> URL: https://issues.apache.org/jira/browse/SOLR-6671
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
>Affects Versions: 4.10.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch,
> SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch, SOLR-6671.patch
>
>
> Many users prefer to deploy code, config and data on separate disk locations,
> so the default of placing the indexes under
> {{$\{solr.solr.home\}/$\{solr.core.name\}/data}} is not always wanted.
> In a multi-core/collection system, there is not much help in the
> {{solr.data.dir}} option, as it would set the {{dataDir}} to the same folder
> for all collections. One workaround, if you don't want to hardcode paths in
> your {{solrconfig.xml}}, is to specify the {{dataDir}} property in each
> {{solr.properties}} file.
> A more elegant solution would be to introduce a new Java-option
> {{solr.data.home}} which would be to data the same as {{solr.solr.home}} is
> for config. If set, all collections would default their {{dataDir}} as
> {{$\{solr.data.home\)/$\{solr.core.name\}/data}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10901) Map SolrJ config api/schema API to V2
[ https://issues.apache.org/jira/browse/SOLR-10901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-10901: -- Summary: Map SolrJ config api/schema API to V2 (was: Map onfig api/schema API to V2) > Map SolrJ config api/schema API to V2 > - > > Key: SOLR-10901 > URL: https://issues.apache.org/jira/browse/SOLR-10901 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10900) Map SolrJ security API to V2
[ https://issues.apache.org/jira/browse/SOLR-10900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-10900: -- Summary: Map SolrJ security API to V2 (was: Map security API to V2) > Map SolrJ security API to V2 > > > Key: SOLR-10900 > URL: https://issues.apache.org/jira/browse/SOLR-10900 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: v2 API >Reporter: Noble Paul > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10900) Map security API to V2
Noble Paul created SOLR-10900: - Summary: Map security API to V2 Key: SOLR-10900 URL: https://issues.apache.org/jira/browse/SOLR-10900 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10901) Map onfig api/schema API to V2
Noble Paul created SOLR-10901: - Summary: Map onfig api/schema API to V2 Key: SOLR-10901 URL: https://issues.apache.org/jira/browse/SOLR-10901 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10899) Map core admin SolJ APIs to V2
Noble Paul created SOLR-10899: - Summary: Map core admin SolJ APIs to V2 Key: SOLR-10899 URL: https://issues.apache.org/jira/browse/SOLR-10899 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield
[ https://issues.apache.org/jira/browse/SOLR-10503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-10503: -- Attachment: SOLR-10503.patch Patch deprecating CurrencyField in favor of a new points-based CurrencyPointField. I had to pull some top-level classes out of CurrencyField (CurrencyValue and FileExchangeRateProvider) in order to share them between the new and old classes. Similarly, I moved CurrencyField.getCurrency() to CurrencyValue, so that the two classes didn't have to refer to CurrencyField. I fixed up the ref guide, and changed all example schemas to use only the new CurrencyPointField. Precommit and all Solr tests pass. I think it's ready to go. > CurrencyField should be changed from TrieLongField to LongPointField for > underlying raw-polyfield > - > > Key: SOLR-10503 > URL: https://issues.apache.org/jira/browse/SOLR-10503 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man > Attachments: SOLR-10503.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10832) Using "indexed" PointField for _version_ breaks VersionInfo.getMaxVersionFromIndex
[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-10832.
-
Resolution: Fixed
Fix Version/s: 6.7
master (7.0)
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> --
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10832.patch, SOLR-10832.patch, SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10832) Using "indexed" PointField for _version_ breaks VersionInfo.getMaxVersionFromIndex
[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051191#comment-16051191
]
ASF subversion and git services commented on SOLR-10832:
Commit 274971c3e331b68e5f7ea2669024215b8017ff7a in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=274971c ]
SOLR-10832: Fixed VersionInfo.getMaxVersionFromIndex when using PointsField
with indexed="true"
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> --
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10832.patch, SOLR-10832.patch, SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10832) Using "indexed" PointField for _version_ breaks VersionInfo.getMaxVersionFromIndex
[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051190#comment-16051190
]
ASF subversion and git services commented on SOLR-10832:
Commit 45af5576a5cbf2e20b9576a200b852042ad76ec1 in lucene-solr's branch
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45af557 ]
SOLR-10832: Fixed VersionInfo.getMaxVersionFromIndex when using PointsField
with indexed="true"
(cherry picked from commit 274971c3e331b68e5f7ea2669024215b8017ff7a)
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> --
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10832.patch, SOLR-10832.patch, SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6651 - Still unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6651/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseG1GC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.handler.component.InfixSuggestersTest
Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001\init-core-data-001:
java.nio.file.AccessDeniedException:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001\init-core-data-001
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001:
java.nio.file.DirectoryNotEmptyException:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001
Stack Trace:
java.io.IOException: Could not remove the following files (in the order of
attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001\init-core-data-001:
java.nio.file.AccessDeniedException:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001\init-core-data-001
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001:
java.nio.file.DirectoryNotEmptyException:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.handler.component.InfixSuggestersTest_9AE2750FDAC2EC29-001
at __randomizedtesting.SeedInfo.seed([9AE2750FDAC2EC29]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
FAILED: org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi
Error Message:
Error from server at http://127.0.0.1:57086/solr: Expected mime type
application/octet-stream but got text/html.Error
400HTTP ERROR: 400 Problem accessing
/solr/v2/c. Reason:
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
Illegal char at index 53:
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core estJ1
empsolr.handler.V2ApiIntegrationTest_9AE2750FDAC2EC29-001
empDir-002,code=400} http://eclipse.org/jetty";>Powered
by Jetty:// 9.3.14.v20161028
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at http://127.0.0.1:57086/solr: Expected mime type
application/octet-stream but got text/html.
Error 400
HTTP ERROR: 400
Problem accessing /solr/v2/c. Reason:
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
Illegal char at index 53:
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core estJ1
empsolr.handler.V2ApiIntegrationTest_9AE2750FDAC2EC29-001
empDir-002,code=400}
http://eclipse.org/jetty";>Powered by Jetty://
9.3.14.v20161028
at
__randomizedtesting.SeedInfo.seed([9AE2750FDAC2EC29:467C928E62DB8897]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:219)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClie
[jira] [Commented] (LUCENE-7872) TopDocs.totalHits should be a long
[ https://issues.apache.org/jira/browse/LUCENE-7872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051164#comment-16051164 ] Hoss Man commented on LUCENE-7872: -- Presumably you're targeting this for 7.0 since it's a public API change? I'm +1 to the idea ... but I feel like if we're going to make this change to TopDocs we should bite the bullet and make the equivalent change to Solr's DocList API (rather then coerce with Math.toIntExact). I'll try to work on an updated patch tomorrow? > TopDocs.totalHits should be a long > -- > > Key: LUCENE-7872 > URL: https://issues.apache.org/jira/browse/LUCENE-7872 > Project: Lucene - Core > Issue Type: Bug >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-7872.patch > > > Even though a single index cannot have more than 2B documents, TopDocs.merge > might merge TopDocs instances that have more than 2B documents in total. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Junit 5?
I may regret this, but is there any interest in moving to Junit 5? It requires Java 8, but so do Lucene and Solr. I have _not_ really looked at whether there are nifty new features that would make it worth the effort. I did notice, though, that it's supposed to run junit3 and junit4 tests so maybe it'd be fairly painless. Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored
[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051100#comment-16051100
]
Hoss Man commented on SOLR-10864:
-
bq. Or do you have other plans?
I did not have any specific plans -- I'd kind of forgotten about needing to
hack around that on the jira/SOLR-10807 branch. Thanks for reminding me.
My 2 strawman suggestions would be:
# Any tests where it's a problem is a test where we should consider *not* using
randomized class name in the fieldType, and instead test the diff permutations
explicitly.
# in addition to the randomized classname sysvar used in schema files, we can
have a randomized boolean var(s) indicating if the choosen classes are points
based, and fields/fieldTypes where "trie w/fieldcache" vs "points w/docvalues"
matter can use that var in their {{docValues="$var"}} declaration.
In practice, we might want to mix both? Use #2 in general purpose test
schemas, and #1 in purpose build test schemas like what TestPoints or TestTrie
use?
Either way:
* i'm guessing at least 80% of test won't be affected at all
* we should have a solution that doesn't depend on wether we do SOLR-10808,
because even if that happens first, we're still going to want to be able to
have schemas where TrieFields have (effective/explicit) {{docValues="false"}}
to continue testing that we don't break FieldCache usage for those fieldTypes
in 7.x point releases
thoughts?
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored
> -
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> *
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the precisionStep
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of
[jira] [Updated] (SOLR-4646) [edismax] let lowercaseOperators default to "false"
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-4646:
--
Attachment: SOLR-4646.patch
New patch that makes the default depend on luceneMatchVersion. I.e. we'll
respect the old default if people bring over their configs without explicitly
bumping version.
> [edismax] let lowercaseOperators default to "false"
> ---
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-4646.patch, SOLR-4646.patch
>
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 1866 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/1866/ 1 tests failed. FAILED: org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest.test Error Message: Mismatch in counts between replicas Stack Trace: java.lang.AssertionError: Mismatch in counts between replicas at __randomizedtesting.SeedInfo.seed([D7D9D787996D02BF:5F8DE85D37916F47]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143) at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 11544 lines...] [junit4] Suite: org.apache.solr.cloud.hdfs.HdfsRecoveryZkTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/solr-core/test/J1/temp/solr.cloud.hdfs.HdfsRecoveryZkTest_D7D9D787996D02BF-001/init-core-data-001 [junit4] 2> 527270 WA
[jira] [Updated] (SOLR-10832) Using "indexed" PointField for _version_ breaks VersionInfo.getMaxVersionFromIndex
[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10832:
Attachment: SOLR-10832.patch
revised path using the FieldType.toObject abstraction for the versionField.
All tests and precommit pass on master.
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> --
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
> Attachments: SOLR-10832.patch, SOLR-10832.patch, SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10832) Using "indexed" PointField for _version_ breaks VersionInfo.getMaxVersionFromIndex
[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reassigned SOLR-10832:
---
Assignee: Hoss Man
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> --
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10832.patch, SOLR-10832.patch, SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed
Hoss Man created SOLR-10898: --- Summary: TestRandomRequestDistribution.testRequestTracking is terrible and should be removed Key: SOLR-10898 URL: https://issues.apache.org/jira/browse/SOLR-10898 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Hoss Man TestRandomRequestDistribution.testRequestTracking() is a badly written test that tries to assert that if 10 requests are sent to a shard has 2 replicas, at least 1 of those requests must be routed to each replica. This is essentially a test that says "flip a coin 10 times, fail if all 10 are heads *OR* if all 10 are tails" Statistically speaking 2 out of every 1024 runs of this test (1/512) should fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7752) Findbugs: Array.equals is equivalent to comparing references
[ https://issues.apache.org/jira/browse/LUCENE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051061#comment-16051061 ] Daniel Jelinski commented on LUCENE-7752: - Okay, I think I got to the bottom of this. The FlattenGraphFilter is a bit lazy when it comes to freeing visited graph nodes. When it's done processing nodes 1,3,5, it frees nodes <1 (=0). When it's done processing nodes 2,4,6 it frees nodes <2 (=1). In order to process node 7 it loads the entire graph up to node 14, pushing the number of concurrently buffered nodes up to 13, which triggers test failure. I modified the code to free nodes eagerly, so that releasing unneeded nodes happens before processing, not after. This made the beast happy. Anyway, this problem probably deserves a separate bug. > Findbugs: Array.equals is equivalent to comparing references > > > Key: LUCENE-7752 > URL: https://issues.apache.org/jira/browse/LUCENE-7752 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Daniel Jelinski >Priority: Minor > Attachments: failing_graph.png, LUCENE-7752.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-6.x - Build # 924 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/924/ 2 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([34A4C601B739602:886D9FB15A753D86]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856) at org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.
[jira] [Commented] (LUCENE-7752) Findbugs: Array.equals is equivalent to comparing references
[ https://issues.apache.org/jira/browse/LUCENE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050950#comment-16050950 ] Daniel Jelinski commented on LUCENE-7752: - Thanks [~cpoerschke] for introducing me to ant beast, wasn't familiar with it. I was able to produce a fairly small failing case. 2 synonyms: aaa=>xxx (keepOriginal=true) aaa=>yyy (keepOriginal=true) Document: aa Fails with flatten maxLookaheadUsed=13. This looks suspicious to me given that the entire flattened graph has only 15 nodes (including start and stop): !failing_graph.png! I'm still trying to figure this out. > Findbugs: Array.equals is equivalent to comparing references > > > Key: LUCENE-7752 > URL: https://issues.apache.org/jira/browse/LUCENE-7752 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Daniel Jelinski >Priority: Minor > Attachments: failing_graph.png, LUCENE-7752.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7752) Findbugs: Array.equals is equivalent to comparing references
[ https://issues.apache.org/jira/browse/LUCENE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Jelinski updated LUCENE-7752: Attachment: failing_graph.png > Findbugs: Array.equals is equivalent to comparing references > > > Key: LUCENE-7752 > URL: https://issues.apache.org/jira/browse/LUCENE-7752 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Daniel Jelinski >Priority: Minor > Attachments: failing_graph.png, LUCENE-7752.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3756 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3756/ Java: 32bit/jdk1.8.0_131 -client -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([9A4F1937C4D47EFD:1168CAE685D2D579]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856) at org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.ap
[jira] [Resolved] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-10834.
-
Resolution: Fixed
Assignee: Hoss Man
Fix Version/s: 6.7
master (7.0)
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0), 6.7
>
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10895) Upgrade to Tika 1.14
[ https://issues.apache.org/jira/browse/SOLR-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050872#comment-16050872 ] Isabelle Giguere commented on SOLR-10895: - Sorry for the duplicate, and thanks for the links. I didn't see it in my search results. > Upgrade to Tika 1.14 > > > Key: SOLR-10895 > URL: https://issues.apache.org/jira/browse/SOLR-10895 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.4.1, 6.6 >Reporter: Isabelle Giguere > > "Apache Tika before 1.14 allows Java code execution for serialized objects > embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do > native deserialization." > a few links: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6809 > https://nvd.nist.gov/vuln/detail/CVE-2016-6809 > ** > This was originally reported by my employer's Security Analysis team. > We are still on Solr 5.4.1. It would be good to know that this security > issue could be fixed with an eventual Solr upgrade. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050869#comment-16050869
]
ASF subversion and git services commented on SOLR-10834:
Commit 625b1cba8be77cca061c72420050aa0c766aab39 in lucene-solr's branch
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=625b1cb ]
SOLR-10834: Fixed tests and test configs to stop using numeric uniqueKey fields
Squashed commit of the following (from jira/SOLR-10834 branch):
commit 8f1043840f38533864b2c713daf066b6c3509147
commit 7b95773bd524cd86aaccc56cc33a003a9aff2004
commit b26bf9d60e2b94e0cdc365d1e2c0a37c33e24198
commit df11992106f8c338503b6e3e9a27ba6ddcfa2953
commit fcf98132410ed247e451bb449a8337a09bd857ce
commit 05e8e226de359a6d7bc99219eaec161a32268f17
commit 6dce948294351560948a32b64679b1879657af79
commit 53f97845caaa8adc25862e4017b94f3091063552
commit d5bfb5f57016341fbeaf73b5e4c9ed10dc3816d0
commit d333f7b1eee10893a81532ac2f5a77a46716d90b
commit 15983ceec4702dc8c7562250d59cd8231c67d46a
commit e18e2e771fb4678cb911a62bbc7c74a873466bf0
commit 134e210bdf601600a9d90dd0720a35cb122896b0
commit ec03260265f8a3bbdfd7f9b015de16a4950a05eb
commit 5d430057ed335801a524e1e7666061075ab6d859
commit 1625df3d21b8fa27815d7a7b89a55fc338eeb23b
(cherry picked from commit f1e2be64519a9ec815785b59e6187c3e99f7d998)
Conflicts:
solr/core/src/test/org/apache/solr/cloud/FullThrottleStoppableIndexingThread.java
solr/core/src/test/org/apache/solr/cloud/SegmentTerminateEarlyTestState.java
solr/core/src/test/org/apache/solr/cloud/autoscaling/AutoScalingHandlerTest.java
solr/core/src/test/org/apache/solr/core/MockInfoBean.java
solr/core/src/test/org/apache/solr/core/TestJmxIntegration.java
solr/core/src/test/org/apache/solr/handler/admin/MBeansHandlerTest.java
solr/core/src/test/org/apache/solr/handler/component/QueryElevationComponentTest.java
solr/core/src/test/org/apache/solr/schema/CopyFieldTest.java
solr/core/src/test/org/apache/solr/search/function/SortByFunctionTest.java
solr/core/src/test/org/apache/solr/search/mlt/SimpleMLTQParserTest.java
solr/core/src/test/org/apache/solr/search/stats/TestDistribIDF.java
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050868#comment-16050868
]
ASF subversion and git services commented on SOLR-10834:
Commit 625b1cba8be77cca061c72420050aa0c766aab39 in lucene-solr's branch
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=625b1cb ]
SOLR-10834: Fixed tests and test configs to stop using numeric uniqueKey fields
Squashed commit of the following (from jira/SOLR-10834 branch):
commit 8f1043840f38533864b2c713daf066b6c3509147
commit 7b95773bd524cd86aaccc56cc33a003a9aff2004
commit b26bf9d60e2b94e0cdc365d1e2c0a37c33e24198
commit df11992106f8c338503b6e3e9a27ba6ddcfa2953
commit fcf98132410ed247e451bb449a8337a09bd857ce
commit 05e8e226de359a6d7bc99219eaec161a32268f17
commit 6dce948294351560948a32b64679b1879657af79
commit 53f97845caaa8adc25862e4017b94f3091063552
commit d5bfb5f57016341fbeaf73b5e4c9ed10dc3816d0
commit d333f7b1eee10893a81532ac2f5a77a46716d90b
commit 15983ceec4702dc8c7562250d59cd8231c67d46a
commit e18e2e771fb4678cb911a62bbc7c74a873466bf0
commit 134e210bdf601600a9d90dd0720a35cb122896b0
commit ec03260265f8a3bbdfd7f9b015de16a4950a05eb
commit 5d430057ed335801a524e1e7666061075ab6d859
commit 1625df3d21b8fa27815d7a7b89a55fc338eeb23b
(cherry picked from commit f1e2be64519a9ec815785b59e6187c3e99f7d998)
Conflicts:
solr/core/src/test/org/apache/solr/cloud/FullThrottleStoppableIndexingThread.java
solr/core/src/test/org/apache/solr/cloud/SegmentTerminateEarlyTestState.java
solr/core/src/test/org/apache/solr/cloud/autoscaling/AutoScalingHandlerTest.java
solr/core/src/test/org/apache/solr/core/MockInfoBean.java
solr/core/src/test/org/apache/solr/core/TestJmxIntegration.java
solr/core/src/test/org/apache/solr/handler/admin/MBeansHandlerTest.java
solr/core/src/test/org/apache/solr/handler/component/QueryElevationComponentTest.java
solr/core/src/test/org/apache/solr/schema/CopyFieldTest.java
solr/core/src/test/org/apache/solr/search/function/SortByFunctionTest.java
solr/core/src/test/org/apache/solr/search/mlt/SimpleMLTQParserTest.java
solr/core/src/test/org/apache/solr/search/stats/TestDistribIDF.java
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10897) SimpleQParserPlugin doesn't work with PointFields
Tomás Fernández Löbbe created SOLR-10897: Summary: SimpleQParserPlugin doesn't work with PointFields Key: SOLR-10897 URL: https://issues.apache.org/jira/browse/SOLR-10897 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Tomás Fernández Löbbe -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10896) RawQParserPlugin doesn't work with PointFields
Tomás Fernández Löbbe created SOLR-10896: Summary: RawQParserPlugin doesn't work with PointFields Key: SOLR-10896 URL: https://issues.apache.org/jira/browse/SOLR-10896 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Tomás Fernández Löbbe -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 371 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/371/ 3 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([621044E7C44DCEEB:E9379736854B656F]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856) at org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFai
[jira] [Commented] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored
[
https://issues.apache.org/jira/browse/SOLR-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050864#comment-16050864
]
Tomás Fernández Löbbe commented on SOLR-10864:
--
+1
One more issue is with the fact that PointFields don't use FieldCache (mv only
since SOLR-10472), and many tests may be using those fields for faceting/stats,
etc. Maybe no longer an issue if we do SOLR-10808 first (and update schema
version)? Or do you have other plans?
> Add static (test only) boolean to PointField indicating 'precisionStep'
> should be ignored
> -
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good
> randomized test coverage of Points fields, I'd like to add the following to
> the {{PointField}} class...
> {code}
> /**
> *
> * The Test framework can set this global variable to instruct PointField
> that
> * (on init) it should be tollerant of the precisionStep
> argument used by TrieFields.
> * This allows for simple randomization of TrieFields and PointFields w/o
> extensive duplication
> * of
[jira] [Resolved] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
[ https://issues.apache.org/jira/browse/SOLR-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe resolved SOLR-10795. -- Resolution: Fixed Assignee: Tomás Fernández Löbbe Fix Version/s: 6.7 master (7.0) > Numeric PointsFields: test multivalued sort using field(name, min|max) syntax > - > > Key: SOLR-10795 > URL: https://issues.apache.org/jira/browse/SOLR-10795 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Tomás Fernández Löbbe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10795.patch, SOLR-10795.patch > > > TestMinMaxOnMultiValuedField tests Trie types for this case, should also test > Points -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
[ https://issues.apache.org/jira/browse/SOLR-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050841#comment-16050841 ] ASF subversion and git services commented on SOLR-10795: Commit ddc128b1099723e8cc2e588958f9043cb9f73bb0 in lucene-solr's branch refs/heads/branch_6x from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ddc128b ] SOLR-10795: Better testing of PointFields multivalued sort using field(name, min|max) syntax > Numeric PointsFields: test multivalued sort using field(name, min|max) syntax > - > > Key: SOLR-10795 > URL: https://issues.apache.org/jira/browse/SOLR-10795 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > Attachments: SOLR-10795.patch, SOLR-10795.patch > > > TestMinMaxOnMultiValuedField tests Trie types for this case, should also test > Points -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050824#comment-16050824 ] ASF subversion and git services commented on SOLR-10891: Commit 5c498b411d8f89c7630fc6a5ca7237c496ed45d4 in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5c498b4 ] SOLR-10891: Don't require docvalues on BBoxField > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050823#comment-16050823 ] ASF subversion and git services commented on SOLR-10891: Commit 85615c6ecdb5ffb872f1d6599714295d0bebec21 in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=85615c6 ] SOLR-10891: Don't require docvalues on BBoxField > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10895) Upgrade to Tika 1.14
[ https://issues.apache.org/jira/browse/SOLR-10895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomás Fernández Löbbe resolved SOLR-10895. -- Resolution: Duplicate Thanks for reporting Isabelle, there is already a Jira issue for this upgrade. Feel free to comment there. > Upgrade to Tika 1.14 > > > Key: SOLR-10895 > URL: https://issues.apache.org/jira/browse/SOLR-10895 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 5.4.1, 6.6 >Reporter: Isabelle Giguere > > "Apache Tika before 1.14 allows Java code execution for serialized objects > embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do > native deserialization." > a few links: > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6809 > https://nvd.nist.gov/vuln/detail/CVE-2016-6809 > ** > This was originally reported by my employer's Security Analysis team. > We are still on Solr 5.4.1. It would be good to know that this security > issue could be fixed with an eventual Solr upgrade. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10795) Numeric PointsFields: test multivalued sort using field(name, min|max) syntax
[ https://issues.apache.org/jira/browse/SOLR-10795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050809#comment-16050809 ] ASF subversion and git services commented on SOLR-10795: Commit ee18a5f64101eb25e914e64eecbbc306d591b9ad in lucene-solr's branch refs/heads/master from [~tomasflobbe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ee18a5f ] SOLR-10795: Better testing of PointFields multivalued sort using field(name, min|max) syntax > Numeric PointsFields: test multivalued sort using field(name, min|max) syntax > - > > Key: SOLR-10795 > URL: https://issues.apache.org/jira/browse/SOLR-10795 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe > Attachments: SOLR-10795.patch, SOLR-10795.patch > > > TestMinMaxOnMultiValuedField tests Trie types for this case, should also test > Points -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10895) Upgrade to Tika 1.14
Isabelle Giguere created SOLR-10895: --- Summary: Upgrade to Tika 1.14 Key: SOLR-10895 URL: https://issues.apache.org/jira/browse/SOLR-10895 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 6.6, 5.4.1 Reporter: Isabelle Giguere "Apache Tika before 1.14 allows Java code execution for serialized objects embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do native deserialization." a few links: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6809 https://nvd.nist.gov/vuln/detail/CVE-2016-6809 ** This was originally reported by my employer's Security Analysis team. We are still on Solr 5.4.1. It would be good to know that this security issue could be fixed with an eventual Solr upgrade. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10894) Streaming expressions handling of escaped special characters bug
Houston Putman created SOLR-10894:
-
Summary: Streaming expressions handling of escaped special
characters bug
Key: SOLR-10894
URL: https://issues.apache.org/jira/browse/SOLR-10894
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Houston Putman
Streaming expressions expect all special characters in named parameter values
to be singly escaped. Since queries can contain strings surrounded by double
quotes, double-escaping is necessary.
Given the following query:
{{summary:"\"This is a summary\"\+"}}
A streaming expression would require surrounding the query with double quotes,
therefore every special character in the query should be escaped:
{{select(collection,q="\"\\\"This is a summary\\\"\\\+\"",)}}
Streaming expressions should unescape the strings contained within double
quotes, however currently they are only unescaping {{\" -> "}}. Therefore it is
impossible to query for text fields containing double quotes. Also other
special characters are not unescaped; this inconsistency causes confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050790#comment-16050790 ] Steve Rowe commented on SOLR-10891: --- bq. Steve, I think your change made docValues mandatory but it was not mandatory before. BBoxField essentially has 2 features – one is for filtering (doesn't require docValues) and the other is for relevancy/sorting (does require docValues). Thanks for looking [~dsmiley], I'll fix it. > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050786#comment-16050786 ] David Smiley commented on SOLR-10891: - Steve, I think your change made docValues mandatory but it was not mandatory before. BBoxField essentially has 2 features -- one is for filtering (doesn't require docValues) and the other is for relevancy/sorting (does require docValues). > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-10891. --- Resolution: Fixed Fix Version/s: 6.7 master (7.0) > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Fix For: master (7.0), 6.7 > > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050775#comment-16050775 ] ASF subversion and git services commented on SOLR-10891: Commit 4fe9d4402fea49b11adbff6529c150974a4c7e32 in lucene-solr's branch refs/heads/master from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4fe9d44 ] SOLR-10891: BBoxField should support point-based number sub-fields > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050772#comment-16050772 ] ASF subversion and git services commented on SOLR-10891: Commit 631e1d4b7848692ee78b9f64bb70e2c2c0231e79 in lucene-solr's branch refs/heads/branch_6x from [~steve_rowe] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=631e1d4 ] SOLR-10891: BBoxField should support point-based number sub-fields Conflicts: solr/core/src/java/org/apache/solr/schema/BBoxField.java > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7452) json facet api returning inconsistent counts in cloud set up
[
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-7452.
Resolution: Fixed
Fix Version/s: master (7.0)
OK, I've committed the last required bits, removed debugging code, and added a
CHANGES entry.
> json facet api returning inconsistent counts in cloud set up
>
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>Assignee: Yonik Seeley
> Labels: count, facet, sort
> Fix For: master (7.0)
>
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent
> returns of counts of faceted value ( Note I am running on a cloud mode of
> solr). For example consider that i have txns_id(unique field or key),
> consumer_number and amount. Now for a 10 million such records , lets say i
> query for
> q=*:*&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
> "numBuckets":3112708,
> "buckets":[{
> "val":"surya",
> "count":4,
> "y":2.264506},
> {
> "val":"raghu",
> "COUNT":3, // capitalised for recognition
> "y":1.8},
> {
> "val":"malli",
> "count":4,
> "y":1.78}]}}}
> but if i restrict the query to
> q=consumer_number:raghu&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> i get :
> "facets":{
> "count":4,
> "biskatoo":{
> "numBuckets":1,
> "buckets":[{
> "val":"raghu",
> "COUNT":4,
> "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but
> still the issue seems not resolved
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7452) json facet api returning inconsistent counts in cloud set up
[
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley reassigned SOLR-7452:
--
Assignee: Yonik Seeley
> json facet api returning inconsistent counts in cloud set up
>
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
>Assignee: Yonik Seeley
> Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent
> returns of counts of faceted value ( Note I am running on a cloud mode of
> solr). For example consider that i have txns_id(unique field or key),
> consumer_number and amount. Now for a 10 million such records , lets say i
> query for
> q=*:*&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
> "numBuckets":3112708,
> "buckets":[{
> "val":"surya",
> "count":4,
> "y":2.264506},
> {
> "val":"raghu",
> "COUNT":3, // capitalised for recognition
> "y":1.8},
> {
> "val":"malli",
> "count":4,
> "y":1.78}]}}}
> but if i restrict the query to
> q=consumer_number:raghu&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> i get :
> "facets":{
> "count":4,
> "biskatoo":{
> "numBuckets":1,
> "buckets":[{
> "val":"raghu",
> "COUNT":4,
> "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but
> still the issue seems not resolved
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7452) json facet api returning inconsistent counts in cloud set up
[
https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050761#comment-16050761
]
ASF subversion and git services commented on SOLR-7452:
---
Commit 3b5f3cc3edfaf22b41f3f969391b56be482fb7b4 in lucene-solr's branch
refs/heads/master from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3b5f3cc ]
SOLR-7452: add CHANGES for refinement, remove debugging output, don't indent
_facet_ refinement info
> json facet api returning inconsistent counts in cloud set up
>
>
> Key: SOLR-7452
> URL: https://issues.apache.org/jira/browse/SOLR-7452
> Project: Solr
> Issue Type: Bug
> Components: Facet Module
>Affects Versions: 5.1
>Reporter: Vamsi Krishna D
> Labels: count, facet, sort
> Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch
>
> Original Estimate: 96h
> Remaining Estimate: 96h
>
> While using the newly added feature of json term facet api
> (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent
> returns of counts of faceted value ( Note I am running on a cloud mode of
> solr). For example consider that i have txns_id(unique field or key),
> consumer_number and amount. Now for a 10 million such records , lets say i
> query for
> q=*:*&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> the results are as follows ( some are omitted ):
> "facets":{
> "count":6641277,
> "biskatoo":{
> "numBuckets":3112708,
> "buckets":[{
> "val":"surya",
> "count":4,
> "y":2.264506},
> {
> "val":"raghu",
> "COUNT":3, // capitalised for recognition
> "y":1.8},
> {
> "val":"malli",
> "count":4,
> "y":1.78}]}}}
> but if i restrict the query to
> q=consumer_number:raghu&rows=0&
> json.facet={
>biskatoo:{
>type : terms,
>field : consumer_number,
>limit : 20,
> sort : {y:desc},
> numBuckets : true,
> facet:{
>y : "sum(amount)"
>}
>}
> }
> i get :
> "facets":{
> "count":4,
> "biskatoo":{
> "numBuckets":1,
> "buckets":[{
> "val":"raghu",
> "COUNT":4,
> "y":2429708.24}]}}}
> One can see the count results are inconsistent ( and I found many occasions
> of inconsistencies).
> I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but
> still the issue seems not resolved
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7868) Use multiple threads to apply deletes and DV updates
[ https://issues.apache.org/jira/browse/LUCENE-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-7868: --- Attachment: LUCENE-7868.patch Another iteration, I think it's ready! All nocommits are gone, all tests and "ant precommit" passes. I'll beast all tests some more before pushing. I improved how we compress the frozen packet of DV updates for better RAM efficiency: each frozen packet is ~8.3% of the original size of the un-frozen packet in my benchmark. I also tested DV updates performance, updating the price field in my internal corpus. With no refresh (just writing DV updates when RAM buffer is full) trunk updates at 8.0 K docs/sec, and the patch 58.0 K docs/sec (7.25X faster). With refresh every 60 seconds, trunk gets 7.4 K docs/sec and the patch gets 63.7 K docs/sec (8.6X faster). This is with 12 threads, 128 MB IW buffer. > Use multiple threads to apply deletes and DV updates > > > Key: LUCENE-7868 > URL: https://issues.apache.org/jira/browse/LUCENE-7868 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: master (7.0) > > Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, > LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch > > > Today, when users delete documents or apply doc values updates, IndexWriter > buffers them up into frozen packets and then eventually uses a single thread > (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms > to docids. This thread also holds IW's monitor lock, so it also blocks > refresh, merges starting/finishing, commits, etc. > We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, > LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it > can't use multiple CPU cores commonly available now. > This doesn't affect append-only usage, but for update-heavy users (me!) this > can be a big bottleneck, and causes long stop-the-world hangs during indexing. > I have an initial exploratory patch to make these lookups concurrent, without > holding IW's lock, so that when a new packet of deletes is pushed, which > happens when we flush a new segment, we immediately use that same indexing > thread to and resolve the deletions. > This is analogous to when we made segment flushing concurrent (LUCENE-3023), > just for deletes and DV updates as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4076 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4076/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll Error Message: Error from server at http://127.0.0.1:60392/solr/testStopAllStartAllCollection_shard1_replica_n2: java.io.FileNotFoundException: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J1/temp/solr.cloud.TestMiniSolrCloudCluster_71621BF108341F5-001/tempDir-001/node2/testStopAllStartAllCollection_shard1_replica_n2/data/tlog/tlog.000 (Too many open files) Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:60392/solr/testStopAllStartAllCollection_shard1_replica_n2: java.io.FileNotFoundException: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J1/temp/solr.cloud.TestMiniSolrCloudCluster_71621BF108341F5-001/tempDir-001/node2/testStopAllStartAllCollection_shard1_replica_n2/data/tlog/tlog.000 (Too many open files) at __randomizedtesting.SeedInfo.seed([71621BF108341F5:71283ECC51B4ECDA]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:552) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1002) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:173) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:138) at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:152) at org.apache.solr.cloud.TestMiniSolrCloudCluster.testStopAllStartAll(TestMiniSolrCloudCluster.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomiz
[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050700#comment-16050700
]
ASF subversion and git services commented on SOLR-10834:
Commit f1e2be64519a9ec815785b59e6187c3e99f7d998 in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f1e2be6 ]
SOLR-10834: Fixed tests and test configs to stop using numeric uniqueKey fields
Squashed commit of the following (from jira/SOLR-10834 branch):
commit 8f1043840f38533864b2c713daf066b6c3509147
commit 7b95773bd524cd86aaccc56cc33a003a9aff2004
commit b26bf9d60e2b94e0cdc365d1e2c0a37c33e24198
commit df11992106f8c338503b6e3e9a27ba6ddcfa2953
commit fcf98132410ed247e451bb449a8337a09bd857ce
commit 05e8e226de359a6d7bc99219eaec161a32268f17
commit 6dce948294351560948a32b64679b1879657af79
commit 53f97845caaa8adc25862e4017b94f3091063552
commit d5bfb5f57016341fbeaf73b5e4c9ed10dc3816d0
commit d333f7b1eee10893a81532ac2f5a77a46716d90b
commit 15983ceec4702dc8c7562250d59cd8231c67d46a
commit e18e2e771fb4678cb911a62bbc7c74a873466bf0
commit 134e210bdf601600a9d90dd0720a35cb122896b0
commit ec03260265f8a3bbdfd7f9b015de16a4950a05eb
commit 5d430057ed335801a524e1e7666061075ab6d859
commit 1625df3d21b8fa27815d7a7b89a55fc338eeb23b
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050699#comment-16050699
]
ASF subversion and git services commented on SOLR-10834:
Commit f1e2be64519a9ec815785b59e6187c3e99f7d998 in lucene-solr's branch
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f1e2be6 ]
SOLR-10834: Fixed tests and test configs to stop using numeric uniqueKey fields
Squashed commit of the following (from jira/SOLR-10834 branch):
commit 8f1043840f38533864b2c713daf066b6c3509147
commit 7b95773bd524cd86aaccc56cc33a003a9aff2004
commit b26bf9d60e2b94e0cdc365d1e2c0a37c33e24198
commit df11992106f8c338503b6e3e9a27ba6ddcfa2953
commit fcf98132410ed247e451bb449a8337a09bd857ce
commit 05e8e226de359a6d7bc99219eaec161a32268f17
commit 6dce948294351560948a32b64679b1879657af79
commit 53f97845caaa8adc25862e4017b94f3091063552
commit d5bfb5f57016341fbeaf73b5e4c9ed10dc3816d0
commit d333f7b1eee10893a81532ac2f5a77a46716d90b
commit 15983ceec4702dc8c7562250d59cd8231c67d46a
commit e18e2e771fb4678cb911a62bbc7c74a873466bf0
commit 134e210bdf601600a9d90dd0720a35cb122896b0
commit ec03260265f8a3bbdfd7f9b015de16a4950a05eb
commit 5d430057ed335801a524e1e7666061075ab6d859
commit 1625df3d21b8fa27815d7a7b89a55fc338eeb23b
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050698#comment-16050698
]
ASF subversion and git services commented on SOLR-10834:
Commit 8f1043840f38533864b2c713daf066b6c3509147 in lucene-solr's branch
refs/heads/jira/SOLR-10834 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8f10438 ]
Merge branch 'master' into jira/SOLR-10834
> test configs should be changed to stop using numeric based uniqueKey field
> --
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7500) Remove LeafReader.fields()
[
https://issues.apache.org/jira/browse/LUCENE-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050697#comment-16050697
]
ASF subversion and git services commented on LUCENE-7500:
-
Commit abc393dbfdb805361747ef651393332968851f3d in lucene-solr's branch
refs/heads/jira/SOLR-10834 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=abc393d ]
LUCENE-7500: Remove LeafReader.fields in lieu of LeafReader.terms.
Optimized MultiFields.getTerms.
> Remove LeafReader.fields()
> --
>
> Key: LUCENE-7500
> URL: https://issues.apache.org/jira/browse/LUCENE-7500
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7500_avoid_leafReader_fields.patch,
> LUCENE_7500_avoid_leafReader_fields.patch,
> LUCENE_7500_Remove_LeafReader_fields.patch,
> LUCENE_7500_Remove_LeafReader_fields.patch,
> LUCENE_7500_Remove_LeafReader_fields.patch
>
>
> {{Fields}} seems like a pointless intermediary between the {{LeafReader}} and
> {{Terms}}. Why not have {{LeafReader.getTerms(fieldName)}} instead? One loses
> the ability to get the count and iterate over indexed fields, but it's not
> clear what real use-cases are for that and such rare needs could figure that
> out with FieldInfos.
> [~mikemccand] pointed out that we'd probably need to re-introduce a
> {{TermVectors}} class since TV's are row-oriented not column-oriented. IMO
> they should be column-oriented but that'd be a separate issue.
> _(p.s. I'm lacking time to do this w/i the next couple months so if someone
> else wants to tackle it then great)_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-10891: -- Attachment: SOLR-10891.patch Patch, the test passes for me now. Thanks [~dsmiley] for the pointers. Fortunately I didn't have to make any modifications to BBoxStrategy. The issue was that the fix for the frozen Point fieldtype (see my first comment above) stripped the identity of the Trie fieldtype, which caused other code to think the fieldtype was neither fish nor fowl; I fixed it by only copying the fieldtype if it's not a Trie fieldtype. The unsupported operation exceptions were due to special case for "bbox" fieldName only skipping of non-rectangles in checkHits(); I just added a case for the new "pbbox" fieldName. I'll commit this once precommit and all tests pass. > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Attachments: SOLR-10891.patch, SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10891) BBoxField does not support point-based number sub-fields
[ https://issues.apache.org/jira/browse/SOLR-10891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reassigned SOLR-10891: - Assignee: Steve Rowe > BBoxField does not support point-based number sub-fields > > > Key: SOLR-10891 > URL: https://issues.apache.org/jira/browse/SOLR-10891 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Steve Rowe >Assignee: Steve Rowe > Attachments: SOLR-10891.patch, tests-failures.txt > > > I noticed while removing Trie fields from example schemas on SOLR-10760 that > BBoxField uses Trie fields in at least one example schema. > I went looking and there is theoretical machinery to support points, but when > I added a point-based bbox variant to TestSolr4Spatial, I get test failures. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10893) SolrClients used by streaming should support setting max connections
[ https://issues.apache.org/jira/browse/SOLR-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050602#comment-16050602 ] Varun Thacker commented on SOLR-10893: -- bq. Thoughts? Do we want to keep search threads and streaming threads part of separate pools? I am currently inclined to use the same httpclient that is used in the HttpShardHandlerFactory. Even if we have separate thread pools for httpShardHandlerFactory and streaming , a user cannot limit parallel analytic queries by reducing the thread pool as they all come from the same jetty thread pool? Maybe it would be part of SOLR-7344 or can be separate after that issue get's committed? > SolrClients used by streaming should support setting max connections > > > Key: SOLR-10893 > URL: https://issues.apache.org/jira/browse/SOLR-10893 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker > > All the streaming expressions , SQL queries use a common SolrClientCache for > issuing the underlying queries. > Today we use a default HttpClient while creating this which means if we > running many parallel stream queries or deeply nested queries we can exhaust > this. > We should allow users to set higher defaults for max connections, max > connections per route etc. > Today since we use a default HttpClient does Streaming work with auth enabled > or in kerberos mode? I'll look into this and confirm. > My idea is we could probably refactor in a way that CoreContainer keeps an > object of SolrClientCache which uses the httpclient that is currently used > for searches ( HttpShardHandlerFactory ) . This means we don't need to > introduce more settings . > Thoughts? Do we want to keep search threads and streaming threads part of > separate pools? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source
[
https://issues.apache.org/jira/browse/SOLR-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050575#comment-16050575
]
Mano Kovacs commented on SOLR-10783:
bq. Why remove the quotes on this variable? Will that have other side affects?
{{SOLR_JETTY_CONFIG}} is solely used to pass {{--module=http(s)}} to
{{start.jar}}. It is defined in the scripts so it was not usable from the
outside. It is working both {{start.jar "--module=http"}} and {{start.jar
--module=http}}, so it was not an issue before, but I added quoted jetty config
so I removed the quotes to prevent double quotes.
> Using Hadoop Credential Provider as SSL/TLS store password source
> -
>
> Key: SOLR-10783
> URL: https://issues.apache.org/jira/browse/SOLR-10783
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10783.patch
>
>
> As a second iteration of SOLR-10307, I propose support of hadoop credential
> providers as source of SSL store passwords.
> Motivation: When SOLR is used in hadoop environment, support of HCP gives
> better integration and unified method to pass sensitive credentials to SOLR.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source
[
https://issues.apache.org/jira/browse/SOLR-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050575#comment-16050575
]
Mano Kovacs edited comment on SOLR-10783 at 6/15/17 2:57 PM:
-
bq. Why remove the quotes on this variable? Will that have other side affects?
{{SOLR_JETTY_CONFIG}} is solely used to pass {{\-\-module=http(s)}} to
{{start.jar}}. It is defined in the scripts so it was not usable from the
outside. It is working both {{start.jar "--module=http"}} and {{start.jar
-\-module=http}}, so it was not an issue before, but I added quoted jetty
config so I removed the quotes to prevent double quotes.
was (Author: manokovacs):
bq. Why remove the quotes on this variable? Will that have other side affects?
{{SOLR_JETTY_CONFIG}} is solely used to pass {{--module=http(s)}} to
{{start.jar}}. It is defined in the scripts so it was not usable from the
outside. It is working both {{start.jar "--module=http"}} and {{start.jar
--module=http}}, so it was not an issue before, but I added quoted jetty config
so I removed the quotes to prevent double quotes.
> Using Hadoop Credential Provider as SSL/TLS store password source
> -
>
> Key: SOLR-10783
> URL: https://issues.apache.org/jira/browse/SOLR-10783
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10783.patch
>
>
> As a second iteration of SOLR-10307, I propose support of hadoop credential
> providers as source of SSL store passwords.
> Motivation: When SOLR is used in hadoop environment, support of HCP gives
> better integration and unified method to pass sensitive credentials to SOLR.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10824) java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats
[
https://issues.apache.org/jira/browse/SOLR-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-10824:
Attachment: SOLR-10824.patch
* NPE fix is nobrainer itself.
* NPE is reproduced if id query is issued before regular query (hitting all
shards and warming cache there).
* but id query fails tests because maxdoc (colStat) from no-hits shards are
omitted. [^SOLR-10824.patch] shares colStat even it has no certain term (and
probably field).
[~varunthacker], [~erickerickson], what do you think if I commit it?
> java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats
> --
>
> Key: SOLR-10824
> URL: https://issues.apache.org/jira/browse/SOLR-10824
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-10824.patch, SOLR-10824.patch, SOLR-10824.patch
>
>
> {quote}
> INFO [qtp411311908-32] (SolrCore.java:2304) - [collection1_shard3_replica2]
> webapp=/solr path=/select
> params={..&distrib=false&_stateVer_=collection1:5...&shards.purpose=32768&shard.url=http://127.0.0.1:57114/solr/collection1_shard3_replica2/|http://127.0.0.1:57112/solr/collection1_shard3_replica1/&version=2)&NOW=1496751847089&isShard=true&applicability.frm=FRM&wt=javabin}
> status=0 QTime=18
> INFO [qtp2123780104-30] (SolrCore.java:2304) - [collection1_shard1_replica1]
> ...
> INFO [qtp411311908-45] (SolrCore.java:2304) - [collection1_shard2_replica1]
> ...
> ERROR [qtp411311908-33] (SolrException.java:148) -
> java.lang.NullPointerException
> at
> org.apache.solr.search.stats.ExactSharedStatsCache.getPerShardTermStats(ExactSharedStatsCache.java:76)
> at
> org.apache.solr.search.stats.ExactStatsCache.sendGlobalStats(ExactStatsCache.java:233)
> at
> org.apache.solr.handler.component.QueryComponent.createMainQuery(QueryComponent.java:930)
> at
> org.apache.solr.handler.component.QueryComponent.regularDistributedProcess(QueryComponent.java:726)
> at
> org.apache.solr.handler.component.QueryComponent.distributedProcess(QueryComponent.java:679)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:345)
> INFO [qtp411311908-33] (SolrCore.java:2304) - [collection1_shard3_replica2]
> webapp=/solr path=/select params={...&wt=javabin&version=2} status=500
> QTime=82
> {quote}
> Switching to {{LRUStatsCache}} seems help.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source
[
https://issues.apache.org/jira/browse/SOLR-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050545#comment-16050545
]
Mark Miller commented on SOLR-10783:
{noformat}
--Djava.io.tmpdir="%SOLR_SERVER_DIR%\tmp" -jar start.jar
"%SOLR_JETTY_CONFIG%"
+-Djava.io.tmpdir="%SOLR_SERVER_DIR%\tmp" -jar start.jar %SOLR_JETTY_CONFIG%
{noformat}
Why remove the quotes on this variable? Will that have other side affects?
> Using Hadoop Credential Provider as SSL/TLS store password source
> -
>
> Key: SOLR-10783
> URL: https://issues.apache.org/jira/browse/SOLR-10783
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10783.patch
>
>
> As a second iteration of SOLR-10307, I propose support of hadoop credential
> providers as source of SSL store passwords.
> Motivation: When SOLR is used in hadoop environment, support of HCP gives
> better integration and unified method to pass sensitive credentials to SOLR.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source
[ https://issues.apache.org/jira/browse/SOLR-10783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-10783: -- Assignee: Mark Miller > Using Hadoop Credential Provider as SSL/TLS store password source > - > > Key: SOLR-10783 > URL: https://issues.apache.org/jira/browse/SOLR-10783 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: security >Reporter: Mano Kovacs >Assignee: Mark Miller > Attachments: SOLR-10783.patch > > > As a second iteration of SOLR-10307, I propose support of hadoop credential > providers as source of SSL store passwords. > Motivation: When SOLR is used in hadoop environment, support of HCP gives > better integration and unified method to pass sensitive credentials to SOLR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+173) - Build # 6650 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6650/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi
Error Message:
Error from server at https://127.0.0.1:53364/solr: Expected mime type
application/octet-stream but got text/html.Error
400HTTP ERROR: 400 Problem accessing
/solr/v2/c. Reason:
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
Illegal char at index 53:
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core estJ1
empsolr.handler.V2ApiIntegrationTest_CAB682315422EEE1-001
empDir-002,code=400} http://eclipse.org/jetty";>Powered
by Jetty:// 9.3.14.v20161028
Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error
from server at https://127.0.0.1:53364/solr: Expected mime type
application/octet-stream but got text/html.
Error 400
HTTP ERROR: 400
Problem accessing /solr/v2/c. Reason:
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=java.nio.file.InvalidPathException},msg=java.nio.file.InvalidPathException:
Illegal char at index 53:
C:UsersjenkinsworkspaceLucene-Solr-master-Windowssolr?uildsolr-core estJ1
empsolr.handler.V2ApiIntegrationTest_CAB682315422EEE1-001
empDir-002,code=400}
http://eclipse.org/jetty";>Powered by Jetty://
9.3.14.v20161028
at
__randomizedtesting.SeedInfo.seed([CAB682315422EEE1:162865B0EC3B8A5F]:0)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:219)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1130)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:871)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at
org.apache.solr.handler.V2ApiIntegrationTest.testCollectionsApi(V2ApiIntegrationTest.java:99)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.
[jira] [Updated] (SOLR-4646) [edismax] let lowercaseOperators default to "false"
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-4646:
--
Attachment: SOLR-4646.patch
Patch
> [edismax] let lowercaseOperators default to "false"
> ---
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: master (7.0)
>
> Attachments: SOLR-4646.patch
>
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-10893) SolrClients used by streaming should support setting max connections
Varun Thacker created SOLR-10893: Summary: SolrClients used by streaming should support setting max connections Key: SOLR-10893 URL: https://issues.apache.org/jira/browse/SOLR-10893 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Varun Thacker All the streaming expressions , SQL queries use a common SolrClientCache for issuing the underlying queries. Today we use a default HttpClient while creating this which means if we running many parallel stream queries or deeply nested queries we can exhaust this. We should allow users to set higher defaults for max connections, max connections per route etc. Today since we use a default HttpClient does Streaming work with auth enabled or in kerberos mode? I'll look into this and confirm. My idea is we could probably refactor in a way that CoreContainer keeps an object of SolrClientCache which uses the httpclient that is currently used for searches ( HttpShardHandlerFactory ) . This means we don't need to introduce more settings . Thoughts? Do we want to keep search threads and streaming threads part of separate pools? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4646) [edismax] let lowercaseOperators default to "false"
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-4646:
--
Summary: [edismax] let lowercaseOperators default to "false" (was:
lowercaseOperators is enabled by default for edismax query parser)
> [edismax] let lowercaseOperators default to "false"
> ---
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: master (7.0)
>
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4586) Eliminate the maxBooleanClauses limit
[ https://issues.apache.org/jira/browse/SOLR-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050407#comment-16050407 ] David Smiley commented on SOLR-4586: bq. remove this completely from all solrconfigs and set default to MAX_INT If we MUST have it configurable somewhere, it belongs in solr.xml or clusterprop. +1 definitely. We still have a limit to those that want it. I appreciate both arguments. The current situation is a bit awkward though -- we should either default to fairly low, or to effectively unlimited. > Eliminate the maxBooleanClauses limit > - > > Key: SOLR-4586 > URL: https://issues.apache.org/jira/browse/SOLR-4586 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.2 > Environment: 4.3-SNAPSHOT 1456767M - ncindex - 2013-03-15 13:11:50 >Reporter: Shawn Heisey > Fix For: 5.2, 6.0 > > Attachments: SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, > SOLR-4586.patch, SOLR-4586.patch, SOLR-4586.patch, > SOLR-4586_verify_maxClauses.patch > > > In the #solr IRC channel, I mentioned the maxBooleanClauses limitation to > someone asking a question about queries. Mark Miller told me that > maxBooleanClauses no longer applies, that the limitation was removed from > Lucene sometime in the 3.x series. The config still shows up in the example > even in the just-released 4.2. > Checking through the source code, I found that the config option is parsed > and the value stored in objects, but does not actually seem to be used by > anything. I removed every trace of it that I could find, and all tests still > pass. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-4646:
--
Fix Version/s: master (7.0)
> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
> Fix For: master (7.0)
>
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl reassigned SOLR-4646:
-
Assignee: Jan Høydahl
> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Assignee: Jan Høydahl
>Priority: Trivial
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4646) lowercaseOperators is enabled by default for edismax query parser
[
https://issues.apache.org/jira/browse/SOLR-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050406#comment-16050406
]
David Smiley commented on SOLR-4646:
+1 [~janhoy]! Thanks for taking care of it.
> lowercaseOperators is enabled by default for edismax query parser
> -
>
> Key: SOLR-4646
> URL: https://issues.apache.org/jira/browse/SOLR-4646
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Affects Versions: 4.1, 4.2
>Reporter: Alexander Koval
>Priority: Trivial
>
> [Documentation|http://wiki.apache.org/solr/ExtendedDisMax#lowercaseOperators]
> says:
> *lowercaseOperators*
> This param controls whether to try to interpret lowercase words as boolean
> operators such as "and", "not" and "or". Set {{&lowercaseOperators=true}} to
> allow this. Default is {{"*false*"}}.
> But in fact {{lowercaseOperators=true}} by default.
> And if one of boolean operators in lowercase is present in query it turns off
> {{mm}} parameter:
> * {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&debugQuery=true}}
> {{"parsedquery_toString": "+((name:young) (name:6) (name:ariston))"}}
> *
> {{q=Young+6+or+Ariston&defType=edismax&qf=name&mm=100%25&lowercaseOperators=false&debugQuery=true}}
> {{"parsedquery_toString": "+(((name:young) (name:6) (name:ariston))~3)"}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9565) Make every UpdateRequestProcessor available implicitly
[
https://issues.apache.org/jira/browse/SOLR-9565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050350#comment-16050350
]
Noble Paul commented on SOLR-9565:
--
bq.shouldn't support for processor=X, X in XURPFactory, continue?
The problem is this leads to unexpected errors when XURPFactory expects some
initialization params. In this case only the ones which are migrated to the new
format can be used. The only problem is when u wish to use a URP which is
loaded from blob store. Users can always issue a config api command to add it
> Make every UpdateRequestProcessor available implicitly
> --
>
> Key: SOLR-9565
> URL: https://issues.apache.org/jira/browse/SOLR-9565
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
> Attachments: SOLR-9565.patch
>
>
> Now that we can 'construct' the URP chains through request parameters, we
> should make all the URPs available automatically. The next challenge is to
> make them read the configuration from request parameters as well
> to access {{HTMLStripFieldUpdateProcessorFactory}} the parameter could be
> {{processor=HTMLStripField}} (The UpdateProcessorFactory part is
> automatically appended )
> The next step is to make the URPs accept request parameters instead of just
> configuration parameters e.g:
> {{processor=HTMLStripField&HTMLStripField.fieldName=}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-10433:
--
Attachment: (was: SOLR-10433.patch)
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-10433:
--
Attachment: SOLR-10433.patch
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050342#comment-16050342
]
Noble Paul edited comment on SOLR-10433 at 6/15/17 11:10 AM:
-
bq.Doing so would simplify the code (fewer null-checks, validation on change,
etc.), and more importantly make the clients safer/less-trappy to use in a
multi-threaded context.
I've removed those setters
was (Author: noble.paul):
I've removed those setters
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050342#comment-16050342
]
Noble Paul commented on SOLR-10433:
---
I've removed those setters
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10433) automatically map collection admin calls from V1 to V2
[
https://issues.apache.org/jira/browse/SOLR-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-10433:
--
Attachment: SOLR-10433.patch
> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Reporter: Noble Paul
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch,
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for
> "properties.solr.tests.maxBufferedDocs"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10824) java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats
[
https://issues.apache.org/jira/browse/SOLR-10824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050294#comment-16050294
]
Mikhail Khludnev commented on SOLR-10824:
-
I don't understand how it may work at all:
{quote}
=== Control Response ===
1.6931472 = weight(id:` in 2) [MockConfigurableSimilarity], result of:
1.6931472 = fieldWeight in 2, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
1.6931472 = idf, computed as log((docCount+1)/(docFreq+1)) + 1 from:
1.0 = docFreq
3.0 = docCount
1.0 = fieldNorm(doc=2)
{quote}
vs
{quote}
=== Shard Response ===
1.4054651 = weight(id:` in 1) [MockConfigurableSimilarity], result of:
1.4054651 = fieldWeight in 1, product of:
1.0 = tf(freq=1.0), with freq of:
1.0 = termFreq=1.0
1.4054651 = idf, computed as log((docCount+1)/(docFreq+1)) + 1 from:
1.0 = docFreq
2.0 = docCount
1.0 = fieldNorm(doc=1)
{quote}
So, the problem is the mismatch between control {{ 3.0 = docCount}} and sharded
{{ 2.0 = docCount}}
I can see stats exchange. It seems fine. But I can't find how global docCount
is applied to scoring. Can someone give a clue?
> java.lang.NullPointerException ExactSharedStatsCache.getPerShardTermStats
> --
>
> Key: SOLR-10824
> URL: https://issues.apache.org/jira/browse/SOLR-10824
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
>Affects Versions: 6.6
>Reporter: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-10824.patch, SOLR-10824.patch
>
>
> {quote}
> INFO [qtp411311908-32] (SolrCore.java:2304) - [collection1_shard3_replica2]
> webapp=/solr path=/select
> params={..&distrib=false&_stateVer_=collection1:5...&shards.purpose=32768&shard.url=http://127.0.0.1:57114/solr/collection1_shard3_replica2/|http://127.0.0.1:57112/solr/collection1_shard3_replica1/&version=2)&NOW=1496751847089&isShard=true&applicability.frm=FRM&wt=javabin}
> status=0 QTime=18
> INFO [qtp2123780104-30] (SolrCore.java:2304) - [collection1_shard1_replica1]
> ...
> INFO [qtp411311908-45] (SolrCore.java:2304) - [collection1_shard2_replica1]
> ...
> ERROR [qtp411311908-33] (SolrException.java:148) -
> java.lang.NullPointerException
> at
> org.apache.solr.search.stats.ExactSharedStatsCache.getPerShardTermStats(ExactSharedStatsCache.java:76)
> at
> org.apache.solr.search.stats.ExactStatsCache.sendGlobalStats(ExactStatsCache.java:233)
> at
> org.apache.solr.handler.component.QueryComponent.createMainQuery(QueryComponent.java:930)
> at
> org.apache.solr.handler.component.QueryComponent.regularDistributedProcess(QueryComponent.java:726)
> at
> org.apache.solr.handler.component.QueryComponent.distributedProcess(QueryComponent.java:679)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:345)
> INFO [qtp411311908-33] (SolrCore.java:2304) - [collection1_shard3_replica2]
> webapp=/solr path=/select params={...&wt=javabin&version=2} status=500
> QTime=82
> {quote}
> Switching to {{LRUStatsCache}} seems help.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-10886) Using V2Request.process(solrClient) method throws NPE if the API returns an error
[
https://issues.apache.org/jira/browse/SOLR-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-10886:
Attachment: SOLR-10886.patch
[~noble.paul] What do you think about this patch?
> Using V2Request.process(solrClient) method throws NPE if the API returns an
> error
> -
>
> Key: SOLR-10886
> URL: https://issues.apache.org/jira/browse/SOLR-10886
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, v2 API
>Affects Versions: master (7.0)
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0)
>
> Attachments: SOLR-10886.patch
>
>
> I was trying to use the V2Request to invoke the Config API and ran into this
> bug. In my case, the command had {{name}} missing but it is a required
> attribute:
> {code}
> String addListenerCommand = "{'add-listener' : {'event':'newSearcher',
> 'class':'" + TestSolrEventListener.class.getName() + "'}}";
> V2Request request = new
> V2Request.Builder("/c/warmingTestColl/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> request.process(solrClient);
> {code}
> The logs show that there was an exception:
> {code}
> 4409 INFO (qtp480792233-31) [n:127.0.0.1:35920_solr c:warmingTestColl
> s:shard1 r:core_node1 x:warmingTestColl_shard1_replica_n1]
> o.a.s.h.SolrConfigHandler Failed to run commands. errors are
> {add-listener={event=newSearcher\,
> class=org.apache.solr.cloud.TestCloudSearcherWarming$TestSolrEventListener}\,
> errorMessages=['name' is a required field]}
> {code}
> But SolrJ, returned an NPE:
> {code}
> java.lang.NullPointerException
> at
> __randomizedtesting.SeedInfo.seed([312F78548DE0B0CB:B97B478E231CDD33]:0)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
> at
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1369 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1369/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: document count mismatch. control=858 sum(shards)=857 cloudClient=857 Stack Trace: java.lang.AssertionError: document count mismatch. control=858 sum(shards)=857 cloudClient=857 at __randomizedtesting.SeedInfo.seed([16E6F69B794E18B2:9EB2C941D7B2754A]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1377) at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:222) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) a
[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19872 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19872/ Java: 32bit/jdk-9-ea+173 -server -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream Error Message: expected:<5> but was:<2> Stack Trace: java.lang.AssertionError: expected:<5> but was:<2> at __randomizedtesting.SeedInfo.seed([67FB4D8A1BBE6E3A:47112F8A87FF8376]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream(StreamExpressionTest.java:4582) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) 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:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 14070 lines...] [junit4] Suite: org.apache.solr.client.solrj.io.stream.StreamExpre
