[jira] [Resolved] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-10406.
---
Resolution: Fixed

> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch, SOLR-10406.patch, 
> SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on;
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10406:


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

SOLR-10406: SolrJ must throw exception if server throws an error


> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch, SOLR-10406.patch, 
> SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on;
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19931 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19931/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration

Error Message:
expected: but 
was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([E6E9563D8751C4D1:58623092FE2BCAE4]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.cloud.ClusterStateUpdateTest.testCoreRegistration(ClusterStateUpdateTest.java:104)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 

[jira] [Commented] (SOLR-10931) Resolve conflicting package names o.a.s.cloud.autoscaling

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10931:
--

Yes! Wer should really work at decoupling the package names. 

> Resolve conflicting package names o.a.s.cloud.autoscaling
> -
>
> Key: SOLR-10931
> URL: https://issues.apache.org/jira/browse/SOLR-10931
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> At the moment, o.a.s.cloud.autoscaling is in core as well as in solrj modules.
> As per following comments, I think we should change them to different package 
> names:
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15658266=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15658266
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15654160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15654160
> Currently, the Eclipse project is broken on master due to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10931) Resolve conflicting package names o.a.s.cloud.autoscaling

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10931:
-

I'm +1 for {{org.apache.solr.client.solrj.autoscaling}}.

> Resolve conflicting package names o.a.s.cloud.autoscaling
> -
>
> Key: SOLR-10931
> URL: https://issues.apache.org/jira/browse/SOLR-10931
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> At the moment, o.a.s.cloud.autoscaling is in core as well as in solrj modules.
> As per following comments, I think we should change them to different package 
> names:
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15658266=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15658266
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15654160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15654160
> Currently, the Eclipse project is broken on master due to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10574:
-

I'm working on this on branch jira/solr-10574. Somehow, I am unable to 
understand why CacheHeaderTest#testCacheVetoHandler is failing; working on it.

> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 955 - Still Unstable!

[Policeman Jenkins Server]

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

36 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.ConvertedLegacyTest

Error Message:
org.apache.solr.ConvertedLegacyTest

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.ConvertedLegacyTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:273)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:233)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/ConvertedLegacyTest.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.TestSimpleTrackingShardHandler

Error Message:
org.apache.solr.TestSimpleTrackingShardHandler

Stack Trace:
java.lang.ClassNotFoundException: org.apache.solr.TestSimpleTrackingShardHandler
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:273)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:233)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:355)
at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
Caused by: java.io.FileNotFoundException: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/TestSimpleTrackingShardHandler.class
 (Too many open files)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.(FileInputStream.java:138)
at 
sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288)
at sun.misc.Resource.cachedInputStream(Resource.java:77)
at sun.misc.Resource.getByteBuffer(Resource.java:160)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:454)
at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
... 12 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.AsyncCallRequestStatusResponseTest

Error Message:
org.apache.solr.cloud.AsyncCallRequestStatusResponseTest

Stack Trace:
java.lang.ClassNotFoundException: 
org.apache.solr.cloud.AsyncCallRequestStatusResponseTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:370)
at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at 

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_131) - Build # 3811 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3811/
Java: 32bit/jdk1.8.0_131 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([E524C122AFCFED02:1DFA54CAD7A33C51]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:895)
at 
org.apache.solr.handler.admin.SegmentsInfoRequestHandlerTest.testSegmentInfosVersion(SegmentsInfoRequestHandlerTest.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=2=count(//lst[@name='segments']/lst/str[@name='version'][.='6.7.0'])
xml response was: 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4095 - Still Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([AD8C86E9ADB57CE2:D88146F5BDAFBA37]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 

[JENKINS-EA] Lucene-Solr-6.x-Windows (64bit/jdk-9-ea+173) - Build # 991 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/991/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults

Error Message:
mismatch: 'myid1'!='myid' @ response/docs/[0]/id

Stack Trace:
java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
at 
__randomizedtesting.SeedInfo.seed([68B87FEE659909DA:5A9278709D672D03]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
at 
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 13104 lines...]
   [junit4] Suite: org.apache.solr.schema.TestUseDocValuesAsStored
   [junit4]   2> Creating dataDir: 

[jira] [Commented] (SOLR-8256) Set legacyCloud=false as default

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8256: Fix CollectionsAPISolrJTest and UnloadDistributedZkTest failures 
(caused by first commmit)


> Set legacyCloud=false as default
> 
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, 
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this 
> mostly unknown setting and start defaulting to this behavior that starts us 
> down the path of zk=truth.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10503) CurrencyField should be changed from TrieLongField to LongPointField for underlying raw-polyfield

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10503:
--
Attachment: SOLR-10503.patch

Patch folding in [~hossman]'s latest feedback.  

I was pulling out my hair trying to figure out why Solrj example tests were 
failing when performing an atomic update on a currency field, e.g.:

{noformat}
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrExampleXMLTest 
-Dtests.method=testUpdateField -Dtests.seed=82002888280BD61E -Dtests.slow=true 
-Dtests.locale=lv -Dtests.timezone=Asia/Kamchatka -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.56s J10 | SolrExampleXMLTest.testUpdateField <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:50840/solr/collection1: ERROR: [doc=unique] 
multiple values encountered for non multiValued field price_cl: [1, 100]
{noformat}

I eventually traced this to {{stored="true"}} used on the dynamic sub-fields in 
{{CurrencyFieldType}}-based field types in example schemas; this causes Atomic 
Update indexing to fail; see 
[https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-FieldStorage].
  I added information about this to the example schemas and to the ref guide.

Comments inline below:

bq. now that CurrencyField extends CurrencyFieldType, can't we move 
CurrencyValue and FileExchangeRateProvider back into CurrencyFieldType.java (or 
make them static inner classes of CurrencyFieldType) ?

I made them static inner classes, but as a result had to add exceptional 
classloader logic to load  CurrencyFieldType inner classes (currently only 
FileExchangeRateProvider).

bq. you removed the error checking from ValueSourceParser.java? ... if someone 
tries to use the currency() function on a non CurrencyFieldType it should still 
through a clean error, not a ClassCastException

Fixed.

bq. do we need to bother parameterizing fieldTypeClass in 
CurrencyFieldTypeTest? isn't it enough to just assert that it's an instanceof 
CurrencyFieldType? ... the test methods really shouldn't be affected at all by 
this distinction

Agreed, removed the fieldTypeClass parameter.

bq. If we're going to consolidate the existing tests like this, it seems better 
to parameterize the expected provider class, and add a getter to 
CurrencyFieldType for that. then we could also fix the assume in 
testAsymmetricPointQuery so it isn't dependent on us remembering to keep the 
list of field names accurate.

Done. (CurrencyFieldType already had getProvider().)

bq. I think these (2) comments are suppose to refer to subclass (not 
superclass) ??... // Don't initialize if superclass already has done so

Right, fixed.

bq. FWIW: I'm still -0 to CurrencyFieldType having hardcoded defalts for \[the 
field suffixes\] ...I think it would be a lot better if the suffixes were 
mandatory in this new class

I've made this change.  I think the user experience would be better with 
defaults for the majority of folks who I'm guessing won't care about sub-field 
details.  But I'm ok with not providing them.

bq. The existence of the dynamicFieldDocValuesArg() method feels more awkward 
and clunky then just making createDynamicCurrencyField() a protected method 
that the subclass can overrideof course: if I can convince you to eliminte 
the DEFAULT_FIELD_SUFFIX_AMOUNT_* logic from the CurrencyFieldType parent 
class, that gets much simpler: only the CurrencyField subclass needs to bother 
implementing/calling createDynamicCurrencyField()

Since only CurrencyField uses createDynamicCurrencyField(), I moved it there.


> CurrencyField should be changed from TrieLongField to LongPointField for 
> underlying raw-polyfield
> -
>
> Key: SOLR-10503
> URL: https://issues.apache.org/jira/browse/SOLR-10503
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10503.patch, SOLR-10503.patch, SOLR-10503.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19930 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19930/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

Error Message:
Error from server at https://127.0.0.1:36549/solr: deleteshard the collection 
time out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36549/solr: deleteshard the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([4B8D3AC3B8094613:8ED38EDF3EFC8CEE]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:599)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:231)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:220)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:459)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:389)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1135)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:876)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:807)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:143)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6669 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6669/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

9 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([74FC9598F171894D:1F15584E16B4F98]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  

[JENKINS] Lucene-Solr-Tests-master - Build # 1890 - Still Unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([B4233419C2FB1329:C12EF405D2E1D5FC]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+173) - Build # 19929 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19929/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:41863/solr/test_col: Failed synchronous update on shard 
StdNode: http://127.0.0.1:40243/solr/test_col_shard1_replica_n1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@190e7a02

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:41863/solr/test_col: Failed synchronous update on 
shard StdNode: http://127.0.0.1:40243/solr/test_col_shard1_replica_n1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@190e7a02
at 
__randomizedtesting.SeedInfo.seed([9514692AABDE8362:A3000B6C2183B973]:0)
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+173) - Build # 3809 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3809/
Java: 32bit/jdk-9-ea+173 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
document count mismatch.  control=458 sum(shards)=457 cloudClient=457

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=458 sum(shards)=457 
cloudClient=457
at 
__randomizedtesting.SeedInfo.seed([55EE5794E7C28149:DDBA684E493EECB1]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1323)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:226)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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 

[jira] [Resolved] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10883.
---
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

Thanks for the review [~ctargett].


> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.7
>
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch, SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10883:


Commit d9d3369cd755160a1187604e353dcb915f65cf3d in lucene-solr's branch 
refs/heads/branch_6x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d9d3369 ]

SOLR-10883: Ref guide: Escape replacement substitutions; add .adoc file checks 
to the top-level validate target

 Conflicts:
solr/solr-ref-guide/src/the-terms-component.adoc


> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch, SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10883:


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

SOLR-10883: Ref guide: Escape replacement substitutions; add .adoc file checks 
to the top-level validate target


> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch, SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1889 - Still Unstable

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([593FF2859D59418:709E3F3449CF52CD]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE 

[jira] [Comment Edited] (SOLR-10934) create a link+anchor checker for the ref-guide PDF using PDFBox

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-10934 at 6/21/17 10:13 PM:
---

based on the code in this SO post, it looks like we should be able to..

https://stackoverflow.com/a/38846776/689372

* loop over all PDAnnotations in each PDPage 
* if the annotation isa PDAnnotationLink then we can access it's PDAction and 
PDDestination
* PDActionURI is an external link, PDActionGoTo is an inter-document link
* PDActionGoTo can point at either a PDPageDestination (page num?) or a 
PDNamedDestination (named anchor?)
* we lookup PDNamedDestination instances in the document catlog.

that _should_ enable us to vet that all inter-document links point to a valid 
anchor.

one thing i'm not sure about is if would be possible to check for the "anchor 
used more then once in diff adoc files" type problem -- i suspect that the 
catalog's list of PDNamedDestination doesn't allow dups, so that info may 
already be lost as part of the PDF creation??


was (Author: hossman):
based on the code in this SO post, it looks like we should be able to..

* loop over all PDAnnotations in each PDPage 
* if the annotation isa PDAnnotationLink then we can access it's PDAction and 
PDDestination
* PDActionURI is an external link, PDActionGoTo is an inter-document link
* PDActionGoTo can point at either a PDPageDestination (page num?) or a 
PDNamedDestination (named anchor?)
* we lookup PDNamedDestination instances in the document catlog.

that _should_ enable us to vet that all inter-document links point to a valid 
anchor.

one thing i'm not sure about is if would be possible to check for the "anchor 
used more then once in diff adoc files" type problem -- i suspect that the 
catalog's list of PDNamedDestination doesn't allow dups, so that info may 
already be lost as part of the PDF creation??

> create a link+anchor checker for the ref-guide PDF using PDFBox
> ---
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> The PDF build only requires things installed by ivy (via JRuby) and we 
> already have some PDFBox based code in ReducePDFSize.java that operates on 
> this PDF every time it's run -- so if we can find a way to do similar checks 
> using the PDFBox API we could catch these broken links faster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1389 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1389/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([C8A8F50C172FC4D3:BDA5351007350206]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_131) - Build # 19928 - Still unstable!

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=1664, 
name=cdcr-update-log-synchronizer-803-thread-1, state=WAITING, 
group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)2) Thread[id=1676, 
name=cdcr-update-log-synchronizer-809-thread-1, state=WAITING, 
group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:748)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 
   1) Thread[id=1664, name=cdcr-update-log-synchronizer-803-thread-1, 
state=WAITING, group=TGRP-CdcrVersionReplicationTest]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
   2) Thread[id=1676, name=cdcr-update-log-synchronizer-809-thread-1, 
state=WAITING, group=TGRP-CdcrVersionReplicationTest]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1081)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at __randomizedtesting.SeedInfo.seed([C85C3257A8C01095]:0)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=1664, name=cdcr-update-log-synchronizer-803-thread-1, state=WAITING, 
group=TGRP-CdcrVersionReplicationTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 

