date:20180322

[jira] [Commented] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Lucene/Solr QA (JIRA)


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

Lucene/Solr QA commented on SOLR-12134:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m  
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m  
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m  0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m  0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m  0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  0m  0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:black}{color} | {color:black} {color} | {color:black}  4m  2s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12134 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12915722/SOLR-12134.patch |
| Optional Tests |  compile  javac  unit  ratsources  validatesourcepatterns  
validaterefguide  checkforbiddenapis  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / e364f5b |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/13/testReport/ |
| modules | C: solr solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/13/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 # 4518 - Still Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4518/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction.testNodeWithMultipleReplicasLost

Error Message:
The operations computed by ComputePlanAction should not be null 
{AFTER_ACTION=[compute_plan, null], BEFORE_ACTION=[compute_plan, null]} event: 
{   "id":"31a456ee86794T5qdm1omq06vll1xv5jm0n5x4i",   
"source":"node_lost_trigger",   "eventTime":873310445922196,   
"eventType":"NODELOST",   "properties":{ "eventTimes":[873310445922196],
 "_enqueue_time_":873322324433846, "nodeNames":["127.0.0.1:10008_solr"]}}

Stack Trace:
java.lang.AssertionError: The operations computed by ComputePlanAction should 
not be null {AFTER_ACTION=[compute_plan, null], BEFORE_ACTION=[compute_plan, 
null]}
event: {
  "id":"31a456ee86794T5qdm1omq06vll1xv5jm0n5x4i",
  "source":"node_lost_trigger",
  "eventTime":873310445922196,
  "eventType":"NODELOST",
  "properties":{
"eventTimes":[873310445922196],
"_enqueue_time_":873322324433846,
"nodeNames":["127.0.0.1:10008_solr"]}}
at 
__randomizedtesting.SeedInfo.seed([4BE996DD454D339A:7B29775FCD3FD2C6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction.testNodeWithMultipleReplicasLost(TestComputePlanAction.java:240)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 20 - Still Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/20/

2 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV2

Error Message:
Unexpected status: HTTP/1.1 400 Bad Request

Stack Trace:
java.lang.AssertionError: Unexpected status: HTTP/1.1 400 Bad Request
at 
__randomizedtesting.SeedInfo.seed([2769D4E753851C64:6D7520FF87194924]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AliasIntegrationTest.assertSuccess(AliasIntegrationTest.java:320)
at 
org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV2(AliasIntegrationTest.java:238)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)


FAILED:  
org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test

Error Message:
Collection not found: myalias

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: myalias
at

[JENKINS] Lucene-Solr-repro - Build # 320 - Still Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-repro/320/

[...truncated 39 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-master/2446/consoleText

[repro] Revision: 2c4b78c43fe2e30ef748af34a1daa174d66e29cc

[repro] Repro line:  ant test  -Dtestcase=CollectionsAPIDistributedZkTest 
-Dtests.method=testCreateShouldFailOnExistingCore -Dtests.seed=C617D3E20919B295 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ar-JO 
-Dtests.timezone=America/Curacao -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=ValueFacetTest 
-Dtests.seed=5BF579E5AE2FF658 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=uk -Dtests.timezone=America/Sitka -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=LegacyFieldFacetExtrasCloudTest 
-Dtests.seed=5BF579E5AE2FF658 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=es-NI -Dtests.timezone=America/Cordoba -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
e364f5be31555d3704ce4007c470feb3bd9c649b
[repro] git fetch
[repro] git checkout 2c4b78c43fe2e30ef748af34a1daa174d66e29cc

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/contrib/analytics
[repro]   LegacyFieldFacetExtrasCloudTest
[repro]   ValueFacetTest
[repro]solr/core
[repro]   CollectionsAPIDistributedZkTest
[repro] ant compile-test

[...truncated 2577 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.LegacyFieldFacetExtrasCloudTest|*.ValueFacetTest" 
-Dtests.showOutput=onerror  -Dtests.seed=5BF579E5AE2FF658 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.locale=es-NI -Dtests.timezone=America/Cordoba 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII

[...truncated 161 lines...]
[repro] Setting last failure code to 256

[repro] ant compile-test

[...truncated 1329 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.CollectionsAPIDistributedZkTest" -Dtests.showOutput=onerror  
-Dtests.seed=C617D3E20919B295 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=ar-JO -Dtests.timezone=America/Curacao -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[...truncated 158 lines...]
[repro] Failures:
[repro]   0/5 failed: 
org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest
[repro]   0/5 failed: 
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest
[repro]   1/5 failed: org.apache.solr.analytics.facet.ValueFacetTest
[repro] git checkout e364f5be31555d3704ce4007c470feb3bd9c649b

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Resolved] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread Noble Paul (JIRA)


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

Noble Paul resolved SOLR-12015.
---
   Resolution: Fixed
Fix Version/s: 7.4

> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 7.4
>
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 # 2447 - Still Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2447/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.analytics.NoFacetTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([FC71134D1FCD9289]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.analytics.SolrAnalyticsTestCase.setupCollection(SolrAnalyticsTestCase.java:63)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 1856 lines...]
   [junit4] JVM J2: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/build/core/test/temp/junit4-J2-20180323_010543_6212210096214676549800.sysout
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] codec: SimpleText, pf: FSTOrd50, dvf: Memory
   [junit4] <<< JVM J2: EOF 

[...truncated 16125 lines...]
   [junit4] Suite: org.apache.solr.analytics.NoFacetTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/build/contrib/solr-analytics/test/J2/temp/solr.analytics.NoFacetTest_FC71134D1FCD9289-001/init-core-data-001
   [junit4]   2> Mar 23, 2018 2:35:13 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {}, 
docValues:{}, maxPointsInLeafNode=1563, maxMBSortInHeap=5.21017861829709, 
sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@527b9622),
 locale=en, timezone=Pacific/Rarotonga
   [junit4]   2> NOTE: Linux 3.13.0-88-generic amd64/Oracle Corporation 
1.8.0_144 (64-bit)/cpus=4,threads=1,free=266035128,total=318242816
   [junit4]   2> NOTE: All tests run in this JVM: [CastingIntValueStreamTest, 
ConcatFunctionTest, DivideFunctionTest, LegacyFunctionTest, AndFunctionTest, 
GTEFunctionTest, ConstantValueTest, MultFunctionTest, StringFieldsTest, 
CastingAnalyticsValueTest, RoundFunctionTest, BooleanFieldsTest, 
CastingLongValueTest, ExpressionFactoryTest, NoFacetTest]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=NoFacetTest 
-Dtests.seed=FC71134D1FCD9289 -Dtests.multiplier=2

[jira] [Commented] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12015:


Commit 56009132b99472adcdaf47a1ddd61afaa93cf88a in lucene-solr's branch 
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5600913 ]

SOLR-12015: fixed typo in CHANGES.txt


> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12015:


Commit 00ce2d28ef66465bd5425fe72c151d9ffdb52996 in lucene-solr's branch 
refs/heads/branch_7x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=00ce2d2 ]

SOLR-12015: Add support "add-distinct" in AtomicURP so that we can use the 
'add-distict' as a request parameter e.g: 
atomic.add-distict=


> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12015:


Commit e364f5be31555d3704ce4007c470feb3bd9c649b in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e364f5b ]

SOLR-12015: fixed typo in CHANGES.txt


> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread Noble Paul (JIRA)


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

Noble Paul updated SOLR-12015:
--
Description: 
SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, which 
essentially means "add-if-not-present". With that we need to add the 
functionality in AtomicURP too.

sample API:
{code}
http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
{code}

  was:
SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, which 
essentially means "add-if-not-present". With that we need to add the 
functionality in AtomicURP too.

sample API:
{code}
http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
{code}


> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12015:


Commit e340cef68ddfd4b8a5166ddb17da47e8ebe7fa76 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e340cef ]

SOLR-12015: Add support "add-distinct" in AtomicURP so that we can use the 
'add-distict' as a request parameter e.g: 
atomic.add-distict=


> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.3-Windows (32bit/jdk1.8.0_144) - Build # 14 - Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/14/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([D84D28F3E314A75C:11F86A5DEA7361A9]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at org.junit.Assert.assertFalse(Assert.java:79)
at 
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue(TestTriggerIntegration.java:632)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)


FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at

[jira] [Commented] (SOLR-12129) After the core is reloaded, term of the core will not be watched

2018-03-22 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-12129:
-

{{raft-term}} then.  Short & sweet and more specific than {{generation}}

> After the core is reloaded, term of the core will not be watched
> 
>
> Key: SOLR-12129
> URL: https://issues.apache.org/jira/browse/SOLR-12129
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12129.patch
>
>
> After the core is reloaded, term of the core will not be watched.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

2018-03-22 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-11913:
-

You're getting there Tapan!

Typo in test name: testMapEntyrIterators

Now, quoting the description where I mentioned one detail not done...

bq. The default impl can produce a Map.Entry with a getValue that calls through 
to getParams.

Instead I see that you're calling getParams eagerly.  The distinction is that 
callers that only care about certain named params will needlessly pay a cost to 
getParams for parameters that aren't even needed.

BTW try {{ant precommit}}.  Hopefully it'll show you that you need to use 
{{\@Override}}

Can you please try updating some callers of getParameterNamesIterator to see 
which of those would be good candidates to renovate to use the Java 5 for-each 
style?  Perhaps do everything but Solr "core" (i.e. just SolrJ + contribs) 
which can be tested in less time than running "ant test" on everything.  
Although you did add a unit test which is nice, there's nothing like real-world 
usage through other code that needs to use it.

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12015) Add support for "add-distinct" in AtomicUpdateProcessorFactory

2018-03-22 Thread Noble Paul (JIRA)


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

Noble Paul reassigned SOLR-12015:
-

Assignee: Noble Paul

> Add support for "add-distinct" in AtomicUpdateProcessorFactory
> --
>
> Key: SOLR-12015
> URL: https://issues.apache.org/jira/browse/SOLR-12015
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Reporter: Amrit Sarkar
>Assignee: Noble Paul
>Priority: Minor
> Attachments: SOLR-12015.patch, SOLR-12015.patch
>
>
> SOLR-11267 is introducing new mode of atomic operation: {{add-distinct}}, 
> which essentially means "add-if-not-present". With that we need to add the 
> functionality in AtomicURP too.
> sample API:
> {code}
> http://SOLR_HOST:SOLR_PORT/solr/COLLECTION_NAME/update?processor=atomic=add-distinct
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls

2018-03-22 Thread Steve Rowe (JIRA)


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

Steve Rowe edited comment on SOLR-11551 at 3/23/18 1:48 AM:


Thanks for making the try-catch change, looks good.

+1 on the rest of the new patch, except for three small things I noticed after 
I took a closer look at the patch: 

1. in {{MergeIndexesOp}}, you changed the line {{if (core != null) \{}} to {{if 
(core == null) return;}} (line 65).  This could happen earlier, and 
short-circuit some unnecessary collection creations, right after where the core 
is obtained, on line 55.

{code:java}
51:  @Override
52:  public void execute(CoreAdminHandler.CallInfo it) throws Exception {
53:SolrParams params = it.req.getParams();
54:String cname = params.required().get(CoreAdminParams.CORE);
55:SolrCore core = it.handler.coreContainer.getCore(cname);
56:SolrQueryRequest wrappedReq = null;
57:
58:List sourceCores = Lists.newArrayList();
59:List searchers = Lists.newArrayList();
60:// stores readers created from indexDir param values
61:List readersToBeClosed = Lists.newArrayList();
62:Map dirsToBeReleased = new HashMap<>();
63:
64:
65:if (core == null) return;
{code}

2. {{CoreAdminOperation.execute()}} no longer needs to declare {{throws 
Exception}} since it always wraps any encountered exceptions with 
{{SolrException}}, which is unchecked.  As a result, all implementing classes 
should also remove this declaration.  (Note that this detail was included in 
this issue's description.)

3. Copy/paste-o's in {{CoreAdminOperationTest.java}}:

3.a. Should call {{REJOINLEADERELECTION_OP.execute()}} instead of 
{{REQUESTSTATUS_OP.execute()}} (and the failure message should be adjusted too):

{code:java}
  public void testRejoinLeaderElectionUnexpectedFailuresResultIn500Exception() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.REQUESTSTATUS_OP.execute(callInfo);
  fail("Expected request-status execution to fail with exception.");
{code}

3.b. failure message prints "core-unload" instead of "core-reload":

{code}
  public void testReloadUnexpectedFailuresResultIn500SolrException() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.RELOAD_OP.execute(callInfo);
  fail("Expected core-unload execution to fail with exception.");
{code}

3.c. failure message prints "request-sync" instead of "request-buffer-updates":

{code}
  public void testRequestBufferUpdatesUnexpectedFailuresResultIn500Exception() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.REQUESTBUFFERUPDATES_OP.execute(callInfo);
  fail("Expected request-sync execution to fail with exception.");
{code}

3.d. failure message prints "request-apply-updates" instead of "request-status":

{code}
 public void testRequestStatusMissingRequestIdParamResultsIn400SolrException() {
whenCoreAdminOpHasParams(Maps.newHashMap());

try {
  CoreAdminOperation.REQUESTSTATUS_OP.execute(callInfo);
  fail("Expected request-apply-updates execution to fail when no 
'requestid' param present");
{code}


was (Author: steve_rowe):
Thanks for making the try-catch change, looks good.

+1 on the rest of the new patch, except for three small things I noticed after 
I took a closer look at the patch: 

1. in {{MergeIndexesOp}}, you changed the line {{if (core != null) \{}} to {{if 
(core == null) return;}} (line 65).  This could happen earlier, and 
short-circuit some unnecessary collection creations, right after where the core 
is obtained, on line 55.

{code:java}
51:  @Override
52:  public void execute(CoreAdminHandler.CallInfo it) throws Exception {
53:SolrParams params = it.req.getParams();
54:String cname = params.required().get(CoreAdminParams.CORE);
55:SolrCore core = it.handler.coreContainer.getCore(cname);
56:SolrQueryRequest wrappedReq = null;
57:
58:List sourceCores = Lists.newArrayList();
59:List searchers = Lists.newArrayList();
60:// stores readers created from indexDir param values
61:List readersToBeClosed = Lists.newArrayList();
62:Map dirsToBeReleased = new HashMap<>();
63:
64:
65:if (core == null) return;
{code}

2. {{CoreAdminOperation.execute() no longer needs to declare {{throws 
Exception}} since it always wraps any encountered exceptions with 
{{SolrException}}, which is unchecked.  As a result, all implementing classes 
should also remove this declaration.  (Note that this detail was included in 
this issue's description.)

3. Copy/paste-o's in {{CoreAdminOperationTest.java}}:

[jira] [Commented] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls

2018-03-22 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on SOLR-11551:
---

Thanks for making the try-catch change, looks good.

+1 on the rest of the new patch, except for three small things I noticed after 
I took a closer look at the patch: 

1. in {{MergeIndexesOp}}, you changed the line {{if (core != null) \{}} to {{if 
(core == null) return;}} (line 65).  This could happen earlier, and 
short-circuit some unnecessary collection creations, right after where the core 
is obtained, on line 55.

{code:java}
51:  @Override
52:  public void execute(CoreAdminHandler.CallInfo it) throws Exception {
53:SolrParams params = it.req.getParams();
54:String cname = params.required().get(CoreAdminParams.CORE);
55:SolrCore core = it.handler.coreContainer.getCore(cname);
56:SolrQueryRequest wrappedReq = null;
57:
58:List sourceCores = Lists.newArrayList();
59:List searchers = Lists.newArrayList();
60:// stores readers created from indexDir param values
61:List readersToBeClosed = Lists.newArrayList();
62:Map dirsToBeReleased = new HashMap<>();
63:
64:
65:if (core == null) return;
{code}

2. {{CoreAdminOperation.execute() no longer needs to declare {{throws 
Exception}} since it always wraps any encountered exceptions with 
{{SolrException}}, which is unchecked.  As a result, all implementing classes 
should also remove this declaration.  (Note that this detail was included in 
this issue's description.)

3. Copy/paste-o's in {{CoreAdminOperationTest.java}}:

3.a. Should call {{REJOINLEADERELECTION_OP.execute()}} instead of 
{{REQUESTSTATUS_OP.execute()}} (and the failure message should be adjusted too):

{code:java}
  public void testRejoinLeaderElectionUnexpectedFailuresResultIn500Exception() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.REQUESTSTATUS_OP.execute(callInfo);
  fail("Expected request-status execution to fail with exception.");
{code}

3.b. failure message prints "core-unload" instead of "core-reload":

{code}
  public void testReloadUnexpectedFailuresResultIn500SolrException() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.RELOAD_OP.execute(callInfo);
  fail("Expected core-unload execution to fail with exception.");
{code}

3.c. failure message prints "request-sync" instead of "request-buffer-updates":

{code}
  public void testRequestBufferUpdatesUnexpectedFailuresResultIn500Exception() {
final Throwable cause = new NullPointerException();
whenUnexpectedErrorOccursDuringCoreAdminOp(cause);

try {
  CoreAdminOperation.REQUESTBUFFERUPDATES_OP.execute(callInfo);
  fail("Expected request-sync execution to fail with exception.");
{code}

3.d. failure message prints "request-apply-updates" instead of "request-status":

{code}
 public void testRequestStatusMissingRequestIdParamResultsIn400SolrException() {
whenCoreAdminOpHasParams(Maps.newHashMap());

try {
  CoreAdminOperation.REQUESTSTATUS_OP.execute(callInfo);
  fail("Expected request-apply-updates execution to fail when no 
'requestid' param present");
{code}

> Standardize response codes and success/failure determination for core-admin 
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-11551.patch, SOLR-11551.patch, SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core 
> admin api's first.
> If we are relying on response codes I think we should make the following 
> change and fix all the APIs 
> {code}
>   interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
>   }
> {code}
> To
> {code}
>   interface CoreAdminOp {
> /**
>  *
>  * @param it request/response object
>  *
>  * If the request is invalid throw a SolrException with 
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
>  * If the execution of the command fails throw a SolrException with 
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
>  * Add a "error-message" key to the response object with the exception ( 
> this part should be done at the caller of this method so that each operation 
> doesn't need to do the same thing )
>  */
> void execute(CallInfo it);
>   }
> {code}
> cc [~gerlowskija]



--
This message

[jira] [Commented] (SOLR-12129) After the core is reloaded, term of the core will not be watched

2018-03-22 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-12129:
-

Hi David, I borrowed that terminology from Raft paper. But you are right, the 
people are confused about that. Steve gave me a hint about changing it to 
generation.

BTW: LIR-Term seems not a good name because it sticks to LIR, but term of a 
replica can be used outside of LIR.

> After the core is reloaded, term of the core will not be watched
> 
>
> Key: SOLR-12129
> URL: https://issues.apache.org/jira/browse/SOLR-12129
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12129.patch
>
>
> After the core is reloaded, term of the core will not be watched.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

2018-03-22 Thread Tapan Vaishnav (JIRA)


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

Tapan Vaishnav commented on SOLR-11913:
---

{quote}1. When uploading updated patches, please use an identical filename. 
JIRA tracks revisions provided that the file name hasn't changed.
{quote}
I see.
{quote}Though you did provide a method getMapEntryIteretor which should be 
renamed to iterator.
{quote}
Done.

Please have a look, apologies for making you review again n again.

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11913) SolrParams ought to implement Iterable<Map.Entry<String,String[]>>

2018-03-22 Thread Tapan Vaishnav (JIRA)


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

Tapan Vaishnav updated SOLR-11913:
--
Attachment: SOLR-11913.patch

> SolrParams ought to implement Iterable>
> --
>
> Key: SOLR-11913
> URL: https://issues.apache.org/jira/browse/SOLR-11913
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Priority: Minor
>  Labels: newdev
> Attachments: SOLR-11913.patch, SOLR-11913.patch, SOLR-11913_v2.patch
>
>
> SolrJ ought to implement {{Iterable>}} so that 
> it's easier to iterate on it, either using Java 5 for-each style, or Java 8 
> streams.  The implementation on ModifiableSolrParams can delegate through to 
> the underlying LinkedHashMap entry set.  The default impl can produce a 
> Map.Entry with a getValue that calls through to getParams.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 319 - Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-repro/319/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/180/consoleText

[repro] Revision: bd6cf168e0e129fa22545a7f614b2b146bd5f202

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.method=test -Dtests.seed=2AD49B74942418F5 -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=he -Dtests.timezone=Europe/Kaliningrad -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=RestartWhileUpdatingTest 
-Dtests.seed=2AD49B74942418F5 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=he -Dtests.timezone=Europe/Kaliningrad -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
ea12b5fd225a6af32cba55e589cdca22e606fc0e
[repro] git fetch
[repro] git checkout bd6cf168e0e129fa22545a7f614b2b146bd5f202

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   RestartWhileUpdatingTest
[repro] ant compile-test

[...truncated 3314 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.RestartWhileUpdatingTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=2AD49B74942418F5 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=he -Dtests.timezone=Europe/Kaliningrad -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[...truncated 83233 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.RestartWhileUpdatingTest
[repro] git checkout ea12b5fd225a6af32cba55e589cdca22e606fc0e

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[GitHub] lucene-solr issue #313: SOLR-11924: Added a way to create collection set wat...

2018-03-22 Thread dennisgove

Github user dennisgove commented on the issue:

https://github.com/apache/lucene-solr/pull/313
  
Overall I think this is a good idea.


---

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

[GitHub] lucene-solr pull request #313: SOLR-11924: Added a way to create collection ...

2018-03-22 Thread dennisgove

Github user dennisgove commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/313#discussion_r176611998
  
--- Diff: 
solr/solrj/src/java/org/apache/solr/common/cloud/CollectionSetWatcher.java ---
@@ -0,0 +1,41 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud;
+
+import java.util.Set;
+
+/**
+ * Callback registered with {@link 
ZkStateReader#registerCollectionSetWatcher(CollectionSetWatcher)}
+ * and called whenever the cluster's collection set changes.
+ */
+public interface CollectionSetWatcher {
--- End diff --

What is a `CollectionSet`? It seems that this is watching collection 
states. Is `CollectionSetWatcher` the best name for this interface?


---

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

[GitHub] lucene-solr pull request #313: SOLR-11924: Added a way to create collection ...

2018-03-22 Thread dennisgove

Github user dennisgove commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/313#discussion_r176611511
  
--- Diff: 
solr/solrj/src/java/org/apache/solr/common/cloud/CollectionSetWatcher.java ---
@@ -0,0 +1,41 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.common.cloud;
+
+import java.util.Set;
+
+/**
+ * Callback registered with {@link 
ZkStateReader#registerCollectionSetWatcher(CollectionSetWatcher)}
+ * and called whenever the cluster's collection set changes.
+ */
+public interface CollectionSetWatcher {
+
+  /**
+   * Called when a collection is created, a collection is deleted or a 
watched collection's state changes.
+   *
+   * Note that, due to the way Zookeeper watchers are implemented, a 
single call may be
+   * the result of several collection set changes. Also, multiple calls to 
this method can be made
+   * with the same colllection set, ie. without any new updates.
+   *
+   * @param collections   the set of collections
+   *
+   * @return true if the watcher should be removed
--- End diff --

What's the case here for removing a watcher, and why is `true` the best 
option? I'm not totally against it, but a boolean seems an odd choice here. If 
boolean is used would returning `true` to continue watching be a better choice?


---

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

[jira] [Commented] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls

2018-03-22 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski commented on SOLR-11551:


[~steve_rowe] mentioned to me in a discussion offline that the enveloping 
{{try-catch}} blocks in each of these CoreAdminOp implementations can be pulled 
into {{CoreAdminOperation.execute()}}, to cut down on duplication and really 
shrink this patch.  I'd considered this before, but avoided it since the 
exception messages aren't quite the same.  But Steve suggested using the enum 
name to generate the error message.

Recent patch takes this suggestion into account (thanks Steve!).

Tests and precommit pass.  Will commit in a day or so unless I get anymore 
feedback.

> Standardize response codes and success/failure determination for core-admin 
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-11551.patch, SOLR-11551.patch, SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core 
> admin api's first.
> If we are relying on response codes I think we should make the following 
> change and fix all the APIs 
> {code}
>   interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
>   }
> {code}
> To
> {code}
>   interface CoreAdminOp {
> /**
>  *
>  * @param it request/response object
>  *
>  * If the request is invalid throw a SolrException with 
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
>  * If the execution of the command fails throw a SolrException with 
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
>  * Add a "error-message" key to the response object with the exception ( 
> this part should be done at the caller of this method so that each operation 
> doesn't need to do the same thing )
>  */
> void execute(CallInfo it);
>   }
> {code}
> cc [~gerlowskija]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls

2018-03-22 Thread Jason Gerlowski (JIRA)


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

Jason Gerlowski updated SOLR-11551:
---
Attachment: SOLR-11551.patch

> Standardize response codes and success/failure determination for core-admin 
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-11551.patch, SOLR-11551.patch, SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core 
> admin api's first.
> If we are relying on response codes I think we should make the following 
> change and fix all the APIs 
> {code}
>   interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
>   }
> {code}
> To
> {code}
>   interface CoreAdminOp {
> /**
>  *
>  * @param it request/response object
>  *
>  * If the request is invalid throw a SolrException with 
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
>  * If the execution of the command fails throw a SolrException with 
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
>  * Add a "error-message" key to the response object with the exception ( 
> this part should be done at the caller of this method so that each operation 
> doesn't need to do the same thing )
>  */
> void execute(CallInfo it);
>   }
> {code}
> cc [~gerlowskija]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12087) Deleting replicas sometimes fails and causes the replicas to exist in the down state

2018-03-22 Thread Lucene/Solr QA (JIRA)


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

Lucene/Solr QA commented on SOLR-12087:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  5s{color} 
| {color:red} SOLR-12087 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help. 
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12087 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12915636/SOLR-12087.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/12/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Deleting replicas sometimes fails and causes the replicas to exist in the 
> down state
> 
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Assignee: Cao Manh Dat
>Priority: Critical
> Attachments: SOLR-12087.patch, SOLR-12087.patch, SOLR-12087.patch, 
> SOLR-12087.test.patch, Screen Shot 2018-03-16 at 11.50.32 AM.png
>
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> This also occurs when trying to move replicas, since that move is an add and 
> delete.
> Some more information regarding this issue; when the MOVEREPLICA command is 
> issued, the new replica is created successfully but the replica to be deleted 
> fails to be removed from state.json (the core is deleted though) and we see 
> two logs spammed.
>  # The node containing the leader replica continually (read every second) 
> attempts to initiate recovery on the replica and fails to do so because the 
> core does not exist. As a result it continually publishes a down state for 
> the replica to zookeeper.
>  # The deleted replica node spams that it cannot locate the core because it's 
> been deleted.
> During this period of time, we see an increase in ZK network connectivity 
> overall, until the replica is finally deleted (spamming DELETEREPLICA on the 
> shard until its removed from the state)
> My guess is there's two issues at hand here:
>  # The leader continually attempts to recover a downed replica that is 
> unrecoverable because the core does not exist.
>  # The replica to be deleted is having trouble being deleted from state.json 
> in ZK.
> This is mostly consistent for my use case. I'm running 7.2.1 with 66 nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 315 - Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-repro/315/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/17/consoleText

[repro] Revision: 2c4b78c43fe2e30ef748af34a1daa174d66e29cc

[repro] Repro line:  ant test  -Dtestcase=AtomicUpdateProcessorFactoryTest 
-Dtests.method=testMultipleThreads -Dtests.seed=C92F345F45EBA322 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=no-NO -Dtests.timezone=Etc/GMT+8 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestTlogReplica 
-Dtests.method=testRecovery -Dtests.seed=C92F345F45EBA322 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-US 
-Dtests.timezone=Etc/GMT-14 -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
ea12b5fd225a6af32cba55e589cdca22e606fc0e
[repro] git fetch
[repro] git checkout 2c4b78c43fe2e30ef748af34a1daa174d66e29cc

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   AtomicUpdateProcessorFactoryTest
[repro]   TestTlogReplica
[repro] ant compile-test

[...truncated 3296 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.AtomicUpdateProcessorFactoryTest|*.TestTlogReplica" 
-Dtests.showOutput=onerror  -Dtests.seed=C92F345F45EBA322 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=no-NO 
-Dtests.timezone=Etc/GMT+8 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

[...truncated 17844 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   2/5 failed: org.apache.solr.cloud.TestTlogReplica
[repro]   2/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest
[repro] git checkout ea12b5fd225a6af32cba55e589cdca22e606fc0e

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[JENKINS] Lucene-Solr-Tests-7.3 - Build # 25 - Unstable

2018-03-22 Thread Apache Jenkins Server

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 76, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

Re: Solr JSON.Facet range over function values

2018-03-22 Thread Yonik Seeley

On Thu, Mar 22, 2018 at 2:47 PM, Mikhail Khludnev  wrote:
> Hello,
>
> What do you think about extending JSON.Range facet with "func" parameter?

Yep, it's been on my roadmap... not sure if an explicit JIRA has been
opened though.
It's related to code to lookup by document (using docValues or
function) rather than using range queries to form buckets:
SOLR-9868 RangeFacet : Use DocValues for accs and docSet collection
instead of RangeQuery
SOLR-10528Use docvalue for range faceting in JSON facet API

Also somewhat related to:
SOLR-11765 Ability to Facet on a Function

> Since range supports different types, it also needs "funcType" parameter,

Or rather, types should be part of functions (i.e. you should be able
to ask a function the type it produces).  Many places need this.

> which will be looked up in schema.

? I don't understand that part.

-Yonik

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

[jira] [Updated] (SOLR-12120) New plugin type AuditLoggerPlugin

2018-03-22 Thread JIRA


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

Jan Høydahl updated SOLR-12120:
---
Description: 
Solr needs a well defined plugin point to implement audit logging 
functionality, which is independent from whatever {{AuthenticationPlugin}} or 
{{AuthorizationPlugin}} are in use at the time.

It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
could be configured in solr.xml or it could be a third type of plugin defined 
in {{security.json}}, i.e.
{code:java}
{
  "authentication" : { "class" : ... },
  "authorization" : { "class" : ... },
  "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
}
{code}
We could then instrument SolrDispatchFilter to the audit plugin with an 
AuditEvent at important points such as successful authentication:
{code:java}
auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED, request)); 
{code}
 We will mark the impl as {{@lucene.experimental}} in the first release to let 
it settle as people write their own plugin implementations.

  was:
Solr needs a well defined plugin point to implement audit logging 
functionality, which is independent from whatever {{AuthenticationPlugin}} or 
{{AuthorizationPlugin}} are in use at the time.

It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
could be configured in solr.xml or it could be a third type of plugin defined 
in {{security.json}}, i.e.
{code}
{
  "authentication" : { "class" : ... },
  "authorization" : { "class" : ... },
  "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
}
{code}
We could then instrument SolrDispatchFilter to the audit plugin with an 
AuditEvent at important points such as successful authentication:
{code:java}
auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED, request)); 
{code}
 

We will mark the impl as {{@lucene.experimental}} in the first release to let 
it settle as people write their own plugin implementations.


> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Solr needs a well defined plugin point to implement audit logging 
> functionality, which is independent from whatever {{AuthenticationPlugin}} or 
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
> could be configured in solr.xml or it could be a third type of plugin defined 
> in {{security.json}}, i.e.
> {code:java}
> {
>   "authentication" : { "class" : ... },
>   "authorization" : { "class" : ... },
>   "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an 
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED, 
> request)); 
> {code}
>  We will mark the impl as {{@lucene.experimental}} in the first release to 
> let it settle as people write their own plugin implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12120) New plugin type AuditLoggerPlugin

2018-03-22 Thread JIRA


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

Jan Høydahl updated SOLR-12120:
---
Description: 
Solr needs a well defined plugin point to implement audit logging 
functionality, which is independent from whatever {{AuthenticationPlugin}} or 
{{AuthorizationPlugin}} are in use at the time.

It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
could be configured in solr.xml or it could be a third type of plugin defined 
in {{security.json}}, i.e.
{code}
{
  "authentication" : { "class" : ... },
  "authorization" : { "class" : ... },
  "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
}
{code}
We could then instrument SolrDispatchFilter to the audit plugin with an 
AuditEvent at important points such as successful authentication:
{code:java}
auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED, request)); 
{code}
 

We will mark the impl as {{@lucene.experimental}} in the first release to let 
it settle as people write their own plugin implementations.

  was:
Solr needs a well defined plugin point to implement audit logging 
functionality, which is independent from whatever {{AuthenticationPlugin}} or 
{{AuthorizationPlugin}} are in use at the time.

It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
could be configured in solr.xml or it could be a third type of plugin defined 
in {{security.json}}, i.e.
{code:java}
"authentication" : { "class" : ... }
"authorization" : { "class" : ... }
"auditlogging" : { "class" : "x.y.MyAuditLogger", ... }{code}
We could then instrument SolrDispatchFilter to call 
{{auditlogger.authenticationFailed(request, response, msg)}} if auth failed and 
the request is going to be aborted, and likewise HttpSolrCall could call 
relevant methods when a final autz decision is made, e.g. 
{{auditlogger.notAuthorized(authCtx, request, response)}}, and if all is OK, it 
could call {{auditlogger.ok()}} for  success logging.

If no auditlogger is explicitly configured, we can fallback to a default 
{{SolrLogAuditLogger}} that logs to standard Solr log, or we could setup log4j 
to output a new {{logs/audit.log}} file.


> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Solr needs a well defined plugin point to implement audit logging 
> functionality, which is independent from whatever {{AuthenticationPlugin}} or 
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
> could be configured in solr.xml or it could be a third type of plugin defined 
> in {{security.json}}, i.e.
> {code}
> {
>   "authentication" : { "class" : ... },
>   "authorization" : { "class" : ... },
>   "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an 
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED, 
> request)); 
> {code}
>  
> We will mark the impl as {{@lucene.experimental}} in the first release to let 
> it settle as people write their own plugin implementations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12120) New plugin type AuditLoggerPlugin

2018-03-22 Thread JIRA


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

Jan Høydahl reassigned SOLR-12120:
--

Assignee: Jan Høydahl

> New plugin type AuditLoggerPlugin
> -
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
>
> Solr needs a well defined plugin point to implement audit logging 
> functionality, which is independent from whatever {{AuthenticationPlugin}} or 
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It 
> could be configured in solr.xml or it could be a third type of plugin defined 
> in {{security.json}}, i.e.
> {code:java}
> "authentication" : { "class" : ... }
> "authorization" : { "class" : ... }
> "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }{code}
> We could then instrument SolrDispatchFilter to call 
> {{auditlogger.authenticationFailed(request, response, msg)}} if auth failed 
> and the request is going to be aborted, and likewise HttpSolrCall could call 
> relevant methods when a final autz decision is made, e.g. 
> {{auditlogger.notAuthorized(authCtx, request, response)}}, and if all is OK, 
> it could call {{auditlogger.ok()}} for  success logging.
> If no auditlogger is explicitly configured, we can fallback to a default 
> {{SolrLogAuditLogger}} that logs to standard Solr log, or we could setup 
> log4j to output a new {{logs/audit.log}} file.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11876) InPlace update fails when resolving from Tlog if schema has a required field

2018-03-22 Thread Lucene/Solr QA (JIRA)


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

Lucene/Solr QA commented on SOLR-11876:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 15s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 49m  5s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m  0s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.update.processor.AtomicUpdateProcessorFactoryTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11876 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12906893/SOLR-11876.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / ea12b5f |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/11/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/11/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/11/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> InPlace update fails when resolving from Tlog if schema has a required field
> 
>
> Key: SOLR-11876
> URL: https://issues.apache.org/jira/browse/SOLR-11876
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
> Environment: OSX High Sierra
> java version "1.8.0_152"
> Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
>Reporter: Justin Deoliveira
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Attachments: SOLR-11876.patch
>
>
> The situation is doing an in place update of a non-indexed/stored numeric doc 
> values field multiple times in fast succession. The schema 
> has a required field ("name") in it. On the third update request the update 
> fails complaining "missing required field: name". It seems this happens 
> when the update document is being resolved from from the TLog.
> To reproduce:
> 1. Setup a schema that has:
>     - A required field other than the uniquekey field, in my case it's called 
> "name"
>     - A numeric doc values field suitable for in place update (non-indexed, 
> non-stored), in my case it's called "likes"
> 2. Execute an in place update of the document a few times in fast succession:
> {noformat}
> for i in `seq 10`; do
> curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/core1/update' --data-binary '
> [{
>  "id": "1",
>  "likes": { "inc": 1 }
> }]'
> done{noformat}
> The resulting stack trace:
> {noformat}
> 2018-01-19 21:27:26.644 ERROR (qtp1873653341-14) [ x:core1] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: [doc=1] 
> missing required field: name
>  at 
> org.apache.solr.update.DocumentBuilder.toDocument(DocumentBuilder.java:233)
>

Re: [JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 180 - Failure

2018-03-22 Thread Dawid Weiss

> ant test  -Dtestcase=ConfusionMatrixGeneratorTest 
> -Dtests.method=testGetConfusionMatrixWithSNB -Dtests.seed=3852F218DBFAD982 
> -Dtests.multiplier=2 -Dtests.locale=en-IN -Dtests.timezone=Etc/UCT 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8

Does not reproduce for me on master or on this particular build's commit.
Dawid

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

Solr JSON.Facet range over function values

2018-03-22 Thread Mikhail Khludnev

Hello,

What do you think about extending JSON.Range facet with "func" parameter?
Since range supports different types, it also needs "funcType" parameter,
which will be looked up in schema.

-- 
Sincerely yours
Mikhail Khludnev

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1509 - Still Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1509/

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressLiveNodes.testStress

Error Message:
iter3203: [127.0.0.1:42700_solr, thrasher-T3202_0-0, thrasher-T3202_0-1, 
thrasher-T3202_0-2, thrasher-T3202_1-0, thrasher-T3202_1-1, thrasher-T3202_1-2, 
thrasher-T3202_2-0, thrasher-T3202_2-1, thrasher-T3202_2-2] expected:<1> but 
was:<10>

Stack Trace:
java.lang.AssertionError: iter3203: [127.0.0.1:42700_solr, thrasher-T3202_0-0, 
thrasher-T3202_0-1, thrasher-T3202_0-2, thrasher-T3202_1-0, thrasher-T3202_1-1, 
thrasher-T3202_1-2, thrasher-T3202_2-0, thrasher-T3202_2-1, thrasher-T3202_2-2] 
expected:<1> but was:<10>
at 
__randomizedtesting.SeedInfo.seed([B3BEE5A710176C65:A6A5986693E0941E]: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.apache.solr.cloud.TestStressLiveNodes.testStress(TestStressLiveNodes.java:140)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Commented] (SOLR-12129) After the core is reloaded, term of the core will not be watched

2018-03-22 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-12129:
-

Dat, your use of the word "term" is non-obvious to me.  Can you qualify your 
uses of it somehow so we don't confuse it with a Lucene "term", which has a lot 
more history on this project?  Perhaps LIR-Term?  It would also make searching 
for it easier :-)

> After the core is reloaded, term of the core will not be watched
> 
>
> Key: SOLR-12129
> URL: https://issues.apache.org/jira/browse/SOLR-12129
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12129.patch
>
>
> After the core is reloaded, term of the core will not be watched.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12126) EmbeddedSolrServer don't pass solrconfig to SolrRequestParsers

2018-03-22 Thread David Smiley (JIRA)


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

David Smiley reassigned SOLR-12126:
---

Assignee: David Smiley

> EmbeddedSolrServer don't pass solrconfig to SolrRequestParsers
> --
>
> Key: SOLR-12126
> URL: https://issues.apache.org/jira/browse/SOLR-12126
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 7.2
>Reporter: Dmitry Tikhonov
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.3
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Starting from solr 7.2 there is stream.body with default false, but you can 
> configure it via solrconfig.xml except one case - EmbeddedSolrServer. In this 
> case SolrRequestParsers always got null instead of solr core config. That 
> means you can't configure some parameters in case of EmbeddedSolrServer.
> {code:java}
> public EmbeddedSolrServer(CoreContainer coreContainer, String coreName) {
>   if (coreContainer == null) {
> throw new NullPointerException("CoreContainer instance required");
>   }
>   if (Strings.isNullOrEmpty(coreName))
> throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Core name 
> cannot be empty");
>   this.coreContainer = coreContainer;
>   this.coreName = coreName;
>   _parser = new SolrRequestParsers(null);
> }{code}
>  
>  Here is a pull request - [https://github.com/apache/lucene-solr/pull/340] , 
> with some basic tests.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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/jdk-9) - Build # 4517 - Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4517/
Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStopPoll

Error Message:
expected:<499> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<499> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([D43BA5FEC8063E6F:C718DBF21EEFF95A]: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.handler.TestReplicationHandler.doTestStopPoll(TestReplicationHandler.java:593)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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 1856 lines...]
   [junit4] JVM J1: stdout was not empty, see:

[jira] [Commented] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-12134:
-

{quote}{{bare-bones-html-validation}} will catch 99% of the "content mistakes" 
in the ref-guide, so that's probably good enough for precommit.
{quote}

...patch updated to make this change.

> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-12134:

Attachment: SOLR-12134.patch

> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance

2018-03-22 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar commented on SOLR-10513:
-

We faced the same issue for the configuring multiple spell checkers, 
{{FileBasedSolrSpellChecker}} specifically. Uploaded patch, tests awaited.

> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
> 
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 5.5
>
> Attachments: SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
>   if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
>   } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
>   }
> } catch (UnsupportedOperationException uoe) {
>   // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by 
> references. So if you are using 2 or more spellcheckers with same distance 
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to 
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method. 
> This does not solve the problem yet, because the *default equals* method 
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .  
> Moreover, Some check of similar sorts should also be in the init method. So 
> that user does not have to wait for this error during query time. If the 
> spellcheck components have been added *solrconfig.xml* , it should throw 
> error during core-reload itself.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance

2018-03-22 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar updated SOLR-10513:

Attachment: SOLR-10513.patch

> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
> 
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 5.5
>
> Attachments: SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
>   if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
>   } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
>   }
> } catch (UnsupportedOperationException uoe) {
>   // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by 
> references. So if you are using 2 or more spellcheckers with same distance 
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to 
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method. 
> This does not solve the problem yet, because the *default equals* method 
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .  
> Moreover, Some check of similar sorts should also be in the init method. So 
> that user does not have to wait for this error during query time. If the 
> spellcheck components have been added *solrconfig.xml* , it should throw 
> error during core-reload itself.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance

2018-03-22 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar updated SOLR-10513:

Attachment: (was: SOLR-10513.patch)

> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
> 
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 5.5
>
> Attachments: SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
>   if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
>   } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
>   }
> } catch (UnsupportedOperationException uoe) {
>   // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by 
> references. So if you are using 2 or more spellcheckers with same distance 
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to 
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method. 
> This does not solve the problem yet, because the *default equals* method 
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .  
> Moreover, Some check of similar sorts should also be in the init method. So 
> that user does not have to wait for this error during query time. If the 
> spellcheck components have been added *solrconfig.xml* , it should throw 
> error during core-reload itself.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-10513) CLONE - ConjunctionSolrSpellChecker wrong check for same string distance

2018-03-22 Thread Amrit Sarkar (JIRA)


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

Amrit Sarkar updated SOLR-10513:

Attachment: SOLR-10513.patch

> CLONE - ConjunctionSolrSpellChecker wrong check for same string distance
> 
>
> Key: SOLR-10513
> URL: https://issues.apache.org/jira/browse/SOLR-10513
> Project: Solr
>  Issue Type: Bug
>  Components: spellchecker
>Affects Versions: 4.9
>Reporter: Abhishek Kumar Singh
>Assignee: James Dyer
>Priority: Major
> Fix For: 5.5
>
> Attachments: SOLR-10513.patch
>
>
> See ConjunctionSolrSpellChecker.java
> try {
>   if (stringDistance == null) {
> stringDistance = checker.getStringDistance();
>   } else if (stringDistance != checker.getStringDistance()) {
> throw new IllegalArgumentException(
> "All checkers need to use the same StringDistance.");
>   }
> } catch (UnsupportedOperationException uoe) {
>   // ignore
> }
> In line stringDistance != checker.getStringDistance() there is comparing by 
> references. So if you are using 2 or more spellcheckers with same distance 
> algorithm, exception will be thrown anyway.
> *Update:* As of Solr 6.5, this has been changed to 
> *stringDistance.equals(checker.getStringDistance())* .
> However, *LuceneLevenshteinDistance* does not even override equals method. 
> This does not solve the problem yet, because the *default equals* method 
> anyway compares references.
> Hence unable to use *FileBasedSolrSpellChecker* .  
> Moreover, Some check of similar sorts should also be in the init method. So 
> that user does not have to wait for this error during query time. If the 
> spellcheck components have been added *solrconfig.xml* , it should throw 
> error during core-reload itself.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12085) IndexFetcher does not honor SolrDeletionPolicy

2018-03-22 Thread Karishma Agrawal (JIRA)


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

Karishma Agrawal updated SOLR-12085:

Affects Version/s: 7.1
   7.2

> IndexFetcher does not honor SolrDeletionPolicy
> --
>
> Key: SOLR-12085
> URL: https://issues.apache.org/jira/browse/SOLR-12085
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Affects Versions: 5.4.1, 7.1, 7.2
>Reporter: Karishma Agrawal
>Priority: Major
>
> Index Fetcher is not in sync with Solr Deletion Policy.
> If we set the SolrDeletionPolicy to retain more than 1 commit - i.e. 
> maxCommitsToKeep > 1. Then slaves get stuck in alternate full replication. 
> This happens because within IndexFetcher, there is a check for unusedFiles - 
> hasUnusedFile, which takes IndexDirectory and latest commit as parameters. If 
> there are files unrelated to latest commit in the index dir then this method 
> returns true, and SolrDeletionPolicy is invoked. However there are no pending 
> files to delete according to the index deletion policy since that is aware of 
> other valid commits, and no action is taken. Once all the retries are 
> exhausted, index fetcher sets fullreplication to true.  
> Possible solutions: 
>  # remove the check for hasUnusedFile completely. We invoke 
> IndexWriter#deleteUnusedFiles and move on.
>  # Add another method in IndexFileDeleter (Lucene) which returns number of 
> pending deleted files. We can replace the IndexFetcher#hasUnusedFile method 
> with this.
>  # Keep track of unused files in IndexDeletionPolicyWrapper.     
> A variation of this bug was previously noted in 
> https://issues.apache.org/jira/browse/SOLR-9278    



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-12134:
-

Wild speculation w/o knowing much about Yetus...

* given that it tested the nocommit patch, it makes total sense that "Validate 
source patterns " would fail – because that patch explicitly includes the words 
"nocommit" in the modifications.
* maybe "Validate source patterns" is a configured prereq for "Validate ref 
guide" so the failure of the former ment that it didn't run the later?
** that's my uneducated  interpretation from the console output of that jenkins 
- we see it saying it's going to "Validate source patterns" on personality "." 
then we see it saying it's going to run "Validate ref guide" on personality 
"solr/solr-ref-guide" but w/o doing anything complains that "Validate source 
patterns" failed.
 
...in any case, should probably move this conversation to a Yetus specific jira?


> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 514 - Still Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/514/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=37791850

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=37791850
at 
__randomizedtesting.SeedInfo.seed([E0DC925CB02B3D4A:D8B0E17924FB9F0C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:48)
at 
org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)


FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180322162914435, index.20180322162914615, index.properties, 
replication.properties,

Re: InetAddressPoint support in Solr?

2018-03-22 Thread David Smiley

Please ask on the solr-user list.  This list is for internal development.

On Thu, Mar 22, 2018 at 11:11 AM Mike Cooper 
wrote:

> I have scoured the web and cannot find any discussion of having the Lucene
> InetAddressPoint type exposed in Solr. Is there a reason this is omitted
> from the Solr supported types? Is it on the roadmap? Is there an
> alternative recommended way to index and store Ipv4 and Ipv6 addresses?
> Thanks for your help.
>
>
>
>
>
> *Michael Cooper*
>
>
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (LUCENE-8219) LevenshteinAutomata should estimate the number of states and transitions

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LUCENE-8219:
-

Commit 26d9a5ecd81c095d86334fffee93c02fdfca514f in lucene-solr's branch 
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=26d9a5e ]