[jira] [Commented] (SOLR-10934) create a link+anchor checker for the ref-guide PDF using PDFBox

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10934:
-

based on the code in this SO post, it looks like we should be able to..

* loop over all PDAnnotations in each PDPage 
* if the annotation isa PDAnnotationLink then we can access it's PDAction and 
PDDestination
* PDActionURI is an external link, PDActionGoTo is an inter-document link
* PDActionGoTo can point at either a PDPageDestination (page num?) or a 
PDNamedDestination (named anchor?)
* we lookup PDNamedDestination instances in the document catlog.

that _should_ enable us to vet that all inter-document links point to a valid 
anchor.

one thing i'm not sure about is if would be possible to check for the "anchor 
used more then once in diff adoc files" type problem -- i suspect that the 
catalog's list of PDNamedDestination doesn't allow dups, so that info may 
already be lost as part of the PDF creation??

> create a link+anchor checker for the ref-guide PDF using PDFBox
> ---
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>
> We currently have CheckLinksAndAnchors.java which is automatically run 
> against the ref-guide HTML as part of the build to use JSoup to find bad 
> links/anchors that asciidoctor doesn't complain about -- but not everyone 
> does/can build the HTML version of the ref-guide sincif we can e it requires 
> manually installing jekyll.
> The PDF build only requires things installed by ivy (via JRuby) and we 
> already have some PDFBox based code in ReducePDFSize.java that operates on 
> this PDF every time it's run -- so if we can find a way to do similar checks 
> using the PDFBox API we could catch these broken links faster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10934) create a link+anchor checker for the ref-guide PDF using PDFBox

[Hoss Man (JIRA)]

Hoss Man created SOLR-10934:
---

 Summary: create a link+anchor checker for the ref-guide PDF using 
PDFBox
 Key: SOLR-10934
 URL: https://issues.apache.org/jira/browse/SOLR-10934
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man


We currently have CheckLinksAndAnchors.java which is automatically run against 
the ref-guide HTML as part of the build to use JSoup to find bad links/anchors 
that asciidoctor doesn't complain about -- but not everyone does/can build the 
HTML version of the ref-guide sincif we can e it requires manually installing 
jekyll.

The PDF build only requires things installed by ivy (via JRuby) and we already 
have some PDFBox based code in ReducePDFSize.java that operates on this PDF 
every time it's run -- so if we can find a way to do similar checks using the 
PDFBox API we could catch these broken links faster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10842) Move quickstart.html to Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10842:
--

This is where I'm heading with this:

Solr Quick Start (the Tutorial)
* Start Solr
* Create Collection
* Index basic data 
* Stop Solr/Restart
* Deeper Look (other sections)
* Where to go next

Solr Installation and Upgrades (rename "Getting Started" section; following are 
sub-sections)
* Installation
** System requirements (including Java)
** Unix/Windows requirements for using bin/solr
** Untar/unzip package

* Orientation to your Solr Install
** Where stuff is - what's in the various directories
** Exampledocs & how to use them
** Major config files

* Taking Solr to Production (move here)

* Upgrading Solr (move here)

> Move quickstart.html to Ref Guide
> -
>
> Key: SOLR-10842
> URL: https://issues.apache.org/jira/browse/SOLR-10842
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: master (7.0)
>
>
> The Solr Quick Start at https://lucene.apache.org/solr/quickstart.html has 
> been problematic to keep up to date - until Ishan just updated it yesterday 
> for 6.6, it said "6.2.1", so hadn't been updated for several releases.
> Now that the Ref Guide is in AsciiDoc format, we can easily use variables for 
> package versions, and it could be released as part of the Ref Guide and kept 
> up to date. It could also integrate links to more information on topics, and 
> users would already be IN the docs, so they would not need to wonder where 
> the docs are.
> There are a few places on the site that will need to be updated to point to 
> the new location, but I can also put a redirect rule into .htaccess so people 
> are redirected to the new location if there are other links "in the wild" 
> that we cannot control. This allows it to be versioned also, if that becomes 
> necessary.
> As part of this, I would like to also update the entire "Getting Started" 
> section of the Ref Guide, which is effectively identical to what was in the 
> first release of the Ref Guide back in 2009 for Solr 1.4 and is in serious 
> need of reconsideration.
> My thought is that moving the page + redoing the Getting Started section 
> would be for 7.0, but if folks are excited about this idea I could move the 
> page for 6.6 and hold off redoing the larger section until 7.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10866) Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10866:

Attachment: SOLR-10866.patch

patch modified SOLR-9565.patch through.

> Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> 
>
> Key: SOLR-10866
> URL: https://issues.apache.org/jira/browse/SOLR-10866
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10866.patch, SOLR-10866.patch, SOLR-10866.patch, 
> SOLR-10866.patch, SOLR-10866.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> TimestampUpdateProcessorFactory will be able to execute by sample curl like 
> below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=Timestamp=timestamp_tdt=true
>  --data-binary { "id" : "1" , "title_s" : "titleA" }
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10866) Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10866:

Description: 
We are trying to get rid of processor definitions in SolrConfig for all URPs 
and take parameters in the request itself.

TimestampUpdateProcessorFactory will be able to execute by sample curl like 
below:

{code}
 curl -X POST -H Content-Type: application/json  
http://localhost:8983/solr/test/update/json/docs?processor=timestamp=timestamp_tdt=true
 --data-binary { "id" : "1" , "title_s" : "titleA" }
{code}

Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.

  was:
We are trying to get rid of processor definitions in SolrConfig for all URPs 
and take parameters in the request itself.

TimestampUpdateProcessorFactory will be able to execute by sample curl like 
below:

{code}
 curl -X POST -H Content-Type: application/json  
http://localhost:8983/solr/test/update/json/docs?processor=Timestamp=timestamp_tdt=true
 --data-binary { "id" : "1" , "title_s" : "titleA" }
{code}

Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.


> Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> 
>
> Key: SOLR-10866
> URL: https://issues.apache.org/jira/browse/SOLR-10866
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10866.patch, SOLR-10866.patch, SOLR-10866.patch, 
> SOLR-10866.patch, SOLR-10866.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> TimestampUpdateProcessorFactory will be able to execute by sample curl like 
> below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=timestamp=timestamp_tdt=true
>  --data-binary { "id" : "1" , "title_s" : "titleA" }
> {code}
> Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10866) Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with request

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-10866:

Description: 
We are trying to get rid of processor definitions in SolrConfig for all URPs 
and take parameters in the request itself.

TimestampUpdateProcessorFactory will be able to execute by sample curl like 
below:

{code}
 curl -X POST -H Content-Type: application/json  
http://localhost:8983/solr/test/update/json/docs?processor=timestamp=timestamp_tdt=true
 --data-binary { "id" : "1" , "title_s" : "titleA" }
{code}

Configuration for TimestampUpdateProcessorFactory in solrconfig.xml is optional.

  was:
We are trying to get rid of processor definitions in SolrConfig for all URPs 
and take parameters in the request itself.

TimestampUpdateProcessorFactory will be able to execute by sample curl like 
below:

{code}
 curl -X POST -H Content-Type: application/json  
http://localhost:8983/solr/test/update/json/docs?processor=timestamp=timestamp_tdt=true
 --data-binary { "id" : "1" , "title_s" : "titleA" }
{code}

Configuration for UUIDUpdateProcessorFactory in solrconfig.xml is optional.


> Make TimestampUpdateProcessorFactory as Runtime URP; take params(s) with 
> request
> 
>
> Key: SOLR-10866
> URL: https://issues.apache.org/jira/browse/SOLR-10866
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Amrit Sarkar
>Priority: Minor
> Attachments: SOLR-10866.patch, SOLR-10866.patch, SOLR-10866.patch, 
> SOLR-10866.patch, SOLR-10866.patch
>
>
> We are trying to get rid of processor definitions in SolrConfig for all URPs 
> and take parameters in the request itself.
> TimestampUpdateProcessorFactory will be able to execute by sample curl like 
> below:
> {code}
>  curl -X POST -H Content-Type: application/json  
> http://localhost:8983/solr/test/update/json/docs?processor=timestamp=timestamp_tdt=true
>  --data-binary { "id" : "1" , "title_s" : "titleA" }
> {code}
> Configuration for TimestampUpdateProcessorFactory in solrconfig.xml is 
> optional.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10933:
---

Wow, that is a complicated expression. Are you just experimenting with the 
syntax?


> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 790 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/790/

No tests ran.