LUCENE-8219: Do a better job of estimating automaton array sizes up front, to 
save on reallocation.  Committed on behalf of Christian Ziech.


> LevenshteinAutomata should estimate the number of states and transitions
> 
>
> Key: LUCENE-8219
> URL: https://issues.apache.org/jira/browse/LUCENE-8219
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Christian Ziech
>Assignee: Karl Wright
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> Currently the toAutomaton() method of the LevenshteinAutomata class uses the 
> default constructor of the Automaton although it exactly knows how many 
> states the automaton will have and can do a reasonable estimation on how many 
> transitions it will need as well.
> I suggest changing the lines 
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> int numStates = description.size();
> Automaton a = new Automaton();
> int lastState;
> {code}
> to
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> final int numStates = description.size();
> final int numTransitions = numStates * Math.min(1 + 2 * n, alphabet.length);
> final int prefixStates = prefix != null ? prefix.codePointCount(0, 
> prefix.length()) : 0;
> final Automaton a = new Automaton(numStates + prefixStates, numTransitions);
> int lastState;
> {code}
> For my test data this cut down on the total amount of memory needed for int 
> arrays by factor 4. The estimation of "1 + 2 * editDistance" should maybe 
> rather be replaced by a value coming from the ParametricDescription used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8219) LevenshteinAutomata should estimate the number of states and transitions

2018-03-22 Thread Karl Wright (JIRA)


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

Karl Wright resolved LUCENE-8219.
-
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

> LevenshteinAutomata should estimate the number of states and transitions
> 
>
> Key: LUCENE-8219
> URL: https://issues.apache.org/jira/browse/LUCENE-8219
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Christian Ziech
>Assignee: Karl Wright
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> Currently the toAutomaton() method of the LevenshteinAutomata class uses the 
> default constructor of the Automaton although it exactly knows how many 
> states the automaton will have and can do a reasonable estimation on how many 
> transitions it will need as well.
> I suggest changing the lines 
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> int numStates = description.size();
> Automaton a = new Automaton();
> int lastState;
> {code}
> to
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> final int numStates = description.size();
> final int numTransitions = numStates * Math.min(1 + 2 * n, alphabet.length);
> final int prefixStates = prefix != null ? prefix.codePointCount(0, 
> prefix.length()) : 0;
> final Automaton a = new Automaton(numStates + prefixStates, numTransitions);
> int lastState;
> {code}
> For my test data this cut down on the total amount of memory needed for int 
> arrays by factor 4. The estimation of "1 + 2 * editDistance" should maybe 
> rather be replaced by a value coming from the ParametricDescription used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

InetAddressPoint support in Solr?