Build Log:
[...truncated 25926 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.5 MB in 0.03 sec (853.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 69.0 MB in 0.08 sec (863.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 79.3 MB in 0.09 sec (886.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6159 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6159 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.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.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 215 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (223.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 50.1 MB in 0.06 sec (771.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 141.3 MB in 0.18 sec (799.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 142.3 MB in 0.17 sec (818.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=7887). Happy searching!
   [smoker] 

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 954 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/954/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {   "responseHeader":{ 
"status":0, "QTime":0},   "overlay":{ "znodeVersion":0, 
"runtimeLib":{"colltest":{ "name":"colltest", "version":1,  
from server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1,  from server:  null
at 
__randomizedtesting.SeedInfo.seed([704A2CD4C98D1B29:A80701833E50BE89]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10842) Move quickstart.html to Ref Guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10842:
--

I'm working through how to reorganize Solr's entire "Getting Started" content. 
I think it's really fair to say it's "poor" today. Here's a breakdown of what 
we do today in that section:

Getting Started
* Solr is awesome!
* Sections in this section

Installation
* Java requirements
* Untar the package (doesn't use package name "solr-x.y.z.tar.gz")

Running Solr
* Start Solr (and stop)
* Create a core
* Basic indexing

A Quick Overview
* Schema concepts
* Solr is amazing!

A Step Closer
* Install directories
* Major config files

Solr Control Script Reference
* Start/Stop
* Create/Remove Collection
* Auth
* ZK

A fair bit of duplicated concepts, low on actual facts, page titles don't 
reflect what is actually covered there, etc. I'm still working through how I 
might replace it, but one thing is I want the pages to be clear and give users 
a really solid orientation to the system.

> Move quickstart.html to Ref Guide
> -
>
> Key: SOLR-10842
> URL: https://issues.apache.org/jira/browse/SOLR-10842
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: master (7.0)
>
>
> The Solr Quick Start at https://lucene.apache.org/solr/quickstart.html has 
> been problematic to keep up to date - until Ishan just updated it yesterday 
> for 6.6, it said "6.2.1", so hadn't been updated for several releases.
> Now that the Ref Guide is in AsciiDoc format, we can easily use variables for 
> package versions, and it could be released as part of the Ref Guide and kept 
> up to date. It could also integrate links to more information on topics, and 
> users would already be IN the docs, so they would not need to wonder where 
> the docs are.
> There are a few places on the site that will need to be updated to point to 
> the new location, but I can also put a redirect rule into .htaccess so people 
> are redirected to the new location if there are other links "in the wild" 
> that we cannot control. This allows it to be versioned also, if that becomes 
> necessary.
> As part of this, I would like to also update the entire "Getting Started" 
> section of the Ref Guide, which is effectively identical to what was in the 
> first release of the Ref Guide back in 2009 for Solr 1.4 and is in serious 
> need of reconsideration.
> My thought is that moving the page + redoing the Getting Started section 
> would be for 7.0, but if folks are excited about this idea I could move the 
> page for 6.6 and hold off redoing the larger section until 7.0.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10883) Ref guide: some replacement substitutions, e.g. => to right arrow, are rendered invisibly in the PDF

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10883:
--

I had an offline discussion with Steve about this. The changes to validate 
.adoc files are fine IMO, but are only a drop in the bucket as far as what can 
go wrong with these files.

There are already two validations that happen when the docs are built:

* the Jekyll and Asciidoctor-pdf tools that we use to build the HTML and PDF 
versions respectively will WARN if files are malformed. The two most common 
I've seen are when section levels are out of order and when a section doesn't 
include a "part" (see SOLR-10297 for more discussion about these)
* After the docs are built, the {{check-links-and-anchors}} target validates 
that all the links between pages adhere to the proper format to be sure they 
work in the PDF, and makes sure there are not duplicate section headings on 
different pages so inter-doc links don't get confused.

I don't expect there to be a lot of devs who build the docs locally before 
committing their changes, but it would be nice if the Ref Guide build had the 
additional validation of what you want to put in precommit; by the same token, 
it would be nice if precommit checked the links and anchors that's now only 
done during the build (the most recent Jenkins Ref Guide build failure was 
caused by that check not being run). 

I also have a list of stuff I'd like to add to validation, just as warnings - 
more along the lines of enforcing/suggesting some style consistencies where 
feasible.

If you go ahead and commit your changes here, I can look at adding precommit to 
the Ref Guide build. Then maybe we can add the check-links-and-anchors to 
precommit if that makes sense to others also.

> Ref guide: some replacement substitutions, e.g. => to right arrow, are 
> rendered invisibly in the PDF 
> -
>
> Key: SOLR-10883
> URL: https://issues.apache.org/jira/browse/SOLR-10883
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: Screen Shot 2017-06-12 at 7.23.07 PM.png, 
> SOLR-10883.patch, SOLR-10883.patch
>
>
> {{=>}}, {{<=}}, and {{<-}} are rendered as invisible in the PDF.  These 
> “replacement substitutions” aka “textual symbol replacements” ( 
> http://asciidoctor.org/docs/asciidoc-writers-guide/#replacements ) render as 
> invisible characters in the PDF, though they are visible in the HTML format, 
> when substitution is in effect.
> This is only a problem outside of code blocks (e.g. {{-->}} close comment 
> syntax in XML is never improperly substituted).
> In the screenshot below, a table from the 
> CharFilterFactories|solr.MappingCharFilterFactory section is shown in the 
> HTML format on the left, and in PDF format to the right; in the PDF format 
> the {{=>}} is invisible.
> !Screen Shot 2017-06-12 at 7.23.07 PM.png|width=800!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [JENKINS] Solr-reference-guide-master - Build # 44 - Still Failing

[Cassandra Targett]

I figured out what was happening here - there was a reference to
another page that would have been broken in the PDF, so it failed the
"check-links-and-anchors" validation step. I pushed a fix for this a
little bit ago.

On Wed, Jun 21, 2017 at 6:09 AM, Apache Jenkins Server
 wrote:
> Build: https://builds.apache.org/job/Solr-reference-guide-master/44/
>
> Log:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on H20 (git-websites) in workspace 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
> Cloning the remote Git repository
> Cloning repository git://git.apache.org/lucene-solr.git
>  > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master 
> # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>  > git --version # timeout=10
>  > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
> +refs/heads/*:refs/remotes/origin/*
>  > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
> timeout=10
>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
> timeout=10
>  > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
> timeout=10
> Cleaning workspace
>  > git rev-parse --verify HEAD # timeout=10
> No valid HEAD. Skipping the resetting
>  > git clean -fdx # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>  > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision 44d1f1fe3fe2bdc0210d065965eb30bc467623ca 
> (refs/remotes/origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 44d1f1fe3fe2bdc0210d065965eb30bc467623ca
>  > git rev-list 4746ff0ec8a008d42a44c6e6dd3e94cbb2886410 # timeout=10
> No emails were triggered.
> [Solr-reference-guide-master] $ /bin/bash -xe 
> /tmp/hudson7695543379996650175.sh
> + echo 'Set ruby path to avoid writing to /usr directory'
> Set ruby path to avoid writing to /usr directory
> + export RUBY_PATH=/home/jenkins/shared/.rvm
> + RUBY_PATH=/home/jenkins/shared/.rvm
> + export GEM_HOME=/home/jenkins/shared/.rvm/gems
> + GEM_HOME=/home/jenkins/shared/.rvm/gems
> + curl -sSL https://get.rvm.io
> + bash -s -- --path /home/jenkins/shared/.rvm
> Downloading https://github.com/rvm/rvm/archive/master.tar.gz
>
> Upgrading the RVM installation in /home/jenkins/shared/.rvm/
> RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
> /home/jenkins/.bashrc /home/jenkins/.zshrc.
> RVM sourcing line found in /home/jenkins/.profile 
> /home/jenkins/.bash_profile /home/jenkins/.zlogin.
> Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
>
> Upgrade Notes:
>
>   * It looks like some old stuff is laying around RVM, you can cleanup with: 
> rvm cleanup all
>
>   * No new notes to display.
>
> + mkdir -p /home/jenkins/shared/.rvm/gems/gems
> + gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
> jekyll-asciidoc pygments.rb
> Successfully installed sass-3.4.24
> Successfully installed rb-inotify-0.9.10
> Successfully installed liquid-4.0.0
> Successfully installed jekyll-3.5.0
> Successfully installed jekyll-asciidoc-2.1.0
> Successfully installed pygments.rb-1.1.2
> 6 gems installed
> + export 
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + 
> PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
> + cd solr/solr-ref-guide
> + ant clean build-pdf build-site
> Buildfile: 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml
>
> clean:
>
> build-init:
> [mkdir] Created dir: 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
>  [echo] Copying all non template files from src ...
>  [copy] Copying 343 files to 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
>  [echo] Copy (w/prop replacement) any template files from src...
>  [copy] Copying 1 file to 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
>
> ivy-availability-check:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
> http://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file = 
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml
>
> resolve:
> [ivy:retrieve] downloading 
> 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4094 - Still Unstable!

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([93D5CBE9C28123C:7C309CA28C32D4E9]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10864:

Attachment: SOLR-10864.patch

patch updated with all import/jdoc fixes needed to pass precommit

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch, 
> SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1888 - Still Unstable

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([154670DFF5F99A43:604BB0C3E5E35C96]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=7474, 

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+173) - Build # 19926 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19926/
Java: 32bit/jdk-9-ea+173 -server -XX:+UseG1GC

8 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.CdcrVersionReplicationTest: 1) Thread[id=13912, 
name=cdcr-update-log-synchronizer-6406-thread-1, state=WAITING, 
group=TGRP-CdcrVersionReplicationTest] at 
java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119)
 at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9-ea/java.lang.Thread.run(Thread.java:844)2) 
Thread[id=13900, name=cdcr-update-log-synchronizer-6400-thread-1, 
state=WAITING, group=TGRP-CdcrVersionReplicationTest] at 
java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
 at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119)
 at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@9-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.cloud.CdcrVersionReplicationTest: 
   1) Thread[id=13912, name=cdcr-update-log-synchronizer-6406-thread-1, 
state=WAITING, group=TGRP-CdcrVersionReplicationTest]
at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119)
at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@9-ea/java.lang.Thread.run(Thread.java:844)
   2) Thread[id=13900, name=cdcr-update-log-synchronizer-6400-thread-1, 
state=WAITING, group=TGRP-CdcrVersionReplicationTest]
at java.base@9-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@9-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@9-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062)
at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1119)
at 
java.base@9-ea/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:848)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1086)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.base@9-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@9-ea/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([25A18B9435646E6C]:0)


FAILED:  

[jira] [Commented] (SOLR-8256) Set legacyCloud=false as default

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8256:



Some more that reproduce with 8e9d685a402 checked out but not eff583ee8 ...

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=CollectionsAPISolrJTest -Dtests.method=testClusterProp 
-Dtests.seed=768F60D350C74DB5 -Dtests.slow=true -Dtests.locale=ru-RU 
-Dtests.timezone=Europe/Minsk -Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.06s | CollectionsAPISolrJTest.testClusterProp <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Expecting legacyCloud 
to false as default expected: but was:

   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestLTROnSolrCloud 
-Dtests.method=testSimpleQuery -Dtests.seed=BE3933A5AB868831 -Dtests.slow=true 
-Dtests.locale=ja-JP -Dtests.timezone=Etc/GMT-9 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   30.1s | TestLTROnSolrCloud.testSimpleQuery <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Path not found: 
/responseHeader/status

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=UnloadDistributedZkTest -Dtests.method=test 
-Dtests.seed=768F60D350C74DB5 -Dtests.slow=true -Dtests.locale=es-VE 
-Dtests.timezone=Atlantic/Reykjavik -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   24.2s | UnloadDistributedZkTest.test <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([768F60D350C74DB5:FEDB5F09FE3B204D]:0)
   [junit4]>at 
org.apache.solr.cloud.UnloadDistributedZkTest.testCoreUnloadAndLeaders(UnloadDistributedZkTest.java:171

{noformat}


> Set legacyCloud=false as default
> 
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, 
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this 
> mostly unknown setting and start defaulting to this behavior that starts us 
> down the path of zk=truth.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7868:


I was unable to make writing of live docs files and new doc values files 
concurrent here: IW's concurrency is just too messy.

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-7868.

Resolution: Fixed

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[ASF subversion and git services (JIRA)]

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

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

Commit 58105a203a19d18a56e09cf69dc0083c1b890315 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=58105a2 ]

LUCENE-7868: use multiple threads to concurrently resolve deletes and DV udpates


> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7883:
---

Unfortunately the latest test failures on master make it hard to differentiate 
between failures caused by my changes and ones already there. But all failures 
in tests that I see here, look like the ones Jenkins is drinking with his beers!

This is not a good state, the test suite should pass for a clean checkout.

> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of 
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug 
> caused by sloppy usage of ClassLoader APIs and should be replaced by 
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be 
> solved by removing the "default" constructor. It only affects CustomAnalyzer, 
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by 
> {{getClass().getClassLoader()}} (except some workaround with clustering using 
> a try-finally). This is in most cases historical code, when Solr was a web 
> application to workaround some buggy webapp containers. In the current state, 
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to 
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7883:
---

I did some live test with the standalone techproducts example. I have seen no 
issues, so I think this should be fine to commit. I will add a CHANGES entry in 
both Lucene and Solr, because this affects both projects.

> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of 
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug 
> caused by sloppy usage of ClassLoader APIs and should be replaced by 
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be 
> solved by removing the "default" constructor. It only affects CustomAnalyzer, 
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by 
> {{getClass().getClassLoader()}} (except some workaround with clustering using 
> a try-finally). This is in most cases historical code, when Solr was a web 
> application to workaround some buggy webapp containers. In the current state, 
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to 
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8256) Set legacyCloud=false as default

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8256:


I'm seeing a bunch of test failures on master that seem related to commit 
8e9d685a402c03d6bf0691d79ae5030f38f09053 ... these don't reproduce if i revert 
to the previous commit (eff583e) ...

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=LeaderElectionIntegrationTest 
-Dtests.method=testSimpleSliceLeaderElection -Dtests.seed=26F0B7AA3C40D7A2 
-Dtests.slow=true -Dtests.locale=bg -Dtests.timezone=Asia/Kolkata 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=CdcrVersionReplicationTest -Dtests.seed=26F0B7AA3C40D7A2 
-Dtests.slow=true -Dtests.locale=ar-OM -Dtests.timezone=Asia/Jakarta 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitWithChaosMonkey -Dtests.seed=26F0B7AA3C40D7A2 
-Dtests.slow=true -Dtests.locale=fi-FI -Dtests.timezone=SystemV/EST5 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
{noformat}




> Set legacyCloud=false as default
> 
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, 
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this 
> mostly unknown setting and start defaulting to this behavior that starts us 
> down the path of zk=truth.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: [1/2] lucene-solr:master: SOLR-8256: Set legacyCloud=false as default

[Chris Hostetter]

FWIW: I'm seeing a bunch of test failures that look suspiciously related 
to this commit  i'll post details in jira.


: Date: Wed, 21 Jun 2017 15:26:00 -
: From: da...@apache.org
: Reply-To: dev@lucene.apache.org
: To: comm...@lucene.apache.org
: Subject: [1/2] lucene-solr:master: SOLR-8256: Set legacyCloud=false as default
: 
: Repository: lucene-solr
: Updated Branches:
:   refs/heads/master eff583ee8 -> 8e9d685a4
: 
: 
: 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/8e9d685a/solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
: --
: diff --git a/solr/core/src/test/org/apache/solr/cloud/OverseerTest.java 
b/solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
: index 2d327a2..f6abb54 100644
: --- a/solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
: +++ b/solr/core/src/test/org/apache/solr/cloud/OverseerTest.java
: @@ -29,7 +29,6 @@ import java.util.List;
:  import java.util.Locale;
:  import java.util.Map;
:  import java.util.Set;
: -import java.util.concurrent.ExecutorService;
:  import java.util.concurrent.TimeUnit;
:  import java.util.concurrent.TimeoutException;
:  import java.util.concurrent.atomic.AtomicInteger;
: @@ -47,13 +46,11 @@ import org.apache.solr.common.cloud.SolrZkClient;
:  import org.apache.solr.common.cloud.ZkNodeProps;
:  import org.apache.solr.common.cloud.ZkStateReader;
:  import org.apache.solr.common.params.CollectionParams;
: -import org.apache.solr.common.util.ExecutorUtil;
:  import org.apache.solr.common.util.Utils;
:  import org.apache.solr.core.CloudConfig;
:  import org.apache.solr.handler.component.HttpShardHandlerFactory;
:  import org.apache.solr.update.UpdateShardHandler;
:  import org.apache.solr.update.UpdateShardHandlerConfig;
: -import org.apache.solr.util.DefaultSolrThreadFactory;
:  import org.apache.zookeeper.CreateMode;
:  import org.apache.zookeeper.KeeperException;
:  import org.apache.zookeeper.KeeperException.NoNodeException;
: @@ -131,8 +128,20 @@ public class OverseerTest extends SolrTestCaseJ4 {
:zkStateReader.close();
:zkClient.close();
:  }
: -
: -public String publishState(String collection, String coreName, String 
coreNodeName, Replica.State stateName, int numShards)
: +
: +public void createCollection(String collection, int numShards) throws 
KeeperException, InterruptedException {
: +
: +  ZkNodeProps m = new ZkNodeProps(Overseer.QUEUE_OPERATION, 
CollectionParams.CollectionAction.CREATE.toLower(),
: +  "name", collection,
: +  ZkStateReader.REPLICATION_FACTOR, "1",
: +  ZkStateReader.NUM_SHARDS_PROP, numShards+"",
: +  "createNodeSet", "");
: +  DistributedQueue q = Overseer.getStateUpdateQueue(zkClient);
: +  q.offer(Utils.toJSON(m));
: +
: +}
: +
: +public String publishState(String collection, String coreName, String 
coreNodeName, String shard, Replica.State stateName, int numShards)
:  throws KeeperException, InterruptedException, IOException {
:if (stateName == null) {
:  ElectionContext ec = electionContext.remove(coreName);
: @@ -144,22 +153,23 @@ public class OverseerTest extends SolrTestCaseJ4 {
:  ZkStateReader.CORE_NAME_PROP, coreName,
:  ZkStateReader.CORE_NODE_NAME_PROP, coreNodeName,
:  ZkStateReader.COLLECTION_PROP, collection);
: -DistributedQueue q = Overseer.getStateUpdateQueue(zkClient);
: -q.offer(Utils.toJSON(m));
: - return null;
: +DistributedQueue q = Overseer.getStateUpdateQueue(zkClient);
: +q.offer(Utils.toJSON(m));
: +return null;
:} else {
:  ZkNodeProps m = new ZkNodeProps(Overseer.QUEUE_OPERATION, 
OverseerAction.STATE.toLower(),
: -ZkStateReader.STATE_PROP, stateName.toString(),
: -ZkStateReader.NODE_NAME_PROP, nodeName,
: -ZkStateReader.CORE_NAME_PROP, coreName,
: -ZkStateReader.CORE_NODE_NAME_PROP, coreNodeName,
: -ZkStateReader.COLLECTION_PROP, collection,
: -ZkStateReader.NUM_SHARDS_PROP, Integer.toString(numShards),
: -ZkStateReader.BASE_URL_PROP, "http://; + nodeName + "/solr/");
: +ZkStateReader.STATE_PROP, stateName.toString(),
: +ZkStateReader.NODE_NAME_PROP, nodeName,
: +ZkStateReader.CORE_NAME_PROP, coreName,
: +ZkStateReader.CORE_NODE_NAME_PROP, coreNodeName,
: +ZkStateReader.COLLECTION_PROP, collection,
: +ZkStateReader.SHARD_ID_PROP, shard,
: +ZkStateReader.NUM_SHARDS_PROP, Integer.toString(numShards),
: +ZkStateReader.BASE_URL_PROP, "http://; + nodeName + "/solr/");
:  DistributedQueue q = Overseer.getStateUpdateQueue(zkClient);
:  q.offer(Utils.toJSON(m));
:}
: -  
: +
:if (collection.length() > 0) {
:  for (int i = 0; i < 120; i++) {
:String shardId = 

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+173) - Build # 6668 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6668/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseSerialGC

7 tests failed.
FAILED:  org.apache.solr.ltr.TestLTROnSolrCloud.testSimpleQuery

Error Message:
Path not found: /responseHeader/status

Stack Trace:
java.lang.RuntimeException: Path not found: /responseHeader/status
at 
__randomizedtesting.SeedInfo.seed([610A1930F7FD61CA:1407D92CE7E7A71F]:0)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:329)
at org.apache.solr.util.RestTestBase.assertJPut(RestTestBase.java:271)
at 
org.apache.solr.ltr.TestRerankBase.loadFeature(TestRerankBase.java:286)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.loadModelsAndFeatures(TestLTROnSolrCloud.java:184)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setupSolrCluster(TestLTROnSolrCloud.java:138)
at 
org.apache.solr.ltr.TestLTROnSolrCloud.setUp(TestLTROnSolrCloud.java:58)
at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:941)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrVersionReplicationTest

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.cloud.CdcrVersionReplicationTest: 1) 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+173) - Build # 3807 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3807/
Java: 64bit/jdk-9-ea+173 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:
--> https://127.0.0.1:33977/w/xp/collection1:Failed to execute sqlQuery 'select 
str_s, count(*), sum(field_i), min(field_i), max(field_i), avg(field_i) from 
collection1 where text='' group by str_s order by sum(field_i) asc limit 2' 
against JDBC connection 'jdbc:calcitesolr:'. Error while executing SQL "select 
str_s, count(*), sum(field_i), min(field_i), max(field_i), avg(field_i) from 
collection1 where text='' group by str_s order by sum(field_i) asc limit 
2": From line 1, column 39 to line 1, column 50: No match found for function 
signature min()

Stack Trace:
java.io.IOException: --> https://127.0.0.1:33977/w/xp/collection1:Failed to 
execute sqlQuery 'select str_s, count(*), sum(field_i), min(field_i), 
max(field_i), avg(field_i) from collection1 where text='' group by str_s 
order by sum(field_i) asc limit 2' against JDBC connection 'jdbc:calcitesolr:'.
Error while executing SQL "select str_s, count(*), sum(field_i), min(field_i), 
max(field_i), avg(field_i) from collection1 where text='' group by str_s 
order by sum(field_i) asc limit 2": From line 1, column 39 to line 1, column 
50: No match found for function signature min()
at 
__randomizedtesting.SeedInfo.seed([7D2A2AEE2CD69927:DA6E924A416D8A9E]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:233)
at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2527)
at 
org.apache.solr.handler.TestSQLHandler.testBasicGrouping(TestSQLHandler.java:676)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:90)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Updated] (SOLR-10864) Add static (test only) boolean to PointField indicating 'precisionStep' should be ignored so we can simplify points randomization in our schemas

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10864:

Attachment: SOLR-10864.patch

updated patch to account for SOLR-10929 ... still testing but this should at 
least apply cleanly against current trunk

> Add static (test only) boolean to PointField indicating 'precisionStep' 
> should be ignored so we can simplify points randomization in our schemas
> 
>
> Key: SOLR-10864
> URL: https://issues.apache.org/jira/browse/SOLR-10864
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
> Attachments: SOLR-10864.patch, SOLR-10864.patch, SOLR-10864.patch, 
> SOLR-10864.patch, SOLR-10864.patch
>
>
> (I'm spinning this idea out of parent jira SOLR-10807 so that it gets it's 
> own jira# w/ it's own summary for increased visibility/comments)
> In the interest of making it easier & more straight forward to get good 
> randomized test coverage of Points fields, I'd like to add the following to 
> the {{PointField}} class...
> {code}
>  /**
>   * 
>   * The Test framework can set this global variable to instruct PointField 
> that
>   * (on init) it should be tollerant of the precisionStep 
> argument used by TrieFields.
>   * This allows for simple randomization of TrieFields and PointFields w/o 
> extensive duplication
>   * of fieldType/ declarations.
>   * 
>   *
>   * NOTE: When {@link TrieField} is removed, this boolean must also be 
> removed
>   *
>   * @lucene.internal
>   * @lucene.experimental
>   */
>  public static boolean TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS = false;
>  /** 
>   * NOTE: This method can be removed completely when
>   * {@link #TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS} is removed 
>   */
>  @Override
>  protected void init(IndexSchema schema, Map args) {
>super.init(schema, args);
>if (TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS) {
>  args.remove("precisionStep");
>}
>  }
> {code}
> Then in SolrTestCaseJ4, set 
> {{PointField.TEST_HACK_IGNORE_USELESS_TRIEFIELD_ARGS}} on a class by class 
> basis when randomizing Trie/Points (and unset \@AfterClass).
> (details to follow in comment)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10929) remove useless valType from ExternalFileField

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10929.
-
   Resolution: Fixed
Fix Version/s: master (7.0)

> remove useless valType from ExternalFileField
> -
>
> Key: SOLR-10929
> URL: https://issues.apache.org/jira/browse/SOLR-10929
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: master (7.0)
>
>
> {{valType}} has always been a useless prop on ExternalFileField. 
> SOLR-2971 made it optional, but if specified it must be a TrieFloatField or 
> else there is a failure.
> We should just eliminate it completely in 7.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10929) remove useless valType from ExternalFileField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10929:


Commit 1737fce5df106847fb5d93eb46ba7b062072c589 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1737fce ]

SOLR-10929: Removed unused 'valType' option from ExternalFileField


> remove useless valType from ExternalFileField
> -
>
> Key: SOLR-10929
> URL: https://issues.apache.org/jira/browse/SOLR-10929
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> {{valType}} has always been a useless prop on ExternalFileField. 
> SOLR-2971 made it optional, but if specified it must be a TrieFloatField or 
> else there is a failure.
> We should just eliminate it completely in 7.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-10930.
--
Resolution: Fixed

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10930:


Commit 1799474 from [~ctargett] in branch 'cms/trunk'
[ https://svn.apache.org/r1799474 ]

SOLR-10930: refine redirect rule so it only applies to beginning of URL path

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on SOLR-10930 at 6/21/17 3:54 PM:


{{/java($|/.*)}} still isn’t completely right though, since it’ll match 
trailing {{/java(/whatever)}} instead of restricting to the beginning of the 
path.

Judging from the example here 
[https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch] the 
{{RedirectMatch}} regex applies to the path (not the whole url), so adding a 
{{\^}} to the beginning of the regex should restrict it properly: 
{{^/java($|/.*)}}

(The initial regex I gave should work for the problem at hand; adding the caret 
should protect against future paths with {{/java/}} in the middle.)


was (Author: steve_rowe):
{{/java($|/.*)}} still isn’t completely right though, since it’ll match 
trailing {{/java(/whatever)}} instead of restricting to the beginning of the 
path.

Judging from the example here 
[https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch] the 
{{RedirectMatch}} regex applies to the path (not the whole url), so adding a 
{{\^}} to the beginning of the regex should restrict it properly: 
{{^/java($|/.*)}}

(The initial regex I gave should work for the problem at hand; adding the caret 
should protect against future paths with {{/java/}} in the middle.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10930:
--

OK, I'll add that to the rule just to protect against something weird again in 
the future.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10930:
---

{{/java($|/.*)}} still isn’t completely right though, since it’ll match 
trailing {{/java(/whatever)}} instead of restricting to the beginning of the 
path.

Judging from the example here 
[https://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirectmatch] the 
{{RedirectMatch}} regex applies to the path (not the whole url), so adding a 
{{\^}} to the beginning of the regex should restrict it properly: 
{{^/java($|/.*)}}

(The initial regex I gave should work for the problem at hand; adding the caret 
should protect against future paths with {{/java/}} in the middle.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10930:
--

Changing the Redirect rule in {{.htaccess}} as Steve suggested fixed the 
problem. 

I also verified that an URL like {{https://lucene.apache.org/java}}, which is 
what the rule was intended for, properly redirects to 
{{https://lucene.apache.org/core/}}.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10889) Stale zookeper information is used during failover check

[Mihaly Toth (JIRA)]

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

Mihaly Toth commented on SOLR-10889:


bq. The only counter argument that comes into my mind is too frequent reading 
of the cluster state. We can enhance this naive solution so that re-reading is 
done only if a bad node is found. But I am not sure if such a read optimization 
is necessary.
Actually, looking into {{ZkStateReader}} there is no network activity involved 
when reading the cluster state. So there is not much counter argument against 
using the most latest cluster state instead of a stale one.

> Stale zookeper information is used during failover check
> 
>
> Key: SOLR-10889
> URL: https://issues.apache.org/jira/browse/SOLR-10889
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (7.0)
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Attachments: SOLR-10889.patch
>
>
> In {{OverseerAutoReplicaFailoverThread}} it goes over each and every replica 
> to check if it needs to be reloaded on a new node. In each such round it 
> reads cluster state just in the beginning. Especially in case of big 
> clusters, cluster state may change during the process of iterating through 
> the replicas. As a result false decisions may be made: restarting a healthy 
> core, or not handling a bad node.
> The code fragment in question:
> {code}
> for (Slice slice : slices) {
>   if (slice.getState() == Slice.State.ACTIVE) {
> final Collection downReplicas = new 
> ArrayList();
> int goodReplicas = findDownReplicasInSlice(clusterState, 
> docCollection, slice, downReplicas);
> {code}
> The solution seems rather straightforward, reading the state every time:
> {code}
> int goodReplicas = 
> findDownReplicasInSlice(zkStateReader.getClusterState(), docCollection, 
> slice, downReplicas);
> {code}
> The only counter argument that comes into my mind is too frequent reading of 
> the cluster state. We can enhance this naive solution so that re-reading is 
> done only if a bad node is found. But I am not sure if such a read 
> optimization is necessary.
> I have done some unit tests around this class, mocking out even the time 
> factor. It runs in a second. I am interested in getting feedback about such 
> an approach. I will upload a patch with this shortly.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10406:
--
Attachment: SOLR-10406.patch

> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch, SOLR-10406.patch, 
> SOLR-10406.patch, SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on;
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8256) Set legacyCloud=false as default

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8256: Set legacyCloud=false as default


> Set legacyCloud=false as default
> 
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, 
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this 
> mostly unknown setting and start defaulting to this behavior that starts us 
> down the path of zk=truth.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10930:
---

I think the idea is for {{/java}} or {{/java/}} or {{/java/whatever}} to match, 
so we could try redoing the regex to something like {{/java($|/.*)}}, which 
should not cause this problem.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10930:
--

The problem is the website has a redirect rule like this: {{RedirectMatch 
Permanent /java(.*) /core$1}} and the page {{java-properties.html}} matches 
that regular expression. We either need to update the regex or rename the page 
(the latter probably being easier).


> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10930:
--

This is really strange. I'm working on fixing it.

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-8256) Set legacyCloud=false as default

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8256:
---
Attachment: SOLR-8256.patch

Final patch ( will commit soon ), ant precommit passed.

> Set legacyCloud=false as default
> 
>
> Key: SOLR-8256
> URL: https://issues.apache.org/jira/browse/SOLR-8256
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Cao Manh Dat
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, 
> SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch, SOLR-8256.patch
>
>
> We don't have the old back compat concerns anymore. It's time to remove this 
> mostly unknown setting and start defaulting to this behavior that starts us 
> down the path of zk=truth.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Solr JSON Facet API & aggregation functions documentation

[Cassandra Targett]

Bram,

If you open a JIRA issue for the effort, I will make sure the existing
doc is converted into the new AsciiDoc format and upload it there for
you to build from.

Cassandra

On Wed, Jun 21, 2017 at 1:33 AM, Bram Van Dam  wrote:
> On 19/06/17 17:38, Erick Erickson wrote:
>> We've recently gone to AsciiDoc which is much easier to edit IMO, and
>> also allows anyone (hint hint) to attach a patch to a JIRA for the
>> documentation that makes it into the next version of reference guide
>> as well as the current online version.
>
> Hint taken, I'll see what I can do. I have to document some of the
> functions (hll and others) for use in our application anyway, so I might
> as well see if I can take it a bit further.
>
>  - Bram
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Assigned] (SOLR-10930) Ref Guide for Java Properties redirect to invalid page

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-10930:


Assignee: Cassandra Targett

> Ref Guide for Java Properties redirect to invalid page
> --
>
> Key: SOLR-10930
> URL: https://issues.apache.org/jira/browse/SOLR-10930
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Mykhailo Kozik
>Assignee: Cassandra Targett
>Priority: Minor
>
> When clicking on "Java Properties" paragraph from the ref guide
> http://lucene.apache.org/solr/guide/6_6/java-properties.html
> it redirects to non-existent page
> http://lucene.apache.org/core-properties.html
> !http://i.imgur.com/1DxLZJX.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7868:


Thanks [~simonw]; I'll run tests and push soon.

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10933) LetStream variables are not evaluated in proper order

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10933:
--

You saved my day, Joel. I was struggling on this bit and after noticing this 
issue, i changed my variables to single alphabet the problem disappeared.

let(a=fetch(collection1,having(rollup(over=email,
 count(email),
select(search(collection1,
q=*:*,
fl="id,business_email",
sort="business_email asc"),
   id,
   business_email as email)),
eq(count(email),1)),
fl="id,business_email as email",
on="email=business_email"),
b=fetch(collection1,having(rollup(over=email,
 count(email),
select(search(collection1,
q=*:*,
fl="id,personal_email",
sort="personal_email asc"),
   id,
   personal_email as email)),
eq(count(email),1)),
fl="id,personal_email as email",
on="email=personal_email"),
c=hashJoin(get(a),hashed=get(b),on="email"),
d=hashJoin(get(b),hashed=get(a),on="email"),
e=select(get(a),id,email),
get(e)
)

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 377 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/377/

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:50095/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:54890/solr/test_col_shard2_replica1: Server Errorrequest: 
http://127.0.0.1:54890/solr/test_col_shard2_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A50095%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:42713/solr/test_col_shard2_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@21357254

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:50095/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:54890/solr/test_col_shard2_replica1: Server Error



request: 
http://127.0.0.1:54890/solr/test_col_shard2_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A50095%2Fsolr%2Ftest_col_shard5_replica1%2F=javabin=2
Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:42713/solr/test_col_shard2_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@21357254
at 
__randomizedtesting.SeedInfo.seed([3CDFB00F0E4D1BDC:ACBD249841021CD]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-7868:
-

LGTM thanks for all the iterations

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Review Request 60154: LUCENE-7868: Concurrent deletes and doc values updates

[Simon Willnauer]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60154/#review178493
---


Ship it!




Ship It!

- Simon Willnauer


On June 21, 2017, 10:04 a.m., Mike McCandless wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60154/
> ---
> 
> (Updated June 21, 2017, 10:04 a.m.)
> 
> 
> Review request for lucene.
> 
> 
> Repository: lucene-solr
> 
> 
> Description
> ---
> 
> Today Lucene uses a single thread to resolve buffered delete/update terms to 
> actual docIDs, but this is a costly process.  This change uses multiple 
> threads (the incoming indexing threads) to resolve terms concurrently.
> 
> Jira issue: https://issues.apache.org/jira/browse/LUCENE-7868
> 
> 
> Diffs
> -
> 
>   
> lucene/core/src/java/org/apache/lucene/index/BinaryDocValuesFieldUpdates.java 
> f8cece9 
>   lucene/core/src/java/org/apache/lucene/index/BufferedUpdates.java 1c3494f 
>   lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java 
> 9955626 
>   lucene/core/src/java/org/apache/lucene/index/CoalescedUpdates.java bf92ac1 
>   lucene/core/src/java/org/apache/lucene/index/DocValuesFieldUpdates.java 
> 528d4bf 
>   lucene/core/src/java/org/apache/lucene/index/DocValuesUpdate.java 1c85f33 
>   lucene/core/src/java/org/apache/lucene/index/DocumentsWriter.java 2807517 
>   
> lucene/core/src/java/org/apache/lucene/index/DocumentsWriterDeleteQueue.java 
> db0e571 
>   
> lucene/core/src/java/org/apache/lucene/index/DocumentsWriterFlushControl.java 
> a5b4b7c 
>   lucene/core/src/java/org/apache/lucene/index/DocumentsWriterFlushQueue.java 
> 2c62487 
>   lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThread.java 
> c929ba2 
>   
> lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThreadPool.java
>  cc72342 
>   lucene/core/src/java/org/apache/lucene/index/FlushByRamOrCountsPolicy.java 
> a85c98b 
>   lucene/core/src/java/org/apache/lucene/index/FlushPolicy.java e70959f 
>   lucene/core/src/java/org/apache/lucene/index/FreqProxTermsWriter.java 
> 1ca2830 
>   lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java 
> 4f482ad 
>   lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java f7f196d 
>   lucene/core/src/java/org/apache/lucene/index/IndexWriter.java 14fbbae 
>   lucene/core/src/java/org/apache/lucene/index/IndexWriterConfig.java 0fdbc3e 
>   lucene/core/src/java/org/apache/lucene/index/LiveIndexWriterConfig.java 
> d9e1bc7 
>   
> lucene/core/src/java/org/apache/lucene/index/MergedPrefixCodedTermsIterator.java
>  cd14eec 
>   
> lucene/core/src/java/org/apache/lucene/index/NumericDocValuesFieldUpdates.java
>  4dd3cd0 
>   lucene/core/src/java/org/apache/lucene/index/PrefixCodedTerms.java df1653b 
>   lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java d4dd4a4 
>   lucene/core/src/java/org/apache/lucene/index/SegmentCommitInfo.java b1084a6 
>   lucene/core/src/java/org/apache/lucene/index/SegmentCoreReaders.java 
> ce2d448 
>   lucene/core/src/java/org/apache/lucene/index/SegmentInfo.java 1c02441 
>   lucene/core/src/java/org/apache/lucene/index/SegmentReader.java c8235d5 
>   lucene/core/src/java/org/apache/lucene/index/SerialMergeScheduler.java 
> 5a8f98b 
>   lucene/core/src/java/org/apache/lucene/index/TieredMergePolicy.java 668f1ec 
>   
> lucene/core/src/java/org/apache/lucene/util/packed/AbstractPagedMutable.java 
> c5fac1e 
>   
> lucene/core/src/test/org/apache/lucene/index/TestBinaryDocValuesUpdates.java 
> ed2b66f 
>   
> lucene/core/src/test/org/apache/lucene/index/TestDocumentsWriterDeleteQueue.java
>  c60f54d 
>   
> lucene/core/src/test/org/apache/lucene/index/TestFlushByRamOrCountsPolicy.java
>  aa2901c 
>   lucene/core/src/test/org/apache/lucene/index/TestForceMergeForever.java 
> 0379395 
>   lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java 6897f06 
>   lucene/core/src/test/org/apache/lucene/index/TestIndexWriterConfig.java 
> 2014c16 
>   lucene/core/src/test/org/apache/lucene/index/TestIndexWriterDelete.java 
> 25817d9 
>   lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java 
> c0907a5 
>   lucene/core/src/test/org/apache/lucene/index/TestIndexWriterReader.java 
> 584e03c 
>   lucene/core/src/test/org/apache/lucene/index/TestNRTReaderWithThreads.java 
> 871715f 
>   
> lucene/core/src/test/org/apache/lucene/index/TestNumericDocValuesUpdates.java 
> 94da587 
>   lucene/core/src/test/org/apache/lucene/index/TestPerSegmentDeletes.java 
> 112a108 
>   lucene/core/src/test/org/apache/lucene/index/TestPrefixCodedTerms.java 
> 89d4ad1 
>   
> lucene/core/src/test/org/apache/lucene/search/TestControlledRealTimeReopenThread.java
>  a1b2a5c 
>   

[jira] [Updated] (SOLR-10406) v2 API error messages list the URL request path as /solr/____v2/... when the original path was /v2/...

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-10406:
--
Attachment: SOLR-10406.patch

The new exception is now called {{RemoteExecutionException}}

> v2 API error messages list the URL request path as /solr/v2/... when the 
> original path was /v2/...
> --
>
> Key: SOLR-10406
> URL: https://issues.apache.org/jira/browse/SOLR-10406
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-10406.patch, SOLR-10406.patch, SOLR-10406.patch, 
> SOLR-10406.patch
>
>
> E.g. attempting introspect on {{/v2/c/.system/blob}} will fail if the 
> {{.system}} collection has not yet been CREATE'd - after {{bin/solr start -e 
> cloud -noprompt}}:
> {noformat}
> $ curl "http://localhost:8983/v2/c/.system/blob/_introspect?indent=on;
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/c/.system/blob/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-10317:


bq. It changed after identifying and handling resource contention
What was the resource contention?

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-10933:
-

Assignee: Joel Bernstein

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10933:
--
Fix Version/s: 6.7

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10933) LetStream variables are not evaluated in proper order

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10933:


Commit adfaf340e027ac73a672f6916f0e9be72cd9e3d1 in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=adfaf34 ]

SOLR-10933: LetStream variables are not evaluated in proper order


> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10933) LetStream variables are not evaluated in proper order

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10933:


Commit eff583ee889e4098ff0f5debb3a05ec09b2e7b19 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=eff583e ]

SOLR-10933: LetStream variables are not evaluated in proper order


> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10933:
--
Fix Version/s: master (7.0)

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10931) Resolve conflicting package names o.a.s.cloud.autoscaling

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10931:


A majority of SolrJ packages start with {{org.apache.solr.client.solrj}} (18 
packages).  Only a relative few (5 packages) branch off before the 
{{client.solrj}} section.

Anyone have any objections to changing the SolrJ autoscaling package name to 
{{org.apache.solr.client.solrj}}?  It'd keep it better aligned with what seems 
to be the convention.

> Resolve conflicting package names o.a.s.cloud.autoscaling
> -
>
> Key: SOLR-10931
> URL: https://issues.apache.org/jira/browse/SOLR-10931
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> At the moment, o.a.s.cloud.autoscaling is in core as well as in solrj modules.
> As per following comments, I think we should change them to different package 
> names:
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15658266=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15658266
> https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15654160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15654160
> Currently, the Eclipse project is broken on master due to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10933:
--
Attachment: SOLR-10933.patch

Simple fix and change to a test case to verify the variables are being 
evaluated in order.

> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10933.patch
>
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10933:
--
Description: 
The LetStream is currently using a HashMap to hold its variable mappings. This 
is problematic because the ordering of the variables will be lost as they are 
evaluated. The test cases pass currently because single letter variables in 
ascending order are used which by luck caused the variables to be evaluated in 
order.

There is a very simple fix for this which is to use a LinkedHashMap to hold the 
variables to ensure they are evaluated in the order that they are received.

  was:
The LetStream is currently using a HashMap to hold its variable mappings. This 
is problematic because the ordering of the variables will lost as they are 
evaluated. The test cases pass currently because single letter variables in 
ascending order are used which by luck caused the variables to be evaluated in 
order.

There is a very simple fix for this which is to use a LinkedHashMap to hold the 
variables to ensure they are evaluated in the order that they are received.


> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will be lost as 
> they are evaluated. The test cases pass currently because single letter 
> variables in ascending order are used which by luck caused the variables to 
> be evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10933:
-

 Summary: LetStream variables are not evaluated in proper order
 Key: SOLR-10933
 URL: https://issues.apache.org/jira/browse/SOLR-10933
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


The LetStream is currently using a HashMap to hold it variable mappings. This 
is problematic because the ordering of the variables will lost as they are 
evaluated. The test cases pass currently because single letter variables in 
ascending order are used which by luck caused the variables to be evaluated in 
order.

There is a very simple fix for this which is to use a LinkedHashMap to hold the 
variables to ensure they are evaluated in the order that they are received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10933) LetStream variables are not evaluated in proper order

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10933:
--
Description: 
The LetStream is currently using a HashMap to hold its variable mappings. This 
is problematic because the ordering of the variables will lost as they are 
evaluated. The test cases pass currently because single letter variables in 
ascending order are used which by luck caused the variables to be evaluated in 
order.

There is a very simple fix for this which is to use a LinkedHashMap to hold the 
variables to ensure they are evaluated in the order that they are received.

  was:
The LetStream is currently using a HashMap to hold it variable mappings. This 
is problematic because the ordering of the variables will lost as they are 
evaluated. The test cases pass currently because single letter variables in 
ascending order are used which by luck caused the variables to be evaluated in 
order.

There is a very simple fix for this which is to use a LinkedHashMap to hold the 
variables to ensure they are evaluated in the order that they are received.


> LetStream variables are not evaluated in proper order
> -
>
> Key: SOLR-10933
> URL: https://issues.apache.org/jira/browse/SOLR-10933
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The LetStream is currently using a HashMap to hold its variable mappings. 
> This is problematic because the ordering of the variables will lost as they 
> are evaluated. The test cases pass currently because single letter variables 
> in ascending order are used which by luck caused the variables to be 
> evaluated in order.
> There is a very simple fix for this which is to use a LinkedHashMap to hold 
> the variables to ensure they are evaluated in the order that they are 
> received.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7885) Inconsistent return of documents in TermsEnum.postings after unsuccesful TermsEnum.seekExact(bytes)

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7885.
--
Resolution: Invalid

Right, the behaviour is undefined in that case. Documentation for {{seekExact}} 
states: {{Attempts to seek to the exact term, returning true if the term is 
found.  If this returns false, the enum is unpositioned.}} and documentation 
for {{postings}} states {{Do not call this when the enum is unpositioned}}. If 
you want to go to the next term when a term is not found, maybe you should use 
{{seekCeil}} instead?

For the record, you might want to consider using {{AssertingDirectoryReader}} 
in your tests, which would detect this kind of issues.

> Inconsistent return of documents in TermsEnum.postings after unsuccesful 
> TermsEnum.seekExact(bytes)
> ---
>
> Key: LUCENE-7885
> URL: https://issues.apache.org/jira/browse/LUCENE-7885
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
> Environment: Linux / Centos X64:
> 3.14.33-26.47.amzn1.x86_64 #1 SMP Wed Feb 11 22:39:25 UTC 2015 x86_64 x86_64 
> x86_64 GNU/Linux
>Reporter: Jeroen Baas
>
> Depending on the number of segments, TermsEnum.seekExact(bytes) to find a 
> non-existing term, followed by TermsEnum.postings() is inconsistently 
> returning different results.
> When *optimized* (to 1 segment in my test), the TermsEnum.postings() return 
> the PostingsEnum with documents associated with the next entry in the terms 
> list, if the term does not exist in the list.
> If the core is *not* optimized, TermsEnum.postings() returns null.
> In both cases, the TermsEnum.seekExact(bytes.toBytesRef()) and consecutive 
> TermsEnum.term appears to have advanced to the next entry (relative to the 
> non-existing term).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-7885) Inconsistent return of documents in TermsEnum.postings after unsuccesful TermsEnum.seekExact(bytes)

[Jeroen Baas (JIRA)]

Jeroen Baas created LUCENE-7885:
---

 Summary: Inconsistent return of documents in TermsEnum.postings 
after unsuccesful TermsEnum.seekExact(bytes)
 Key: LUCENE-7885
 URL: https://issues.apache.org/jira/browse/LUCENE-7885
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
 Environment: Linux / Centos X64:
3.14.33-26.47.amzn1.x86_64 #1 SMP Wed Feb 11 22:39:25 UTC 2015 x86_64 x86_64 
x86_64 GNU/Linux
Reporter: Jeroen Baas


Depending on the number of segments, TermsEnum.seekExact(bytes) to find a 
non-existing term, followed by TermsEnum.postings() is inconsistently returning 
different results.

When *optimized* (to 1 segment in my test), the TermsEnum.postings() return the 
PostingsEnum with documents associated with the next entry in the terms list, 
if the term does not exist in the list.
If the core is *not* optimized, TermsEnum.postings() returns null.

In both cases, the TermsEnum.seekExact(bytes.toBytesRef()) and consecutive 
TermsEnum.term appears to have advanced to the next entry (relative to the 
non-existing term).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-10932) install solr service service command fails

[Susheel Kumar (JIRA)]

Susheel Kumar created SOLR-10932:


 Summary: install solr service service command fails
 Key: SOLR-10932
 URL: https://issues.apache.org/jira/browse/SOLR-10932
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
 Environment: Suse linux
Reporter: Susheel Kumar
Priority: Minor


In SUSE distribution,  "service --version" commands always fail and abort the 
solr installation with printing the error  "Script requires the 'service' 
command" 

We can fix it by changing "service --version" to "service --help" command. 

Shawn's test results
==
This is what I get with OS versions that I have access to when running
"service --version":

CentOS 7:
service ver. 1.1

Ubuntu 16:
service ver. 0.91-ubuntu1

Ubuntu 14:
service ver. 0.91-ubuntu1

CentOS 6:
service ver. 0.91

Debian 6:
service ver. 0.91-ubuntu1

Sparc Solaris 10:
bash: service: command not found

=



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4093 - Still Unstable!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.MultiThreadedOCPTest.test

Error Message:
Task 3001 did not complete, final state: FAILED expected same: was 
not:

Stack Trace:
java.lang.AssertionError: Task 3001 did not complete, final state: FAILED 
expected same: was not:
at 
__randomizedtesting.SeedInfo.seed([F0F5A4211EA94F9:875B6598BF16F901]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testDeduplicationOfSubmittedTasks(MultiThreadedOCPTest.java:226)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Created] (SOLR-10931) Resolve conflicting package names o.a.s.cloud.autoscaling

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10931:
---

 Summary: Resolve conflicting package names o.a.s.cloud.autoscaling
 Key: SOLR-10931
 URL: https://issues.apache.org/jira/browse/SOLR-10931
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Ishan Chattopadhyaya


At the moment, o.a.s.cloud.autoscaling is in core as well as in solrj modules.

As per following comments, I think we should change them to different package 
names:
https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15658266=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15658266

https://issues.apache.org/jira/browse/SOLR-9746?focusedCommentId=15654160=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15654160

Currently, the Eclipse project is broken on master due to this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Solr-reference-guide-master - Build # 44 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/44/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H20 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
Cloning the remote Git repository
Cloning repository git://git.apache.org/lucene-solr.git
 > git init /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master # 
 > timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
No valid HEAD. Skipping the resetting
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 44d1f1fe3fe2bdc0210d065965eb30bc467623ca 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 44d1f1fe3fe2bdc0210d065965eb30bc467623ca
 > git rev-list 4746ff0ec8a008d42a44c6e6dd3e94cbb2886410 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/hudson7695543379996650175.sh
+ echo 'Set ruby path to avoid writing to /usr directory'
Set ruby path to avoid writing to /usr directory
+ export RUBY_PATH=/home/jenkins/shared/.rvm
+ RUBY_PATH=/home/jenkins/shared/.rvm
+ export GEM_HOME=/home/jenkins/shared/.rvm/gems
+ GEM_HOME=/home/jenkins/shared/.rvm/gems
+ curl -sSL https://get.rvm.io
+ bash -s -- --path /home/jenkins/shared/.rvm
Downloading https://github.com/rvm/rvm/archive/master.tar.gz

Upgrading the RVM installation in /home/jenkins/shared/.rvm/
RVM PATH line found in /home/jenkins/.mkshrc /home/jenkins/.profile 
/home/jenkins/.bashrc /home/jenkins/.zshrc.
RVM sourcing line found in /home/jenkins/.profile 
/home/jenkins/.bash_profile /home/jenkins/.zlogin.
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.

Upgrade Notes:

  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all

  * No new notes to display.

+ mkdir -p /home/jenkins/shared/.rvm/gems/gems
+ gem install --install-dir /home/jenkins/shared/.rvm/gems jekyll 
jekyll-asciidoc pygments.rb
Successfully installed sass-3.4.24
Successfully installed rb-inotify-0.9.10
Successfully installed liquid-4.0.0
Successfully installed jekyll-3.5.0
Successfully installed jekyll-asciidoc-2.1.0
Successfully installed pygments.rb-1.1.2
6 gems installed
+ export 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ 
PATH=/home/jenkins/shared/.rvm/gems/bin:/home/jenkins/tools/java/latest1.8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
+ cd solr/solr-ref-guide
+ ant clean build-pdf build-site
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 343 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/lucene/top-level-ivy-settings.xml

resolve:
[ivy:retrieve] downloading 
http://repo1.maven.org/maven2/org/asciidoctor/asciidoctor-ant/1.6.0-alpha.3/asciidoctor-ant-1.6.0-alpha.3.jar
 ...
[ivy:retrieve] 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_131) - Build # 989 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/989/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.RecoveryZkTest.test

Error Message:
Mismatch in counts between replicas

Stack Trace:
java.lang.AssertionError: Mismatch in counts between replicas
at 
__randomizedtesting.SeedInfo.seed([E690B5EAFDE4516E:6EC48A3053183C96]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.RecoveryZkTest.assertShardConsistency(RecoveryZkTest.java:143)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 12146 lines...]
   [junit4] Suite: org.apache.solr.cloud.RecoveryZkTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.RecoveryZkTest_E690B5EAFDE4516E-001\init-core-data-001
   [junit4]   2> 

[jira] [Updated] (SOLR-10915) Make SolrClient classes extendable without code duplication

[Jason Gerlowski (JIRA)]

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

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

Updated patch.  The only constructor I was able to remove outright was a 
private one in CloudSolrClient.  The others have been deprecated, with their 
implementations changed to call out to the Builder-based ctor.

All tests pass.

> Make SolrClient classes extendable without code duplication
> ---
>
> Key: SOLR-10915
> URL: https://issues.apache.org/jira/browse/SOLR-10915
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>Priority: Blocker
> Fix For: master (7.0)
>
> Attachments: SOLR-10915.patch, SOLR-10915.patch.with-deprecations, 
> SOLR-10915.patch.without-deprecations
>
>
> SolrClient used to be easily extendable but our move to Builder pattern has 
> made it impossible to extend those classes without code duplication. 
> As an example, if we wanted to extend HttpSolrClient we would also want to 
> extend the Builder. The problem is that the constructor of the main class, 
> does not accept the builder object but explicit parameters, and the inherited 
> class doesn't have access to any of those values from the Builder object as 
> they are all private. 
> Generally, we'd want to have the client object constructor accept the 
> Builder, instead of explicit values, and also make the Builder values 
> protected so the inherited classes could use them.
> I'm marking this as a blocker for 7.0 as this is an important piece that 
> needs to be fixed before the major release, specially now that we know that 
> this problem exists.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7882) Maybe expression compiler should cache recently compiled expressions?

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7882:
-

These one-off class loaders should be gc-ed if there are no root refs pointing 
at anything they declared. This should be relatively easy to verify if you dump 
the heap incrementally over time (yourkit is your friend here).

The blocked thread is possibly a related issue (if they do have some 
synchronization going on internally), but I don't see where that could occur. 
Try the things Robert mentioned. Interesting stuff.

> Maybe expression compiler should cache recently compiled expressions?
> -
>
> Key: LUCENE-7882
> URL: https://issues.apache.org/jira/browse/LUCENE-7882
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/expressions
>Reporter: Michael McCandless
>
> I've been running search performance tests using a simple expression 
> ({{_score + ln(1000+unit_sales)}}) for sorting and hit this odd bottleneck:
> {noformat}
> "pool-1-thread-30" #70 prio=5 os_prio=0 tid=0x7eea7000a000 nid=0x1ea8a 
> waiting for monitor entry [0x7eea867dd000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> org.apache.lucene.expressions.js.JavascriptCompiler$CompiledExpression.evaluate(_score
>  + ln(1000+unit_sales))
>   at 
> org.apache.lucene.expressions.ExpressionFunctionValues.doubleValue(ExpressionFunctionValues.java:49)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collectInternal(OrderedVELeafCollector.java:123)
>   at 
> com.amazon.lucene.OrderedVELeafCollector.collect(OrderedVELeafCollector.java:108)
>   at 
> org.apache.lucene.search.MultiCollectorManager$Collectors$LeafCollectors.collect(MultiCollectorManager.java:102)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:241)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:184)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:658)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:600)
>   at org.apache.lucene.search.IndexSearcher$5.call(IndexSearcher.java:597)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I couldn't see any {{synchronized}} in the sources here, so I'm not sure 
> which object monitor it's blocked on.
> I was accidentally compiling a new expression for every query, and that 
> bottleneck would cause overall QPS to slow down drastically (~4X slower after 
> ~1 hour of redline tests), as if the JVM is getting slower and slower to 
> evaluate each expression the more expressions I had compiled.
> I tested JDK 9-ea and it also kept slowing down over time as the performance 
> test ran.
> Maybe we should put a small cache in front of the expressions compiler to 
> make it less trappy?  Or maybe we can get to the root cause of why the JVM 
> slows down more and more, the more expressions you compile?
> I won't have time to work on this in the near future so if anyone else feels 
> the itch, please scratch it!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7883) Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7883:
-

Looks good to me. I'll check why the context classloader is required in 
clustering later on. I think the case was that clustering was under shared 
libraries and resources loaded per-core couldn't figure where to load classes 
from.

> Remove references to Thread#getContextClassLoader() from Lucene/Solr codebase
> -
>
> Key: LUCENE-7883
> URL: https://issues.apache.org/jira/browse/LUCENE-7883
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: master (7.0)
>
> Attachments: LUCENE-7883.patch
>
>
> As discussed in LUCENE-7873, the use of 
> {{Thread.currentThread().getContextClassLoader()}} is in most cases a bug 
> caused by sloppy usage of ClassLoader APIs and should be replaced by 
> {{getClass().getClassLoader()}}.
> In Lucene we only have the ClassPathResourceLoader, but this one can be 
> solved by removing the "default" constructor. It only affects CustomAnalyzer, 
> that should also be extended in Lucene 7.
> The uses in Solr and its test are all to be replaced by 
> {{getClass().getClassLoader()}} (except some workaround with clustering using 
> a try-finally). This is in most cases historical code, when Solr was a web 
> application to workaround some buggy webapp containers. In the current state, 
> the code is "just wrong".
> Finally, we should add {{java.lang.Thread#getContextClassLoader()}} to 
> forbidden-apis.
> I'd like to get this into Lucene 7, as it affects some APIs in Lucene.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7868) Use multiple threads to apply deletes and DV updates

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7868:


Ugh, sorry, I though I had done that, but I must have forgot to click the 
"Publish Changes" button.  Try now?

I also realize I failed to click Publish Changes on my replies to your first 
review, sheesh!!  So I clicked that now and I guess you now got an email with 
my comments from the *first* iteration!

> Use multiple threads to apply deletes and DV updates
> 
>
> Key: LUCENE-7868
> URL: https://issues.apache.org/jira/browse/LUCENE-7868
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0)
>
> Attachments: cpu-after.png, cpu-before.png, LUCENE-7868.patch, 
> LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, LUCENE-7868.patch, 
> LUCENE-7868.patch
>
>
> Today, when users delete documents or apply doc values updates, IndexWriter 
> buffers them up into frozen packets and then eventually uses a single thread 
> (BufferedUpdatesStream.applyDeletesAndUpdates) to resolve delete/update terms 
> to docids.  This thread also holds IW's monitor lock, so it also blocks 
> refresh, merges starting/finishing, commits, etc.
> We have heavily optimized this part of Lucene over time, e.g. LUCENE-6161, 
> LUCENE-2897, LUCENE-2680, LUCENE-3342, but still, it's a single thread so it 
> can't use multiple CPU cores commonly available now.
> This doesn't affect append-only usage, but for update-heavy users (me!) this 
> can be a big bottleneck, and causes long stop-the-world hangs during indexing.
> I have an initial exploratory patch to make these lookups concurrent, without 
> holding IW's lock, so that when a new packet of deletes is pushed, which 
> happens when we flush a new segment, we immediately use that same indexing 
> thread to and resolve the deletions.
> This is analogous to when we made segment flushing concurrent (LUCENE-3023), 
> just for deletes and DV updates as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Review Request 60154: LUCENE-7868: Concurrent deletes and doc values updates

[Mike McCandless]

> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java
> > Lines 276 (patched)
> > 
> >
> > is it possible that an indexing thread is currently handling this? in 
> > that case we would do it twice? I'd love if you could add some in-line 
> > comment about that

I sync on the packet and checked the `applied` CountDownLatch to see if it was 
completed already, so it should never happen twice.

I'll move this whole method into `FrozenBufferedUpdates` to make that sync 
clearer.


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java
> > Lines 342 (patched)
> > 
> >
> > this is pretty scary if you do that without a try / finally block. if 
> > we fail before we can decrement the refs we might leak the file references?
> > 
> > it's pretty unclear to me where it will be released and I wonder if we 
> > sould use some kind of datastructure where we can record all the files and 
> > make sure that if we exit this loop we release them? ie. have a single 
> > place where we release, like a list we add to?

OK, I've changed the incRef to be the last thing we do in the sync(IW) block, 
and the matched decRef to the first thing I do in the finally block.


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java
> > Lines 348 (patched)
> > 
> >
> > this loop is pretty scary while I get what you are doing. maybe it 
> > would be simpler if we can break out part of it into seperate methods? the 
> > size of the loop also makes it hard to reason about if we leak any resources

OK, I factored out two chunks of code to separate methods.


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java
> > Line 295 (original), 377 (patched)
> > 
> >
> > this entire finally block should be a seperate method

OK I did that.


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/DocumentsWriter.java
> > Lines 720 (patched)
> > 
> >
> > `catch(Throwable t)` really :) I know IW#tragicEvent will sort it out 
> > for us