2018-03-22 Thread Mike Cooper

I have scoured the web and cannot find any discussion of having the Lucene
InetAddressPoint type exposed in Solr. Is there a reason this is omitted
from the Solr supported types? Is it on the roadmap? Is there an alternative
recommended way to index and store Ipv4 and Ipv6 addresses? Thanks for your
help.

 

Michael Cooper



 



smime.p7s
Description: S/MIME cryptographic signature

[jira] [Commented] (LUCENE-8219) LevenshteinAutomata should estimate the number of states and transitions

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on LUCENE-8219:
-

Commit 7cadada441d7e10fc1271cf5b68f76efcdfdbc9b in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7cadada ]

LUCENE-8219: Do a better job of estimating automaton array sizes up front, to 
save on reallocation.  Committed on behalf of Christian Ziech.


> LevenshteinAutomata should estimate the number of states and transitions
> 
>
> Key: LUCENE-8219
> URL: https://issues.apache.org/jira/browse/LUCENE-8219
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Christian Ziech
>Assignee: Karl Wright
>Priority: Major
>
> Currently the toAutomaton() method of the LevenshteinAutomata class uses the 
> default constructor of the Automaton although it exactly knows how many 
> states the automaton will have and can do a reasonable estimation on how many 
> transitions it will need as well.
> I suggest changing the lines 
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> int numStates = description.size();
> Automaton a = new Automaton();
> int lastState;
> {code}
> to
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> final int numStates = description.size();
> final int numTransitions = numStates * Math.min(1 + 2 * n, alphabet.length);
> final int prefixStates = prefix != null ? prefix.codePointCount(0, 
> prefix.length()) : 0;
> final Automaton a = new Automaton(numStates + prefixStates, numTransitions);
> int lastState;
> {code}
> For my test data this cut down on the total amount of memory needed for int 
> arrays by factor 4. The estimation of "1 + 2 * editDistance" should maybe 
> rather be replaced by a value coming from the ParametricDescription used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (LUCENE-8219) LevenshteinAutomata should estimate the number of states and transitions