Yeah :)  I think an exception here is necessarily tragic because the internal 
state of the packet has changed and we cannot easily recover/retry applying 
it...


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThreadPool.java
> > Line 213 (original), 217 (patched)
> > 
> >
> > is this a leftover?

Yeah, I intend to switch to notify.  I think the notifyAll defensively is too 
much: only one thread state freed up.


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java
> > Lines 449 (patched)
> > 
> >
> > I'd love to see dedicated unittests for these methods here if there 
> > aren't any. I mean it's private so maybe we should add some? It's pretty 
> > intense code here

I think TestNumeric/BinaryDocValuesUpdates and TestIndexWriterDelete/ByQuery do 
a pretty good job testing here?


> On June 16, 2017, 8:31 p.m., Simon Willnauer wrote:
> > lucene/core/src/java/org/apache/lucene/index/SegmentReader.java
> > Lines 165 (patched)
> > 
> >
> > is this a bug? should this be fixed seperately?

Not I bug: I just refactored the ternary operator up above to a real `if`.


- Mike


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60154/#review178121
---


On June 21, 2017, 10:04 a.m., Mike McCandless wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60154/
> ---
> 
> (Updated June 21, 2017, 10:04 a.m.)
> 
> 
> Review request for lucene.
> 
> 
> Repository: lucene-solr
> 
> 
> Description
> ---
> 
> Today Lucene uses a single thread to resolve buffered delete/update terms to 
> actual docIDs, but this is a costly process.  This change uses multiple 
> threads (the incoming 

Re: Review Request 60154: LUCENE-7868: Concurrent deletes and doc values updates

[Mike McCandless]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60154/
---

(Updated June 21, 2017, 10:04 a.m.)


Review request for lucene.


Repository: lucene-solr


Description
---

Today Lucene uses a single thread to resolve buffered delete/update terms to 
actual docIDs, but this is a costly process.  This change uses multiple threads 
(the incoming indexing threads) to resolve terms concurrently.

Jira issue: https://issues.apache.org/jira/browse/LUCENE-7868


Diffs (updated)
-

  lucene/core/src/java/org/apache/lucene/index/BinaryDocValuesFieldUpdates.java 
f8cece9 
  lucene/core/src/java/org/apache/lucene/index/BufferedUpdates.java 1c3494f 
  lucene/core/src/java/org/apache/lucene/index/BufferedUpdatesStream.java 
9955626 
  lucene/core/src/java/org/apache/lucene/index/CoalescedUpdates.java bf92ac1 
  lucene/core/src/java/org/apache/lucene/index/DocValuesFieldUpdates.java 
528d4bf 
  lucene/core/src/java/org/apache/lucene/index/DocValuesUpdate.java 1c85f33 
  lucene/core/src/java/org/apache/lucene/index/DocumentsWriter.java 2807517 
  lucene/core/src/java/org/apache/lucene/index/DocumentsWriterDeleteQueue.java 
db0e571 
  lucene/core/src/java/org/apache/lucene/index/DocumentsWriterFlushControl.java 
a5b4b7c 
  lucene/core/src/java/org/apache/lucene/index/DocumentsWriterFlushQueue.java 
2c62487 
  lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThread.java 
c929ba2 
  
lucene/core/src/java/org/apache/lucene/index/DocumentsWriterPerThreadPool.java 
cc72342 
  lucene/core/src/java/org/apache/lucene/index/FlushByRamOrCountsPolicy.java 
a85c98b 
  lucene/core/src/java/org/apache/lucene/index/FlushPolicy.java e70959f 
  lucene/core/src/java/org/apache/lucene/index/FreqProxTermsWriter.java 1ca2830 
  lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java 
4f482ad 
  lucene/core/src/java/org/apache/lucene/index/IndexFileDeleter.java f7f196d 
  lucene/core/src/java/org/apache/lucene/index/IndexWriter.java 14fbbae 
  lucene/core/src/java/org/apache/lucene/index/IndexWriterConfig.java 0fdbc3e 
  lucene/core/src/java/org/apache/lucene/index/LiveIndexWriterConfig.java 
d9e1bc7 
  
lucene/core/src/java/org/apache/lucene/index/MergedPrefixCodedTermsIterator.java
 cd14eec 
  
lucene/core/src/java/org/apache/lucene/index/NumericDocValuesFieldUpdates.java 
4dd3cd0 
  lucene/core/src/java/org/apache/lucene/index/PrefixCodedTerms.java df1653b 
  lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java d4dd4a4 
  lucene/core/src/java/org/apache/lucene/index/SegmentCommitInfo.java b1084a6 
  lucene/core/src/java/org/apache/lucene/index/SegmentCoreReaders.java ce2d448 
  lucene/core/src/java/org/apache/lucene/index/SegmentInfo.java 1c02441 
  lucene/core/src/java/org/apache/lucene/index/SegmentReader.java c8235d5 
  lucene/core/src/java/org/apache/lucene/index/SerialMergeScheduler.java 
5a8f98b 
  lucene/core/src/java/org/apache/lucene/index/TieredMergePolicy.java 668f1ec 
  lucene/core/src/java/org/apache/lucene/util/packed/AbstractPagedMutable.java 
c5fac1e 
  lucene/core/src/test/org/apache/lucene/index/TestBinaryDocValuesUpdates.java 
ed2b66f 
  
lucene/core/src/test/org/apache/lucene/index/TestDocumentsWriterDeleteQueue.java
 c60f54d 
  
lucene/core/src/test/org/apache/lucene/index/TestFlushByRamOrCountsPolicy.java 
aa2901c 
  lucene/core/src/test/org/apache/lucene/index/TestForceMergeForever.java 
0379395 
  lucene/core/src/test/org/apache/lucene/index/TestIndexWriter.java 6897f06 
  lucene/core/src/test/org/apache/lucene/index/TestIndexWriterConfig.java 
2014c16 
  lucene/core/src/test/org/apache/lucene/index/TestIndexWriterDelete.java 
25817d9 
  lucene/core/src/test/org/apache/lucene/index/TestIndexWriterExceptions.java 
c0907a5 
  lucene/core/src/test/org/apache/lucene/index/TestIndexWriterReader.java 
584e03c 
  lucene/core/src/test/org/apache/lucene/index/TestNRTReaderWithThreads.java 
871715f 
  lucene/core/src/test/org/apache/lucene/index/TestNumericDocValuesUpdates.java 
94da587 
  lucene/core/src/test/org/apache/lucene/index/TestPerSegmentDeletes.java 
112a108 
  lucene/core/src/test/org/apache/lucene/index/TestPrefixCodedTerms.java 
89d4ad1 
  
lucene/core/src/test/org/apache/lucene/search/TestControlledRealTimeReopenThread.java
 a1b2a5c 
  lucene/join/src/test/org/apache/lucene/search/join/TestJoinUtil.java 1503de8 
  
lucene/sandbox/src/java/org/apache/lucene/codecs/idversion/IDVersionPostingsWriter.java
 334f784 
  
lucene/sandbox/src/java/org/apache/lucene/codecs/idversion/VersionBlockTreeTermsWriter.java
 d83b915 
  
lucene/test-framework/src/java/org/apache/lucene/index/BaseDocValuesFormatTestCase.java
 8cb6665 
  
lucene/test-framework/src/java/org/apache/lucene/index/BaseIndexFileFormatTestCase.java
 959466a 
  lucene/test-framework/src/java/org/apache/lucene/util/LuceneTestCase.java 
0243a56 


Diff: 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi [~michael.sun] It changed after identifying and handling resource 
contention. 

Sadly for Indexing (using ConcurrentUpdateSolrClient) on the SolrCloud, there 
are still fluctuations noted (I am guessing because ConcurrentUpdateSolrClient 
uses HttpSolrClient instead of CloudSolrClient, see: 
https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/ConcurrentUpdateSolrClient.java#L105-L107)

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> SOLR-10317.patch, solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-7872) TopDocs.totalHits should be a long

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7872.
--
   Resolution: Fixed
Fix Version/s: master (7.0)

> TopDocs.totalHits should be a long
> --
>
> Key: LUCENE-7872
> URL: https://issues.apache.org/jira/browse/LUCENE-7872
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE-7872.patch, LUCENE-7872.patch
>
>
> Even though a single index cannot have more than 2B documents, TopDocs.merge 
> might merge TopDocs instances that have more than 2B documents in total.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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