2018-03-22 Thread Karl Wright (JIRA)


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

Karl Wright reassigned LUCENE-8219:
---

Assignee: Karl Wright

> LevenshteinAutomata should estimate the number of states and transitions
> 
>
> Key: LUCENE-8219
> URL: https://issues.apache.org/jira/browse/LUCENE-8219
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Christian Ziech
>Assignee: Karl Wright
>Priority: Major
>
> Currently the toAutomaton() method of the LevenshteinAutomata class uses the 
> default constructor of the Automaton although it exactly knows how many 
> states the automaton will have and can do a reasonable estimation on how many 
> transitions it will need as well.
> I suggest changing the lines 
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> int numStates = description.size();
> Automaton a = new Automaton();
> int lastState;
> {code}
> to
> {code:language=java|firstline=154|linenumbers=true}
> // the number of states is based on the length of the word and n
> final int numStates = description.size();
> final int numTransitions = numStates * Math.min(1 + 2 * n, alphabet.length);
> final int prefixStates = prefix != null ? prefix.codePointCount(0, 
> prefix.length()) : 0;
> final Automaton a = new Automaton(numStates + prefixStates, numTransitions);
> int lastState;
> {code}
> For my test data this cut down on the total amount of memory needed for int 
> arrays by factor 4. The estimation of "1 + 2 * editDistance" should maybe 
> rather be replaced by a value coming from the ParametricDescription used.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (LUCENE-8219) LevenshteinAutomata should estimate the number of states and transitions

2018-03-22 Thread Christian Ziech (JIRA)

Christian Ziech created LUCENE-8219:
---

 Summary: LevenshteinAutomata should estimate the number of states 
and transitions
 Key: LUCENE-8219
 URL: https://issues.apache.org/jira/browse/LUCENE-8219
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Christian Ziech


Currently the toAutomaton() method of the LevenshteinAutomata class uses the 
default constructor of the Automaton although it exactly knows how many states 
the automaton will have and can do a reasonable estimation on how many 
transitions it will need as well.

I suggest changing the lines {code:language=java|firstline=154|linenumbers=true}
// the number of states is based on the length of the word and n
int numStates = description.size();

Automaton a = new Automaton();
int lastState;
{code}
to
{code:language=java|firstline=154|linenumbers=true}
// the number of states is based on the length of the word and n
final int numStates = description.size();
final int numTransitions = numStates * Math.min(1 + 2 * n, alphabet.length);
final int prefixStates = prefix != null ? prefix.codePointCount(0, 
prefix.length()) : 0;

final Automaton a = new Automaton(numStates + prefixStates, numTransitions);
int lastState;
{code}
For my test data this cut down on the total amount of memory needed for int 
arrays by factor 4. The estimation of "1 + 2 * editDistance" should maybe 
rather be replaced by a value coming from the ParametricDescription used.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-10075) TestNonWritablePersistFile fails when run as a single test under root.

2018-03-22 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-10075:
---
Attachment: SOLR-10075.patch

> TestNonWritablePersistFile fails when run as a single test under root.
> --
>
> Key: SOLR-10075
> URL: https://issues.apache.org/jira/browse/SOLR-10075
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Attachments: SOLR-10075.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-10075) TestNonWritablePersistFile fails when run as a single test under root.

2018-03-22 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-10075:


I thought I had made an attempt to fix this before and I guess I had - we use 
an assume to catch the 'under root' issue, but then no test executes and our 
tests fail in that case. I'll switch out the assumes so this test can pass 
individually.

> TestNonWritablePersistFile fails when run as a single test under root.
> --
>
> Key: SOLR-10075
> URL: https://issues.apache.org/jira/browse/SOLR-10075
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-10075) TestNonWritablePersistFile fails when run as a single test under root.

2018-03-22 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-10075:
---
Summary: TestNonWritablePersistFile fails when run as a single test under 
root.  (was: TestNonWritablePersistFile appears to be incompatible with custom 
ant test location properties that should be supported.)

> TestNonWritablePersistFile fails when run as a single test under root.
> --
>
> Key: SOLR-10075
> URL: https://issues.apache.org/jira/browse/SOLR-10075
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 313 - Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-repro/313/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/19/consoleText

[repro] Revision: bd6cf168e0e129fa22545a7f614b2b146bd5f202

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testEventQueue -Dtests.seed=DEF89269F503DD1 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-LB 
-Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testNodeLostTrigger -Dtests.seed=DEF89269F503DD1 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=ar-LB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testListeners -Dtests.seed=DEF89269F503DD1 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-LB 
-Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testNodeAddedTrigger -Dtests.seed=DEF89269F503DD1 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=ar-LB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TriggerIntegrationTest 
-Dtests.method=testSetProperties -Dtests.seed=DEF89269F503DD1 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=ar-LB -Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=AtomicUpdateProcessorFactoryTest 
-Dtests.method=testMultipleThreads -Dtests.seed=DEF89269F503DD1 
-Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
-Dtests.locale=sl-SI -Dtests.timezone=America/Lima -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
92f1cdebfaff79867a6a65f9419fc0bba274c62b
[repro] git fetch
[repro] git checkout bd6cf168e0e129fa22545a7f614b2b146bd5f202

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TriggerIntegrationTest
[repro]   AtomicUpdateProcessorFactoryTest
[repro] ant compile-test

[...truncated 3314 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TriggerIntegrationTest|*.AtomicUpdateProcessorFactoryTest" 
-Dtests.showOutput=onerror  -Dtests.seed=DEF89269F503DD1 -Dtests.multiplier=2 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-LB 
-Dtests.timezone=Mexico/BajaSur -Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 22735 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   1/5 failed: 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest
[repro]   3/5 failed: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest
[repro] git checkout 92f1cdebfaff79867a6a65f9419fc0bba274c62b

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

[jira] [Commented] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on SOLR-12134:
---

bq. let's see if the autopatch sumission review will like my patch

Looks like there are a couple problems here:

# The patch Yetus chose was {{nocommit.SOLR-12134.sample-failures.patch}}, 
rather than {{SOLR-12134.patch}}.  Judging from  
https://yetus.apache.org/documentation/in-progress/precommit-patchnames/ I 
would have thought a {{nocommit.\*}} patch would be ignored.  I'll ask on the 
Yetus mailing list about this.
# The "Validate ref guide" test is reported as failed, but the log has no 
record of any ant target being called, so I don't know what happened.  Also the 
comment associated with the failure refers to the wrong test ("Validate source 
patterns validate-source-patterns failed").  I'll run tests locally (using 
{{dev-tools/test-patch/test-patch.sh}}) to see if I can figure out what's 
happening.

> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 # 2446 - Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2446/

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.ValueFacetTest

Error Message:
Could not load collection from ZK: collection1

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
collection1
at __randomizedtesting.SeedInfo.seed([5BF579E5AE2FF658]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1236)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:674)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154)
at 
org.apache.solr.analytics.SolrAnalyticsTestCase.setupCollection(SolrAnalyticsTestCase.java:63)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)
Caused by: org.apache.zookeeper.KeeperException$SessionExpiredException: 
KeeperErrorCode = Session expired for /collections/collection1/state.json
at org.apache.zookeeper.KeeperException.create(KeeperException.java:130)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)
at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1215)
at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:340)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
at 
org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:340)
at 
org.apache.solr.common.cloud.ZkStateReader.fetchCollectionState(ZkStateReader.java:1248)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1234)
... 29 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.legacy.facet.LegacyFieldFacetExtrasCloudTest

Error Message:
Could not load collection from ZK: collection1

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
collection1
at __randomizedtesting.SeedInfo.seed([5BF579E5AE2FF658]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1236)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:674)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148)

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 180 - Unstable

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/180/

3 tests failed.
FAILED:  org.apache.solr.cloud.RestartWhileUpdatingTest.test

Error Message:
There are still nodes recoverying - waited for 320 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 320 
seconds
at 
__randomizedtesting.SeedInfo.seed([2AD49B74942418F5:A280A4AE3AD8750D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:185)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:921)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1478)
at 
org.apache.solr.cloud.RestartWhileUpdatingTest.test(RestartWhileUpdatingTest.java:144)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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

[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter

2018-03-22 Thread Jim Ferenczi (JIRA)


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

Jim Ferenczi commented on LUCENE-8202:
--

sure +1 for the exception, I don't think that this limit should be configurable 
though, 1000 seems more than enough to handle normal cases ?

> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8202.patch, LUCENE-8202.patch, LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter

2018-03-22 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on LUCENE-8202:
---

I don't like to silently drop tokens though.  I think throwing an exception is 
the way to go, with a clear message saying 'either prune your synonym tree, 
reduce the shingle size, or up the soft limit'

> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8202.patch, LUCENE-8202.patch, LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter

2018-03-22 Thread Jim Ferenczi (JIRA)


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

Jim Ferenczi commented on LUCENE-8202:
--

+1 to set position length to 1, this is a fixed size shingle filter so there's 
no additional information in this attribute.
Regarding the explosion of the number of terms can you track the total number 
of tokens that need to produce a shingle at the next position and ignore new 
tokens with posIncr=0 if the number is too high (1000 ?) ?


> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8202.patch, LUCENE-8202.patch, LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8202) Add a FixedShingleFilter

2018-03-22 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on LUCENE-8202:
---

TestRandomChains has found two issues:
 * positionLength should be 1, rather than the shingle length.  We don't have 
any intermediary tokens, only shingles, so we're not building graphs.  TRC 
found this by feeding the output into FlattenGraphFilter, which then complained.
 * we need somehow limit either the length of the shingle, or the number of 
stacked positions we iterate through, as we can otherwise get a combinatorial 
explosion of terms.  TRC found this by feeding long strings into a 
decompounding filter, and then building shingles of length 11.  The 
decompounding filter was producing up to 50 tokens in the same position, which 
lead to 50^11 shingles being generated, resulting in OOM.  I'm not sure of the 
best way of dealing with this one though - we could just limit shingle length 
to a maximum of 3 or 4, but that seems like too harsh a restriction for this.  
The other possibility would be to have a (configurable) maximum number of 
shingles emitted at a single position, and throw IllegalStateException if this 
is hit.

> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8202.patch, LUCENE-8202.patch, LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Reopened] (LUCENE-8202) Add a FixedShingleFilter

2018-03-22 Thread Alan Woodward (JIRA)


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

Alan Woodward reopened LUCENE-8202:
---

Reopening to address a couple of test failures

> Add a FixedShingleFilter
> 
>
> Key: LUCENE-8202
> URL: https://issues.apache.org/jira/browse/LUCENE-8202
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8202.patch, LUCENE-8202.patch, LUCENE-8202.patch
>
>
> In LUCENE-3475 I tried to make a ShingleGraphFilter that could accept and 
> emit arbitrary graphs, while duplicating all the functionality of the 
> existing ShingleFilter.  This ends up being extremely hairy, and doesn't play 
> well with query parsers.
> I'd like to step back and try and create a simpler shingle filter that can be 
> used for index-time phrase tokenization only.  It will have a single fixed 
> shingle size, can deal with single-token synonyms, and won't emit unigrams.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12087) Deleting replicas sometimes fails and causes the replicas to exist in the down state

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12087:


Commit 137dc1df2e9d5b3c6053f0c98a7e1a7ea6206b00 in lucene-solr's branch 
refs/heads/branch_7x from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=137dc1d ]

SOLR-12087: Deleting replicas sometimes fails and causes the replicas to exist 
in the down state


> Deleting replicas sometimes fails and causes the replicas to exist in the 
> down state
> 
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Assignee: Cao Manh Dat
>Priority: Critical
> Attachments: SOLR-12087.patch, SOLR-12087.patch, SOLR-12087.patch, 
> SOLR-12087.test.patch, Screen Shot 2018-03-16 at 11.50.32 AM.png
>
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> This also occurs when trying to move replicas, since that move is an add and 
> delete.
> Some more information regarding this issue; when the MOVEREPLICA command is 
> issued, the new replica is created successfully but the replica to be deleted 
> fails to be removed from state.json (the core is deleted though) and we see 
> two logs spammed.
>  # The node containing the leader replica continually (read every second) 
> attempts to initiate recovery on the replica and fails to do so because the 
> core does not exist. As a result it continually publishes a down state for 
> the replica to zookeeper.
>  # The deleted replica node spams that it cannot locate the core because it's 
> been deleted.
> During this period of time, we see an increase in ZK network connectivity 
> overall, until the replica is finally deleted (spamming DELETEREPLICA on the 
> shard until its removed from the state)
> My guess is there's two issues at hand here:
>  # The leader continually attempts to recover a downed replica that is 
> unrecoverable because the core does not exist.
>  # The replica to be deleted is having trouble being deleted from state.json 
> in ZK.
> This is mostly consistent for my use case. I'm running 7.2.1 with 66 nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12087) Deleting replicas sometimes fails and causes the replicas to exist in the down state

2018-03-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-12087:


Commit 92f1cdebfaff79867a6a65f9419fc0bba274c62b in lucene-solr's branch 
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=92f1cde ]

SOLR-12087: Deleting replicas sometimes fails and causes the replicas to exist 
in the down state


> Deleting replicas sometimes fails and causes the replicas to exist in the 
> down state
> 
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Assignee: Cao Manh Dat
>Priority: Critical
> Attachments: SOLR-12087.patch, SOLR-12087.patch, SOLR-12087.patch, 
> SOLR-12087.test.patch, Screen Shot 2018-03-16 at 11.50.32 AM.png
>
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> This also occurs when trying to move replicas, since that move is an add and 
> delete.
> Some more information regarding this issue; when the MOVEREPLICA command is 
> issued, the new replica is created successfully but the replica to be deleted 
> fails to be removed from state.json (the core is deleted though) and we see 
> two logs spammed.
>  # The node containing the leader replica continually (read every second) 
> attempts to initiate recovery on the replica and fails to do so because the 
> core does not exist. As a result it continually publishes a down state for 
> the replica to zookeeper.
>  # The deleted replica node spams that it cannot locate the core because it's 
> been deleted.
> During this period of time, we see an increase in ZK network connectivity 
> overall, until the replica is finally deleted (spamming DELETEREPLICA on the 
> shard until its removed from the state)
> My guess is there's two issues at hand here:
>  # The leader continually attempts to recover a downed replica that is 
> unrecoverable because the core does not exist.
>  # The replica to be deleted is having trouble being deleted from state.json 
> in ZK.
> This is mostly consistent for my use case. I'm running 7.2.1 with 66 nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 180 - Failure

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/180/

No tests ran.

Build Log:
[...truncated 30146 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 230 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (19.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.4.0-src.tgz...
   [smoker] 31.9 MB in 0.04 sec (900.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.4.0.tgz...
   [smoker] 73.4 MB in 0.07 sec (1037.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.4.0.zip...
   [smoker] 84.0 MB in 0.09 sec (908.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.4.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6308 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6308 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.4.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6308 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6308 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.4.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.8" 
PATH="/home/jenkins/tools/java/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.8/bin/java"; ant clean test 
-Dtests.badapples=false -Dtests.slow=false" failed:
   [smoker] Buildfile: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.4.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.4.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.4.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.13 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 516ms :: artifacts 
dl 18ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker] 
-
   [smoker] 
   [smoker] -init-totals:
   [smoker] 
   [smoker] test-core:
   [smoker] 
   [smoker] -clover.disable:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:

[jira] [Updated] (SOLR-12087) Deleting replicas sometimes fails and causes the replicas to exist in the down state

2018-03-22 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat updated SOLR-12087:

Attachment: SOLR-12087.patch

> Deleting replicas sometimes fails and causes the replicas to exist in the 
> down state
> 
>
> Key: SOLR-12087
> URL: https://issues.apache.org/jira/browse/SOLR-12087
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.2
>Reporter: Jerry Bao
>Assignee: Cao Manh Dat
>Priority: Critical
> Attachments: SOLR-12087.patch, SOLR-12087.patch, SOLR-12087.patch, 
> SOLR-12087.test.patch, Screen Shot 2018-03-16 at 11.50.32 AM.png
>
>
> Sometimes when deleting replicas, the replica fails to be removed from the 
> cluster state. This occurs especially when deleting replicas en mass; the 
> resulting cause is that the data is deleted but the replicas aren't removed 
> from the cluster state. Attempting to delete the downed replicas causes 
> failures because the core does not exist anymore.
> This also occurs when trying to move replicas, since that move is an add and 
> delete.
> Some more information regarding this issue; when the MOVEREPLICA command is 
> issued, the new replica is created successfully but the replica to be deleted 
> fails to be removed from state.json (the core is deleted though) and we see 
> two logs spammed.
>  # The node containing the leader replica continually (read every second) 
> attempts to initiate recovery on the replica and fails to do so because the 
> core does not exist. As a result it continually publishes a down state for 
> the replica to zookeeper.
>  # The deleted replica node spams that it cannot locate the core because it's 
> been deleted.
> During this period of time, we see an increase in ZK network connectivity 
> overall, until the replica is finally deleted (spamming DELETEREPLICA on the 
> shard until its removed from the state)
> My guess is there's two issues at hand here:
>  # The leader continually attempts to recover a downed replica that is 
> unrecoverable because the core does not exist.
>  # The replica to be deleted is having trouble being deleted from state.json 
> in ZK.
> This is mostly consistent for my use case. I'm running 7.2.1 with 66 nodes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12131) Authorization plugin support for getting user's roles from the outside

2018-03-22 Thread JIRA


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

Jan Høydahl commented on SOLR-12131:


See pull request 341 for patch. Targeting 7.4. Comments welcome

> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping 
> users to roles. However, when users are authenticated by an external Identity 
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps 
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the 
> Authorization plugin should be able to accept (verified) roles from the 
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a 
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization 
> plugin can then pull the roles from request. By piggy-backing on the 
> Principal, we have a seamless way to transfer extra external information, and 
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure 
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two 
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new 
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12131) Authorization plugin support for getting user's roles from the outside

2018-03-22 Thread JIRA


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

Jan Høydahl reassigned SOLR-12131:
--

Assignee: Jan Høydahl

> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping 
> users to roles. However, when users are authenticated by an external Identity 
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps 
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the 
> Authorization plugin should be able to accept (verified) roles from the 
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a 
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization 
> plugin can then pull the roles from request. By piggy-backing on the 
> Principal, we have a seamless way to transfer extra external information, and 
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure 
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two 
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new 
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12131) Authorization plugin support for getting user's roles from the outside

2018-03-22 Thread JIRA


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

Jan Høydahl updated SOLR-12131:
---
Fix Version/s: master (8.0)
   7.4

> Authorization plugin support for getting user's roles from the outside
> --
>
> Key: SOLR-12131
> URL: https://issues.apache.org/jira/browse/SOLR-12131
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the {{RuleBasedAuthorizationPlugin}} relies on explicitly mapping 
> users to roles. However, when users are authenticated by an external Identity 
> service (e.g. JWT as implemented in SOLR-12121), that external service keeps 
> track of the user's roles, and will pass that as a "claim" in the token (JWT).
> In order for Solr to be able to Authorise requests based on those roles, the 
> Authorization plugin should be able to accept (verified) roles from the 
> request instead of explicit mapping.
> Suggested approach is to create a new interface {{VerifiedUserRoles}} and a 
> {{PrincipalWithUserRoles}} which implements the interface. The Authorization 
> plugin can then pull the roles from request. By piggy-backing on the 
> Principal, we have a seamless way to transfer extra external information, and 
> there is also a natural relationship:
> {code:java}
> User Authentication -> Role validation -> Creating a Principal{code}
> I plan to add the interface, the custom Principal class and restructure 
> {{RuleBasedAuthorizationPlugin}} in an abstract base class and two 
> implementations: {{RuleBasedAuthorizationPlugin}} (as today) and a new 
> {{ExternalRoleRuleBasedAuthorizationPlugin.}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.3 - Build # 6 - Failure

2018-03-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.3/6/

No tests ran.

Build Log:
[...truncated 30126 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist
 [copy] Copying 491 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 230 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] Java 9 JAVA_HOME=/home/jenkins/tools/java/latest1.9
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (53.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.3.0-src.tgz...
   [smoker] 31.9 MB in 0.03 sec (1182.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.tgz...
   [smoker] 73.4 MB in 0.08 sec (874.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.3.0.zip...
   [smoker] 83.9 MB in 0.08 sec (996.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.3.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] test demo with 9...
   [smoker]   got 6300 hits for query "lucene"
   [smoker] checkindex with 9...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.3.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 217 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
-Dtests.slow=false'...
   [smoker] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.9" 
PATH="/home/jenkins/tools/java/latest1.9/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.9/bin/java"; ant clean test 
-Dtests.badapples=false -Dtests.slow=false" failed:
   [smoker] Buildfile: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] [loadresource] Do not set property disallowed.ivy.jars.list as its 
length is 0.
   [smoker] 
   [smoker] -ivy-fail-disallowed-ivy-version:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.3/lucene/build/smokeTestRelease/tmp/unpack/lucene-7.3.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.13 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 1049ms :: artifacts 
dl 2ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker]

[JENKINS] Lucene-Solr-BadApples-7.x-Linux (32bit/jdk1.8.0_162) - Build # 12 - Still Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/12/
Java: 32bit/jdk1.8.0_162 -client -XX:+UseParallelGC

6 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [ZkController] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.cloud.ZkController  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.cloud.ZkController.(ZkController.java:448)  at 
org.apache.solr.core.ZkContainer.initZooKeeper(ZkContainer.java:113)  at 
org.apache.solr.core.CoreContainer.load(CoreContainer.java:519)  at 
org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:263)
  at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:183)  
at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:139)  at 
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:741)  
at 
org.eclipse.jetty.servlet.ServletHandler.updateMappings(ServletHandler.java:1474)
  at 
org.eclipse.jetty.servlet.ServletHandler.setFilterMappings(ServletHandler.java:1537)
  at 
org.eclipse.jetty.servlet.ServletHandler.addFilterMapping(ServletHandler.java:1183)
  at 
org.eclipse.jetty.servlet.ServletHandler.addFilterWithMapping(ServletHandler.java:1020)
  at 
org.eclipse.jetty.servlet.ServletContextHandler.addFilter(ServletContextHandler.java:447)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$1.lifeCycleStarted(JettySolrRunner.java:308)
  at 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarted(AbstractLifeCycle.java:179)
  at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:69)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:396)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:369)
  at org.apache.solr.cloud.ChaosMonkey.start(ChaosMonkey.java:653)  at 
org.apache.solr.cloud.BasicDistributedZkTest.testStopAndStartCoresInOneInstance(BasicDistributedZkTest.java:561)
  at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:381)
  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:1737)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
  at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
  at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
  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:943)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
  at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
  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

[jira] [Commented] (SOLR-12134) validate links to javadocs in ref-guide & hook all ref-guide validation into top level documentation/precommit

2018-03-22 Thread Lucene/Solr QA (JIRA)


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

Lucene/Solr QA commented on SOLR-12134:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
|| || || || {color:brown} master Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m  3s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} | 
{color:red}  0m  3s{color} | {color:red} Validate source patterns 
validate-source-patterns failed {color} |
| {color:red}-1{color} | {color:red} Validate ref guide {color} | {color:red}  
0m  3s{color} | {color:red} Validate source patterns validate-source-patterns 
failed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:black}{color} | {color:black} {color} | {color:black}  0m 31s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12134 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12915523/nocommit.SOLR-12134.sample-failures.patch
 |
| Optional Tests |  ratsources  validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 2c4b78c |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Validate source patterns | 
https://builds.apache.org/job/PreCommit-SOLR-Build/10/artifact/out/patch-validate-source-patterns-root.txt
 |
| Validate ref guide | 
https://builds.apache.org/job/PreCommit-SOLR-Build/10/artifact/out/patch-validate-source-patterns-root.txt
 |
| modules | C: solr/solr-ref-guide U: solr/solr-ref-guide |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/10/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> validate links to javadocs in ref-guide & hook all ref-guide validation into 
> top level documentation/precommit
> --
>
> Key: SOLR-12134
> URL: https://issues.apache.org/jira/browse/SOLR-12134
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-12134.patch, 
> nocommit.SOLR-12134.sample-failures.patch
>
>
> We've seen a couple problems come up recently where the ref-guide had broken 
> links ot javadocs.
> In some cases these are because people made typos in java classnames / 
> pathnames while editing the docs - but in other cases the problems were that 
> the docs were correct at one point, but then later the class was 
> moved/renamed/removed, or had it's access level downgraded from public to 
> private (after deprecation)
> I've worked up a patch with some ideas to help us catch these types of 
> mistakes - and in general to hook the "bare-bones HTML" validation (which 
> does not require jekyll or any non-ivy managed external dependencies) into 
> {{ant precommit}}
> Details to follow in comment/patch...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11601) geodist fails for some fields when field is in parenthesis instead of sfield param

2018-03-22 Thread Lucene/Solr QA (JIRA)


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

Lucene/Solr QA commented on SOLR-11601:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
24s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 24s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 49m 38s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 54s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.update.processor.AtomicUpdateProcessorFactoryTest |
|   | solr.handler.admin.AutoscalingHistoryHandlerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11601 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12915515/SOLR-11601.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 2c4b78c |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/9/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/9/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | https://builds.apache.org/job/PreCommit-SOLR-Build/9/console 
|
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> geodist fails for some fields when field is in parenthesis instead of sfield 
> param
> --
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-11601.patch, SOLR-11601.patch, SOLR-11601.patch
>
>
> Im switching my schemas from derprecated solr.LatLonType to 
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field 
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax 
> {color:#14892c}sfield=b4_location__geo_si=47.36667,8.55=geodist() asc
> works as expected though...{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk1.8.0_162) - Build # 12 - Still Unstable!

2018-03-22 Thread Policeman Jenkins Server

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/12/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC

9 tests failed.
FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([D6200915CB4A7DBF:1F954BBBC22DBB4A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue(TriggerIntegrationTest.java:752)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
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:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
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)


FAILED:  org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at

80 matches

Mail list logo