[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6733:


I created a new branch.  And then discovered that I'd named it incorrectly 
after I'd already pushed it.  Now there's a correctly named "solr-6733" branch.

Most of the work I've done is on scripts, but I have created new modules.  The 
Main.java for the start module is taken straight from an http2 embedded example 
and is likely nowhere near usable.  The Main.java for the agent module is 
untested and so far only implements one command.

> Umbrella issue - Solr as a standalone application
> -
>
> Key: SOLR-6733
> URL: https://issues.apache.org/jira/browse/SOLR-6733
> Project: Solr
>  Issue Type: New Feature
>Reporter: Shawn Heisey
>Priority: Major
>
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by 
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
>  * Create org.apache.solr.start.Main (and possibly other classes in the same 
> package), to be placed in solr-start.jar.  The Main class will contain the 
> main method that starts the embedded Jetty and Solr.  I do not know how to 
> adjust the build system to do this successfully.
>  * Handle central configurations in code -- TCP port, SSL, and things like 
> web.xml.
>  * For each of these steps, clean up any test fallout.
>  * Handle cloud-related configurations in code -- port, hostname, protocol, 
> etc.  Use the same information as the central configurations.
>  * Consider whether things like authentication need changes.
>  * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately 
> being applied only to master, not the stable branch.



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

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

[JENKINS] Lucene-Solr-BadApples-7.x-Linux (64bit/jdk1.8.0_172) - Build # 46 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-7.x-Linux/46/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.handler.tagger.Tagger2Test.testStopWords

Error Message:
[]: didn't find expected TestTag{[2-6] doc=1:'A City A' substr=City} (of 1); 
java.lang.AssertionError: array lengths differed, expected.length=1 
actual.length=0

Stack Trace:
java.lang.AssertionError: []: didn't find expected TestTag{[2-6] doc=1:'A City 
A' substr=City} (of 1); java.lang.AssertionError: array lengths differed, 
expected.length=1 actual.length=0
at 
__randomizedtesting.SeedInfo.seed([5E0244ABA1C20E0D:DDF1CB7338E627FE]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertSortedArrayEquals(TaggerTestCase.java:199)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertTags(TaggerTestCase.java:132)
at 
org.apache.solr.handler.tagger.Tagger2Test.testStopWords(Tagger2Test.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11-ea+14) - Build # 46 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/46/
Java: 64bit/jdk-11-ea+14 -XX:+UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  org.apache.solr.handler.tagger.Tagger2Test.testStopWords

Error Message:
[]: didn't find expected TestTag{[2-6] doc=1:'A City A' substr=City} (of 1); 
java.lang.AssertionError: array lengths differed, expected.length=1 
actual.length=0

Stack Trace:
java.lang.AssertionError: []: didn't find expected TestTag{[2-6] doc=1:'A City 
A' substr=City} (of 1); java.lang.AssertionError: array lengths differed, 
expected.length=1 actual.length=0
at 
__randomizedtesting.SeedInfo.seed([4B68E7405D081FC9:C89B6898C42C363A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertSortedArrayEquals(TaggerTestCase.java:199)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertTags(TaggerTestCase.java:132)
at 
org.apache.solr.handler.tagger.Tagger2Test.testStopWords(Tagger2Test.java:102)
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:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12444:


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

SOLR-12444: added more assertions to the test


> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[jira] [Commented] (SOLR-12142) EmbeddedSolrServer should use req.getContentWriter

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12142:
-

Now that the SolrTextTagger is in Solr, it's test demonstrating the issue is 
now here too.  See:
https://github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/handler/tagger/EmbeddedSolrNoSerializeTest.java#L102
   (the commented out part)

If it can't be fixed for 7.4 then the commit ought to be reverted from 7x.

> EmbeddedSolrServer should use req.getContentWriter 
> ---
>
> Key: SOLR-12142
> URL: https://issues.apache.org/jira/browse/SOLR-12142
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12142.patch
>
>
> In SOLR-11380, SolrRequest.getContentWriter was introduced as a replacement 
> for getContentStreams.  However, EmbeddedSolrServer still calls 
> getContentStreams, and so clients who need to send POST data to it cannot yet 
> switch from the Deprecated API to the new API.  The SolrTextTagger is an 
> example of a project where one would want to do this.
> It seems EmbeddedSolrServer ought to check for getContentWriter and if 
> present then convert it into a ContentStream somehow.  For the time being, 
> ESS needs to call both since both APIs exist.
> CC [~noble.paul]



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

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

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12444:


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

SOLR-12444: added more assertions to the test


> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 2062 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2062/
Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseParallelGC

7 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/68)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":11}, "core_node4":{ 
  "core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1528249446415155700", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:1_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":14}, "core_node2":{ 
  "core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1528249446423917250",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{  
 "parent":"shard1",   "stateTimestamp":"1528249446423740250",   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node7":{   "leader":"true",   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10001_solr",   
"base_url":"http://127.0.0.1:10001/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:1_solr",   
"base_url":"http://127.0.0.1:1/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/68)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "shards":{
"shard2":{
  "replicas":{
"core_node3":{
  "core":"testSplitIntegration_collection_shard2_replica_n3",
  "leader":"true",
  "SEARCHER.searcher.maxDoc":11,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":1,
  "node_name":"127.0.0.1:1_solr",
  

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 236 - Failure

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/77)={   
"replicationFactor":"2",   "pullReplicas":"0",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0",   
"autoCreated":"true",   "shards":{ "shard2":{   "replicas":{ 
"core_node3":{   
"core":"testSplitIntegration_collection_shard2_replica_n3",   
"leader":"true",   "SEARCHER.searcher.maxDoc":11,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10020_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":11}, "core_node4":{ 
  "core":"testSplitIntegration_collection_shard2_replica_n4",   
"SEARCHER.searcher.maxDoc":11,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10021_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":11}},   "range":"0-7fff",   
"state":"active"}, "shard1":{   "stateTimestamp":"1528475866204489850", 
  "replicas":{ "core_node1":{   
"core":"testSplitIntegration_collection_shard1_replica_n1",   
"leader":"true",   "SEARCHER.searcher.maxDoc":14,   
"SEARCHER.searcher.deletedDocs":0,   "INDEX.sizeInBytes":1,   
"node_name":"127.0.0.1:10020_solr",   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":14}, "core_node2":{ 
  "core":"testSplitIntegration_collection_shard1_replica_n2",   
"SEARCHER.searcher.maxDoc":14,   "SEARCHER.searcher.deletedDocs":0, 
  "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10021_solr",  
 "state":"active",   "type":"NRT",   
"SEARCHER.searcher.numDocs":14}},   "range":"8000-",   
"state":"inactive"}, "shard1_1":{   "parent":"shard1",   
"stateTimestamp":"1528475866256994000",   "range":"c000-",  
 "state":"active",   "replicas":{ "core_node10":{   
"leader":"true",   
"core":"testSplitIntegration_collection_shard1_1_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10020_solr",   
"base_url":"http://127.0.0.1:10020/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node9":{   
"core":"testSplitIntegration_collection_shard1_1_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10021_solr",   
"base_url":"http://127.0.0.1:10021/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}}}, "shard1_0":{  
 "parent":"shard1",   "stateTimestamp":"1528475866256721450",   
"range":"8000-bfff",   "state":"active",   "replicas":{ 
"core_node7":{   
"core":"testSplitIntegration_collection_shard1_0_replica0",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10021_solr",   
"base_url":"http://127.0.0.1:10021/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}, 
"core_node8":{   
"core":"testSplitIntegration_collection_shard1_0_replica1",   
"SEARCHER.searcher.maxDoc":7,   "SEARCHER.searcher.deletedDocs":0,  
 "INDEX.sizeInBytes":1,   "node_name":"127.0.0.1:10020_solr",   
"base_url":"http://127.0.0.1:10020/solr;,   "state":"active",   
"type":"NRT",   "SEARCHER.searcher.numDocs":7}

Stack Trace:
java.util.concurrent.TimeoutException: last state: 
DocCollection(testSplitIntegration_collection//clusterstate.json/77)={
  "replicationFactor":"2",
  "pullReplicas":"0",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0",
  "autoCreated":"true",
  "shards":{
"shard2":{
  "replicas":{
"core_node3":{
  "core":"testSplitIntegration_collection_shard2_replica_n3",
  "leader":"true",
  "SEARCHER.searcher.maxDoc":11,
  "SEARCHER.searcher.deletedDocs":0,
  "INDEX.sizeInBytes":1,
  "node_name":"127.0.0.1:10020_solr",
  "state":"active",
  "type":"NRT",
  "SEARCHER.searcher.numDocs":11},
  

[jira] [Commented] (SOLR-6733) Umbrella issue - Solr as a standalone application

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-6733:
--

bq. Is there anyone out there with significant Ant experience, and possibly a 
significant understanding of Solr's build system in particular, that could help 
me write a build.xml for a "start" module, and integrate it into the overall 
build system?

I could help.  How would this differ from the existing {{server/}} module?

> Umbrella issue - Solr as a standalone application
> -
>
> Key: SOLR-6733
> URL: https://issues.apache.org/jira/browse/SOLR-6733
> Project: Solr
>  Issue Type: New Feature
>Reporter: Shawn Heisey
>Priority: Major
>
> Umbrella issue.
> Solr should be a standalone application, where the main method is provided by 
> Solr source code.
> Here are the major tasks I envision, if we choose to embed Jetty:
>  * Create org.apache.solr.start.Main (and possibly other classes in the same 
> package), to be placed in solr-start.jar.  The Main class will contain the 
> main method that starts the embedded Jetty and Solr.  I do not know how to 
> adjust the build system to do this successfully.
>  * Handle central configurations in code -- TCP port, SSL, and things like 
> web.xml.
>  * For each of these steps, clean up any test fallout.
>  * Handle cloud-related configurations in code -- port, hostname, protocol, 
> etc.  Use the same information as the central configurations.
>  * Consider whether things like authentication need changes.
>  * Handle any remaining container configurations.
> I am currently imagining this work happening in a new branch and ultimately 
> being applied only to master, not the stable branch.



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

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

[jira] [Commented] (SOLR-12362) JSON and XML loaders should save the relationship of children

[mosh (JIRA)]

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

mosh commented on SOLR-12362:
-

The unique key solution seems like a better way to determine if the JSON is 
indeed a child document.
 However, I did not quite grasp your idea for custom JSON:
{quote}For custom JSON, I think we can explicitly call out these child 
documents by having the path show up in the split param. It seems this is 
already supported though we need to retain the semantic key
{quote}
Do you refer to _childDocuments_ as the *semantic key*?
If so, the conditional: {code}if 
(fieldName.equals(JsonLoader.CHILD_DOC_KEY)){code} could be changed to: 
{code}if (anonChildDocFlag && fieldName.equals(JsonLoader.CHILD_DOC_KEY)) {code}

> JSON and XML loaders should save the relationship of children
> -
>
> Key: SOLR-12362
> URL: https://issues.apache.org/jira/browse/SOLR-12362
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Once _childDocuments in SolrInputDocument is changed to a Map, the JsonLoader 
> and XmlLoader should add the child document to the map while saving its key 
> name, to maintain the child's relationship to its parent.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10) - Build # 22185 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22185/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC

8 tests failed.
FAILED:  org.apache.solr.update.TransactionLogTest.testBigLastAddSize

Error Message:
For input string: "00011734527593407600408"

Stack Trace:
java.lang.NumberFormatException: For input string: 
"00011734527593407600408"
at 
__randomizedtesting.SeedInfo.seed([A078B1642B3229EB:B8821FCFC27CD5EA]:0)
at 
java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Long.parseLong(Long.java:692)
at java.base/java.lang.Long.parseLong(Long.java:817)
at org.apache.solr.update.TransactionLog.(TransactionLog.java:153)
at org.apache.solr.update.TransactionLog.(TransactionLog.java:141)
at 
org.apache.solr.update.TransactionLogTest.testBigLastAddSize(TransactionLogTest.java:34)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
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:  org.apache.solr.update.TransactionLogTest.testBigLastAddSize

Error Message:
For input string: "00010746430551404070650"

Stack Trace:
java.lang.NumberFormatException: For input string: 
"00010746430551404070650"
at 
__randomizedtesting.SeedInfo.seed([A078B1642B3229EB:B8821FCFC27CD5EA]:0)
at 

[jira] [Commented] (SOLR-12283) Unable To Load ZKPropertiesWriter when dih.jar is added as runtimelib BLOB in .system collection

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-12283:
-

The stacktrace isn't making any sense.  It's complaining about a line number 
that shouldn't have any problem.

Line 940 is the last line of this bit of code:
{code:java}
ClassNotFoundException ex = new ClassNotFoundException("Unable to load 
" + name + " or "
+ DocBuilder
.class
.getPackage()
.getName()
+ "." + name, e);
{code}

I've tested this construct, and cannot get an NPE.  Thoroughly confused.

> Unable To Load ZKPropertiesWriter when dih.jar is added as runtimelib BLOB in 
> .system collection
> 
>
> Key: SOLR-12283
> URL: https://issues.apache.org/jira/browse/SOLR-12283
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Affects Versions: 6.6.1, 7.3
> Environment: Debian
> SolrCloud
>Reporter: Maxence SAUNIER
>Priority: Blocker
> Attachments: indexation_events.xml, modified-DIH.zip, 
> modified-DIH.zip, mysql-connector-java-5.1.46-bin.jar, 
> mysql-connector-java-5.1.46.jar, request_handler_config.json, 
> solr-core-7.3.0.jar, solr-dataimporthandler-7.3.0.jar, 
> solr-dataimporthandler-extras-7.3.0.jar, solr-solrj-7.3.0.jar, solr.log, 
> solr.log, solr.log, solr.log
>
>
> Hello,
> It's been 2 weeks that I try to correct this problem with the community 
> user-solr but no success. I seriously wonder if this is not a problem in the 
> code. I do not have the impression that many people use DIH with Solr's cloud 
> version.
> On Internet, no similar problem.
> For information, the following configuration of DIH comes from DIHs that work 
> in production on a single Solr server. The connections to the databases are 
> therefore correct.
> *Errors messages:*
> {panel:title=DataImporter}
> {code:java}
> Full Import 
> failed:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable 
> to PropertyWriter implementation:ZKPropertiesWriter
>   at 
> org.apache.solr.handler.dataimport.DataImporter.createPropertyWriter(DataImporter.java:339)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:420)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:483)
>   at 
> org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:183)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2503)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:711)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:517)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1629)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   at 
> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2061/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.handler.tagger.Tagger2Test.testStopWords

Error Message:
[]: didn't find expected TestTag{[2-6] doc=1:'A City A' substr=City} (of 1); 
java.lang.AssertionError: array lengths differed, expected.length=1 
actual.length=0

Stack Trace:
java.lang.AssertionError: []: didn't find expected TestTag{[2-6] doc=1:'A City 
A' substr=City} (of 1); java.lang.AssertionError: array lengths differed, 
expected.length=1 actual.length=0
at 
__randomizedtesting.SeedInfo.seed([1EE884562A69BBA5:9D1B0B8EB34D9256]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertSortedArrayEquals(TaggerTestCase.java:199)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertTags(TaggerTestCase.java:132)
at 
org.apache.solr.handler.tagger.Tagger2Test.testStopWords(Tagger2Test.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Michael Braun (JIRA)]

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

Michael Braun commented on LUCENE-8345:
---

[~thetaphi] corrected the random T in the text. Should the String add be 
included as part of this ticket? 

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Assignee: Uwe Schindler
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[jira] [Updated] (SOLR-12267) Admin UI broken metrics

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12267:
-
Component/s: metrics
 Admin UI

> Admin UI broken metrics
> ---
>
> Key: SOLR-12267
> URL: https://issues.apache.org/jira/browse/SOLR-12267
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI, metrics
>Reporter: Varun Thacker
>Priority: Major
> Attachments: Solr662.png, Solr720.png
>
>
> Attaching Screenshots of the same metric on Solr 6.6.2 VS Solr 7.2.0 
> The admin UI shows completely different metrics



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

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

[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11453:


Commit 7d827c627c3090354898cd02fb9cd6a303dfb2a9 in lucene-solr's branch 
refs/heads/branch_7x from [~varunthacker]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7d827c6 ]

SOLR-11453: fix typos in the CHANGES entry


> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Reporter: Shawn Heisey
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> slowlog-informational.patch, slowlog-informational.patch, 
> slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



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

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

[jira] [Commented] (SOLR-11453) Create separate logger for slow requests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11453:


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

SOLR-11453: fix typos in the CHANGES entry


> Create separate logger for slow requests
> 
>
> Key: SOLR-11453
> URL: https://issues.apache.org/jira/browse/SOLR-11453
> Project: Solr
>  Issue Type: Improvement
>  Components: logging
>Reporter: Shawn Heisey
>Assignee: Varun Thacker
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, 
> slowlog-informational.patch, slowlog-informational.patch, 
> slowlog-informational.patch
>
>
> There is some desire on the mailing list to create a separate logfile for 
> slow queries.  Currently it is not possible to do this cleanly, because the 
> WARN level used by slow query logging within the SolrCore class is also used 
> for other events that SolrCore can log.  Those messages would be out of place 
> in a slow query log.  They should typically stay in main solr logfile.
> I propose creating a custom logger for slow queries, similar to what has been 
> set up for request logging.  In the SolrCore class, which is 
> org.apache.solr.core.SolrCore, there is a special logger at 
> org.apache.solr.core.SolrCore.Request.  This is not a real class, just a 
> logger which makes it possible to handle those log messages differently than 
> the rest of Solr's logging.  I propose setting up another custom logger 
> within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest.



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 22184 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22184/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseParallelGC

4 tests failed.
FAILED:  org.apache.solr.handler.tagger.Tagger2Test.testStopWords

Error Message:
[]: didn't find expected TestTag{[2-6] doc=1:'A City A' substr=City} (of 1); 
java.lang.AssertionError: array lengths differed, expected.length=1 
actual.length=0

Stack Trace:
java.lang.AssertionError: []: didn't find expected TestTag{[2-6] doc=1:'A City 
A' substr=City} (of 1); java.lang.AssertionError: array lengths differed, 
expected.length=1 actual.length=0
at 
__randomizedtesting.SeedInfo.seed([4FC7B790B612CD41:CC3438482F36E4B2]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertSortedArrayEquals(TaggerTestCase.java:199)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertTags(TaggerTestCase.java:132)
at 
org.apache.solr.handler.tagger.Tagger2Test.testStopWords(Tagger2Test.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-12209:
---

I'll attempt to commit fairly soon. If I run into any snags I'll probably have 
to wait until the next release.

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12209.patch, SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



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

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

Re: Lucene/Solr 7.4

[Varun Thacker]

+1

On Tue, Jun 5, 2018 at 1:24 AM, Adrien Grand  wrote:

> Hi all,
>
> We released 7.3 two months ago on April 4th and we accumulated quite a
> number of features, enhancements and fixes that are not released yet, so
> I'd like to start working on releasing Lucene/Solr 7.4.0.
>
> I propose to create the 7.4 branch later this week and build the first RC
> early next week if that works for everyone. Please let me know if that are
> bug fixes that we think should make it to 7.4 and might not be ready by
> then.
>
> Adrien
>

[jira] [Commented] (SOLR-12454) tweak Overseer leadership transition related logging

[JIRA]

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

Jan Høydahl commented on SOLR-12454:


Can you give background for why such debugging cannot be done by raising the 
log level for the Overseer to DEBUG on demand? That's what we have debug levels 
for, not :) 

> tweak Overseer leadership transition related logging
> 
>
> Key: SOLR-12454
> URL: https://issues.apache.org/jira/browse/SOLR-12454
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12454.patch
>
>
> Proposed patch to follow.



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

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

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

[Apache Jenkins Server]

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

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

[repro] Revision: 05cde8de3cf9f5e4162d1f2c031274ebe99daf51

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testNodeLost -Dtests.seed=9A16B54ACB350F8 -Dtests.multiplier=2 
-Dtests.locale=fr-LU -Dtests.timezone=SystemV/HST10 -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] Repro line:  ant test  -Dtestcase=TestLargeCluster 
-Dtests.method=testBasic -Dtests.seed=9A16B54ACB350F8 -Dtests.multiplier=2 
-Dtests.locale=fr-LU -Dtests.timezone=SystemV/HST10 -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
0c6f38a315d0df5abd01e7d4efe481bc53444a49
[repro] git fetch
[repro] git checkout 05cde8de3cf9f5e4162d1f2c031274ebe99daf51

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

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

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

[...truncated 3317 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestLargeCluster" -Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=9A16B54ACB350F8 -Dtests.multiplier=2 -Dtests.locale=fr-LU 
-Dtests.timezone=SystemV/HST10 -Dtests.asserts=true -Dtests.file.encoding=UTF-8

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

[repro] Failures:
[repro]   4/5 failed: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster
[repro] git checkout 0c6f38a315d0df5abd01e7d4efe481bc53444a49

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

[...truncated 6 lines...]

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

[jira] [Commented] (SOLR-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11654:
-

RE your change to TimeRoutedAliasUpdateProcessorTest ... I'd rather the test 
not bother doing a cleanup of the conifgsets added.  Since the current test 
asserts the number of configSets, it can be modified to be less stringent or 
not care; it's not important.

> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to 
> the ideal shard
> 
>
> Key: SOLR-11654
> URL: https://issues.apache.org/jira/browse/SOLR-11654
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-11654.patch
>
>
> {{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the 
> Shard/Slice to talk to for the given collection.  It currently picks the 
> first active Shard/Slice but it has a TODO to route to the ideal one based on 
> the router configuration of the target collection.  There is similar code in 
> CloudSolrClient & DistributedUpdateProcessor that should probably be 
> refactored/standardized so that we don't have to repeat this logic.



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

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 236 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 24222 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2203 links (1757 relative) to 2985 anchors in 230 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/package/solr-7.4.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/top-level-ivy-settings.xml

[jira] [Commented] (SOLR-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11654:
-

Looking at your patch.  getLeaderNode I noticed doesn't pass along "slice" to 
the constructor of RetryNode (last param).  It probably should do so for 
routeDocToSlice, but lookupShardLeadersOfCollections I guess null (what's 
happening today).  I'm not completely clear on the implications yet.

Hey [~shalinmangar] or anyone who knows SolrCloud well, do you know if there 
are tests for ensuring the doc routing goes right to the correct shard leader 
instead of being arbitrary?  I suppose it's fundamental to DURP but in 
CloudSolrClient AFAIK this is an optimization so perhaps there's a test for 
that?  We're not sure how to test this since it's an internal routing thing.  
See Gus's most recent comment above.  I directed Gus at 
TrackingShardHandlerFactory but didn't realize it's a search-only tracker not 
for updates (ouch).

> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to 
> the ideal shard
> 
>
> Key: SOLR-11654
> URL: https://issues.apache.org/jira/browse/SOLR-11654
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-11654.patch
>
>
> {{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the 
> Shard/Slice to talk to for the given collection.  It currently picks the 
> first active Shard/Slice but it has a TODO to route to the ideal one based on 
> the router configuration of the target collection.  There is similar code in 
> CloudSolrClient & DistributedUpdateProcessor that should probably be 
> refactored/standardized so that we don't have to repeat this logic.



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

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

Re: Lucene/Solr 7.4

[Simon Willnauer]

+1

On Tue, Jun 5, 2018 at 5:40 PM, Christian Moen  wrote:
> +1
>
>
> On Tue, Jun 5, 2018 at 5:24 PM Adrien Grand  wrote:
>>
>> Hi all,
>>
>> We released 7.3 two months ago on April 4th and we accumulated quite a
>> number of features, enhancements and fixes that are not released yet, so I'd
>> like to start working on releasing Lucene/Solr 7.4.0.
>>
>> I propose to create the 7.4 branch later this week and build the first RC
>> early next week if that works for everyone. Please let me know if that are
>> bug fixes that we think should make it to 7.4 and might not be ready by
>> then.
>>
>> Adrien

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

[jira] [Commented] (SOLR-12402) factor out a SolrDefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12402:


This SOLR-12402 ticket here builds upon SOLR-12036 which in turn built upon the 
SOLR-12174 refactoring.

[~joel.bernstein] - would you have any thoughts on the (small) attached patch? 
I think it would be nice for these three to jointly be in the 7.4 release.

> factor out a SolrDefaultStreamFactory class
> ---
>
> Key: SOLR-12402
> URL: https://issues.apache.org/jira/browse/SOLR-12402
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12402.patch
>
>
> Two motivations behind the proposed factoring out:
> * discoverability of solr/solrj Lang vs. solr/core Lucene/Solr functions
> * support for custom classes that require access to a SolrResourceLoader



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

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

[jira] [Assigned] (SOLR-11654) TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to the ideal shard

[David Smiley (JIRA)]

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

David Smiley reassigned SOLR-11654:
---

Assignee: David Smiley

> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to 
> the ideal shard
> 
>
> Key: SOLR-11654
> URL: https://issues.apache.org/jira/browse/SOLR-11654
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-11654.patch
>
>
> {{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the 
> Shard/Slice to talk to for the given collection.  It currently picks the 
> first active Shard/Slice but it has a TODO to route to the ideal one based on 
> the router configuration of the target collection.  There is similar code in 
> CloudSolrClient & DistributedUpdateProcessor that should probably be 
> refactored/standardized so that we don't have to repeat this logic.



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

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

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/395#discussion_r193217004
  
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java 
---
@@ -556,82 +556,105 @@ private void parseFieldValue(SolrInputField sif) 
throws IOException {
   if (ev == JSONParser.OBJECT_START) {
 parseExtendedFieldValue(sif, ev);
   } else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
 sif.setValue(val);
   }
 }
 
+private Map generateExtendedValueMap(int ev) throws 
IOException {
+  assert ev == JSONParser.OBJECT_START;
+  Map extendedInfo = new HashMap<>();
+
+  for(; ; ) {
--- End diff --

nitpick: I prefer while(true)


---

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

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/395#discussion_r193217572
  
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java 
---
@@ -556,82 +556,105 @@ private void parseFieldValue(SolrInputField sif) 
throws IOException {
   if (ev == JSONParser.OBJECT_START) {
 parseExtendedFieldValue(sif, ev);
   } else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
 sif.setValue(val);
   }
 }
 
+private Map generateExtendedValueMap(int ev) throws 
IOException {
+  assert ev == JSONParser.OBJECT_START;
+  Map extendedInfo = new HashMap<>();
+
+  for(; ; ) {
+ev = parser.nextEvent();
+if (ev == JSONParser.OBJECT_END) {
+  return extendedInfo;
+}
+String label = parser.getString();
+SolrInputField sif = new SolrInputField(label);
+parseFieldValue(sif);
+extendedInfo.put(label, sif.getValue());
+  }
+}
+
+private boolean isChildDoc(Map extendedMap) {
+  if (extendedMap.containsKey("value") && 
extendedMap.containsKey("boost")) {
--- End diff --

lets instead simply check for the uniqueKey label


---

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

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/395#discussion_r193216812
  
--- Diff: solr/core/src/java/org/apache/solr/handler/loader/JsonLoader.java 
---
@@ -556,82 +556,105 @@ private void parseFieldValue(SolrInputField sif) 
throws IOException {
   if (ev == JSONParser.OBJECT_START) {
 parseExtendedFieldValue(sif, ev);
   } else {
-Object val = parseNormalFieldValue(ev, sif.getName());
+Object val = parseNormalFieldValue(ev, sif);
 sif.setValue(val);
   }
 }
 
+private Map generateExtendedValueMap(int ev) throws 
IOException {
--- End diff --

Can you please sequence the methods so this follows where it's called from 
so readers needn't look back up?


---

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

[GitHub] lucene-solr pull request #395: WIP SOLR-12362: add tests for working relatio...

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/395#discussion_r193216315
  
--- Diff: solr/core/src/test/org/apache/solr/handler/JsonLoaderTest.java ---
@@ -946,5 +946,87 @@ public void testGrandChildDocs() throws Exception {
 
   }
 
+  @Test
+  public void testRelationalChildDocs() throws Exception {
--- End diff --

A bit on terminology if so-called "relational" child docs are going to 
be the only way to have a child doc in the future, then lets just start calling 
these simply child docs without the "relational" qualifier.  "Relational" may 
be kinda confusing since an anonymous relationship is still related.  Perhaps 
the new way is a "labelled" child doc?  If you disagree and want to keep some 
qualifier then okay.  If you see an existing test that says "child doc" for 
anonymous child doc then change its name to be about "anonymous" child docs.


---

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

[jira] [Commented] (SOLR-12362) JSON and XML loaders should save the relationship of children

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12362:
-

To be clear, this patch thus far seems to be focused on "Solr-Style JSON" 
https://lucene.apache.org/solr/guide/7_3/uploading-data-with-index-handlers.html#uploading-data-with-index-handlers
  (alas I don't like that name)  and not custom JSON.   Will this issue address 
both or do you think Custom JSON warrants a separate issue?

*For Solr-Style JSON*: Unfortunately the Solr Ref Guide doesn't show the 
atomic/partial update syntax.  Here's an excerpt:
{code:json}
[{'id':'1', 'val_s':{'add':'foo'}}]
{code}

Assuming that all documents must have the uniqueKey field, I think we can 
simply look for the presence of that key in the child JSON object?  Technically 
uniqueKey is optional but if it's undefined then child documents (and many/most 
Solr features) don't work any way.  I think it's more complicated to go the 
path you did by trying to know the atomic update verbs and other special keys.  
There would be issues if someone oddly chooses a uniqueKey matching "value" or 
one of these update verbs but that'd be a pretty weird choice.  Perhaps long 
term Solr ought to lock down "id" for the official uniqueKey as a simplifying 
decision.

*For custom JSON*, I think we can explicitly call out these child documents by 
having the path show up in the {{split}} param.  It seems this is already 
supported though we need to retain the semantic key and decide when we add this 
semantic key or when not (make anonymous).  If we view anonymous children as 
old/deprecated to be removed, then we can just have a flag for this, one that 
is boolean one way in 7x but the other in master (8x).

> JSON and XML loaders should save the relationship of children
> -
>
> Key: SOLR-12362
> URL: https://issues.apache.org/jira/browse/SOLR-12362
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Once _childDocuments in SolrInputDocument is changed to a Map, the JsonLoader 
> and XmlLoader should add the child document to the map while saving its key 
> name, to maintain the child's relationship to its parent.



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

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

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

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

mosh commented on SOLR-12209:
-

[~joel.bernstein],
Seems like the patch passed the tests, hopefully we can get it accepted before 
the feature freeze.

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12209.patch, SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



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

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

[jira] [Commented] (LUCENE-8165) ban Arrays.copyOfRange with forbidden APIs

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen commented on LUCENE-8165:
-

I've attached a new patch which removes both `Arrays.copyOfRange` and 
`Arrays.copyOf` using two newly added helper methods in ArrayUtil. Please have 
a look. Thank you!

> ban Arrays.copyOfRange with forbidden APIs
> --
>
> Key: LUCENE-8165
> URL: https://issues.apache.org/jira/browse/LUCENE-8165
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8165.patch, LUCENE-8165_copy_of.patch, 
> LUCENE-8165_copy_of_range.patch, LUCENE-8165_start.patch, 
> LUCENE-8165_start.patch
>
>
> This method is no good, because instead of throwing AIOOBE for bad bounds, it 
> will silently fill with zeros (essentially silent corruption). Unfortunately 
> it is used in quite a few places so replacing it with e.g. arrayCopy may 
> uncover some interesting surprises.
> See LUCENE-8164 for motivation.



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

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

[jira] [Updated] (LUCENE-8165) ban Arrays.copyOfRange with forbidden APIs

[Nhat Nguyen (JIRA)]

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

Nhat Nguyen updated LUCENE-8165:

Attachment: LUCENE-8165.patch

> ban Arrays.copyOfRange with forbidden APIs
> --
>
> Key: LUCENE-8165
> URL: https://issues.apache.org/jira/browse/LUCENE-8165
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8165.patch, LUCENE-8165_copy_of.patch, 
> LUCENE-8165_copy_of_range.patch, LUCENE-8165_start.patch, 
> LUCENE-8165_start.patch
>
>
> This method is no good, because instead of throwing AIOOBE for bad bounds, it 
> will silently fill with zeros (essentially silent corruption). Unfortunately 
> it is used in quite a few places so replacing it with e.g. arrayCopy may 
> uncover some interesting surprises.
> See LUCENE-8164 for motivation.



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

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

[jira] [Commented] (SOLR-12395) Typo in SignificantTermsQParserPlugin.NAME

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12395:


The above reported {{solr.search.TestStandardQParsers}} and 
{{solr.search.QueryEqualityTest}} failures were genuine -- I have not yet 
checked about the non-solr.search ones.

Attached revised patch, note that the addition of the deprecated 
{{SignificantTermsQParserPlugin.OLD_NAME}} constant will make it easy to remove 
the "for Solr 7.x backcompat only" code portions.

> Typo in SignificantTermsQParserPlugin.NAME
> --
>
> Key: SOLR-12395
> URL: https://issues.apache.org/jira/browse/SOLR-12395
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5, 7.3.1
>Reporter: Tobias Kässmann
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-12395.patch, SOLR-12395.patch, SOLR-12395.patch
>
>
> I think there is a small typo in the {{SignificantTermsQParserPlugin}}:
> {code:java}
> public static final String NAME = "sigificantTerms";{code}
> should be:
> {code:java}
> public static final String NAME = "significantTerms";{code}
>  See the patch attached.



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

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

[jira] [Commented] (SOLR-12438) Improve status reporting of metrics history API

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12438:
--

This patch contains the following changes:
* the API works now also in non-cloud mode.
* report the current "mode" (disabled, memory, index).
* automatically pull in-memory history from Overseer when request is submitted 
to any node and when the API is in non-persistent mode (the data is not 
available then in the {{.system}} collection)
* report the source node where the data was obtained from. When in "index" mode 
the source node is always the one where the request was submitted to.

> Improve status reporting of metrics history API
> ---
>
> Key: SOLR-12438
> URL: https://issues.apache.org/jira/browse/SOLR-12438
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12438.patch
>
>
> In an offline conversation with [~janhoy] we identified the following areas 
> of improvement to the metrics history API in order to increase its 
> user-friendliness and provide more details about its status.
>  
> * there are three possible states for the API: inactive (when not in cloud 
> mode), in-memory only (when {{.system}} collection doesn’t exist), and 
> persisted when it’s both active and persisted in Solr. The 
> /admin/metrics/history endpoint should give some hint about this status, such 
> as "mode":"memory/index", "active": true|false. Or a separate action=status 
> just to poll status? Currently when the API is inactive it simply returns 404 
> Not Found.
> * when in "memory" mode a call to /admin/metrics/history on a non-overseer 
> node should forward the request to the overseer, so that the client does not 
> need to care what mode it is in - kind of like how a query works in 
> distributed mode.
> * better documentation for the API behavior in each mode.
> * perhaps if mode=memory, there could also be a "message":"Warning, metrics 
> history is not being persisted. Please create the .system collection to start 
> persisting history"



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

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

[jira] [Updated] (SOLR-12395) Typo in SignificantTermsQParserPlugin.NAME

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12395:
---
Attachment: SOLR-12395.patch

> Typo in SignificantTermsQParserPlugin.NAME
> --
>
> Key: SOLR-12395
> URL: https://issues.apache.org/jira/browse/SOLR-12395
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Affects Versions: 6.5, 7.3.1
>Reporter: Tobias Kässmann
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-12395.patch, SOLR-12395.patch, SOLR-12395.patch
>
>
> I think there is a small typo in the {{SignificantTermsQParserPlugin}}:
> {code:java}
> public static final String NAME = "sigificantTerms";{code}
> should be:
> {code:java}
> public static final String NAME = "significantTerms";{code}
>  See the patch attached.



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

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

[jira] [Updated] (SOLR-12438) Improve status reporting of metrics history API

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12438:
-
Attachment: SOLR-12438.patch

> Improve status reporting of metrics history API
> ---
>
> Key: SOLR-12438
> URL: https://issues.apache.org/jira/browse/SOLR-12438
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12438.patch
>
>
> In an offline conversation with [~janhoy] we identified the following areas 
> of improvement to the metrics history API in order to increase its 
> user-friendliness and provide more details about its status.
>  
> * there are three possible states for the API: inactive (when not in cloud 
> mode), in-memory only (when {{.system}} collection doesn’t exist), and 
> persisted when it’s both active and persisted in Solr. The 
> /admin/metrics/history endpoint should give some hint about this status, such 
> as "mode":"memory/index", "active": true|false. Or a separate action=status 
> just to poll status? Currently when the API is inactive it simply returns 404 
> Not Found.
> * when in "memory" mode a call to /admin/metrics/history on a non-overseer 
> node should forward the request to the overseer, so that the client does not 
> need to care what mode it is in - kind of like how a query works in 
> distributed mode.
> * better documentation for the API behavior in each mode.
> * perhaps if mode=memory, there could also be a "message":"Warning, metrics 
> history is not being persisted. Please create the .system collection to start 
> persisting history"



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

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-10) - Build # 2060 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/2060/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseG1GC

5 tests failed.
FAILED:  org.apache.solr.handler.tagger.Tagger2Test.testStopWords

Error Message:
[]: didn't find expected TestTag{[2-6] doc=1:'A City A' substr=City} (of 1); 
java.lang.AssertionError: array lengths differed, expected.length=1 
actual.length=0

Stack Trace:
java.lang.AssertionError: []: didn't find expected TestTag{[2-6] doc=1:'A City 
A' substr=City} (of 1); java.lang.AssertionError: array lengths differed, 
expected.length=1 actual.length=0
at 
__randomizedtesting.SeedInfo.seed([F0F9D611072326FE:730A59C99E070F0D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertSortedArrayEquals(TaggerTestCase.java:199)
at 
org.apache.solr.handler.tagger.TaggerTestCase.assertTags(TaggerTestCase.java:132)
at 
org.apache.solr.handler.tagger.Tagger2Test.testStopWords(Tagger2Test.java:102)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:47)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12233:


Commit 0c6f38a315d0df5abd01e7d4efe481bc53444a49 in lucene-solr's branch 
refs/heads/master from Jeff
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0c6f38a ]

SOLR-12233: QParserPlugin's static registry of builtins can be optimized
 to avoid needless ClassLoader activity on SolrCore load.


> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12233.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[jira] [Commented] (SOLR-12454) tweak Overseer leadership transition related logging

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12454:


Attached proposed patch which is intended to make it easier to troubleshoot and 
debug Overseer leadership transition related problems.

cc/fyi [~romseygeek] and [~janhoy] w.r.t. the earlier SOLR-5563 changes. This 
here would revert a small number of those info-to-debug changes but the changes 
are very selective and targetted at code paths that should not happen on a 
regular basis (e.g. {{am_i_leader unclear}}) or that happen infrequently i.e. 
overseer leadership transition. What do you think?


> tweak Overseer leadership transition related logging
> 
>
> Key: SOLR-12454
> URL: https://issues.apache.org/jira/browse/SOLR-12454
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12454.patch
>
>
> Proposed patch to follow.



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

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

[jira] [Updated] (SOLR-12454) tweak Overseer leadership transition related logging

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12454:
---
Attachment: SOLR-12454.patch

> tweak Overseer leadership transition related logging
> 
>
> Key: SOLR-12454
> URL: https://issues.apache.org/jira/browse/SOLR-12454
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12454.patch
>
>
> Proposed patch to follow.



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

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

[jira] [Created] (SOLR-12454) tweak Overseer leadership transition related logging

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-12454:
--

 Summary: tweak Overseer leadership transition related logging
 Key: SOLR-12454
 URL: https://issues.apache.org/jira/browse/SOLR-12454
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke


Proposed patch to follow.



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

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

[jira] [Resolved] (SOLR-12376) New TaggerRequestHandler (aka SolrTextTagger)

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-12376.
-
Resolution: Fixed

> New TaggerRequestHandler (aka SolrTextTagger)
> -
>
> Key: SOLR-12376
> URL: https://issues.apache.org/jira/browse/SOLR-12376
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12376.patch, SOLR-12376.patch, SOLR-12376.patch
>
>
> This issue introduces a new RequestHandler: {{TaggerRequestHandler}}, AKA the 
> SolrTextTagger from the OpenSextant project 
> [https://github.com/OpenSextant/SolrTextTagger]. It's used for named entity 
> recognition (NER) of text past to it. It doesn't do any NLP (outside of 
> Lucene text analysis) so it's said to be a "naive tagger", but it's 
> definitely useful as-is and a more complete NER or ERD (entity recognition 
> and disambiguation) system can be built with this as a key component. The 
> SolrTextTagger has been used on queries for query-understanding, and it's 
> been used on full-text, and it's been used on dictionaries that number tens 
> of millions in size. Since it's small and has been used a bunch (including 
> helping win an ERD competition and in [Apache 
> Stanbol|https://stanbol.apache.org/]), several people have asked me when or 
> why isn't this in Solr yet. So here it is.
> To use it, first you need a collection of documents that have a name-like 
> field (short text) indexed with the ConcatenateFilter (LUCENE-8323) at the 
> end. We call this the dictionary. Once that's in place, you simply post text 
> to a {{TaggerRequestHandler}} and it returns the offset pairs into that text 
> for matches in the dictionary along with the uniqueKey of the matching 
> documents. It can also return other document data desired. That's the gist; 
> I'll add more details on use to the Solr Reference Guide.



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

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

[jira] [Commented] (SOLR-12376) New TaggerRequestHandler (aka SolrTextTagger)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12376:


Commit 39bec86593ae72ca7799c2e331ace7679e628dda in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=39bec86 ]

SOLR-12376: New TaggerRequestHandler (SolrTextTagger).

(cherry picked from commit cf63392)


> New TaggerRequestHandler (aka SolrTextTagger)
> -
>
> Key: SOLR-12376
> URL: https://issues.apache.org/jira/browse/SOLR-12376
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12376.patch, SOLR-12376.patch, SOLR-12376.patch
>
>
> This issue introduces a new RequestHandler: {{TaggerRequestHandler}}, AKA the 
> SolrTextTagger from the OpenSextant project 
> [https://github.com/OpenSextant/SolrTextTagger]. It's used for named entity 
> recognition (NER) of text past to it. It doesn't do any NLP (outside of 
> Lucene text analysis) so it's said to be a "naive tagger", but it's 
> definitely useful as-is and a more complete NER or ERD (entity recognition 
> and disambiguation) system can be built with this as a key component. The 
> SolrTextTagger has been used on queries for query-understanding, and it's 
> been used on full-text, and it's been used on dictionaries that number tens 
> of millions in size. Since it's small and has been used a bunch (including 
> helping win an ERD competition and in [Apache 
> Stanbol|https://stanbol.apache.org/]), several people have asked me when or 
> why isn't this in Solr yet. So here it is.
> To use it, first you need a collection of documents that have a name-like 
> field (short text) indexed with the ConcatenateFilter (LUCENE-8323) at the 
> end. We call this the dictionary. Once that's in place, you simply post text 
> to a {{TaggerRequestHandler}} and it returns the offset pairs into that text 
> for matches in the dictionary along with the uniqueKey of the matching 
> documents. It can also return other document data desired. That's the gist; 
> I'll add more details on use to the Solr Reference Guide.



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

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

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

[Apache Jenkins Server]

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

10 tests failed.
FAILED:  
org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringAbortWithThreadsOnlyOnce

Error Message:
MockDirectoryWrapper: cannot close: there are still 34 open files: {_1.tvd=1, 
_1_MockRandom_0.pos=1, _1.nvd=1, _3_Lucene70_0.dvd=1, _0.nvd=1, _2.fdt=1, 
_3_MockRandom_0.doc=1, _4.fdx=1, _2_MockRandom_0.tio=1, _2.nvd=1, _2.tvd=1, 
_0_MockRandom_0.doc=1, _0_Lucene70_0.dvd=1, _2_MockRandom_0.pos=1, _1.fdt=1, 
_5.fdx=1, _1_MockRandom_0.doc=1, _3.nvd=1, _5.fdt=1, _5.tvx=1, 
_1_Lucene70_0.dvd=1, _4.tvd=1, _3.tvd=1, _3_MockRandom_0.tim=1, _0.fdt=1, 
_0_MockRandom_0.pos=1, _0.tvd=1, _2_MockRandom_0.doc=1, _4.fdt=1, _4.tvx=1, 
_2_Lucene70_0.dvd=1, _3_MockRandom_0.pos=1, _5.tvd=1, _3.fdt=1}

Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still 
34 open files: {_1.tvd=1, _1_MockRandom_0.pos=1, _1.nvd=1, _3_Lucene70_0.dvd=1, 
_0.nvd=1, _2.fdt=1, _3_MockRandom_0.doc=1, _4.fdx=1, _2_MockRandom_0.tio=1, 
_2.nvd=1, _2.tvd=1, _0_MockRandom_0.doc=1, _0_Lucene70_0.dvd=1, 
_2_MockRandom_0.pos=1, _1.fdt=1, _5.fdx=1, _1_MockRandom_0.doc=1, _3.nvd=1, 
_5.fdt=1, _5.tvx=1, _1_Lucene70_0.dvd=1, _4.tvd=1, _3.tvd=1, 
_3_MockRandom_0.tim=1, _0.fdt=1, _0_MockRandom_0.pos=1, _0.tvd=1, 
_2_MockRandom_0.doc=1, _4.fdt=1, _4.tvx=1, _2_Lucene70_0.dvd=1, 
_3_MockRandom_0.pos=1, _5.tvd=1, _3.fdt=1}
at 
__randomizedtesting.SeedInfo.seed([AD843BE13B0BB289:FAD21C009EBAF7D7]:0)
at 
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:841)
at 
org.apache.lucene.index.TestIndexWriterWithThreads._testMultipleThreadsFailure(TestIndexWriterWithThreads.java:341)
at 
org.apache.lucene.index.TestIndexWriterWithThreads.testIOExceptionDuringAbortWithThreadsOnlyOnce(TestIndexWriterWithThreads.java:464)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
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 

[jira] [Commented] (SOLR-12376) New TaggerRequestHandler (aka SolrTextTagger)

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12376:


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

SOLR-12376: New TaggerRequestHandler (SolrTextTagger).


> New TaggerRequestHandler (aka SolrTextTagger)
> -
>
> Key: SOLR-12376
> URL: https://issues.apache.org/jira/browse/SOLR-12376
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12376.patch, SOLR-12376.patch, SOLR-12376.patch
>
>
> This issue introduces a new RequestHandler: {{TaggerRequestHandler}}, AKA the 
> SolrTextTagger from the OpenSextant project 
> [https://github.com/OpenSextant/SolrTextTagger]. It's used for named entity 
> recognition (NER) of text past to it. It doesn't do any NLP (outside of 
> Lucene text analysis) so it's said to be a "naive tagger", but it's 
> definitely useful as-is and a more complete NER or ERD (entity recognition 
> and disambiguation) system can be built with this as a key component. The 
> SolrTextTagger has been used on queries for query-understanding, and it's 
> been used on full-text, and it's been used on dictionaries that number tens 
> of millions in size. Since it's small and has been used a bunch (including 
> helping win an ERD competition and in [Apache 
> Stanbol|https://stanbol.apache.org/]), several people have asked me when or 
> why isn't this in Solr yet. So here it is.
> To use it, first you need a collection of documents that have a name-like 
> field (short text) indexed with the ConcatenateFilter (LUCENE-8323) at the 
> end. We call this the dictionary. Once that's in place, you simply post text 
> to a {{TaggerRequestHandler}} and it returns the offset pairs into that text 
> for matches in the dictionary along with the uniqueKey of the matching 
> documents. It can also return other document data desired. That's the gist; 
> I'll add more details on use to the Solr Reference Guide.



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

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

[jira] [Commented] (LUCENE-7976) Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of very large segments

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-7976:


Simon: 

Thanks, I'll be able to work on this sometime this week I hope.

I'm trying to keep "scope creep" from happening too much here so may add 
another JIRA or two for things that are pre-existing. I'll detail when I 
incorporate your comments.

I won't consider committing this before the 7.4 version is cut, if for no other 
reason than I want this to get as much mileage as possible before it's included 
in a release.

6,000 iterations of TestTieredMergePolicy later and no failures so I'm starting 
to feel optimistic.

> Make TieredMergePolicy respect maxSegmentSizeMB and allow singleton merges of 
> very large segments
> -
>
> Key: LUCENE-7976
> URL: https://issues.apache.org/jira/browse/LUCENE-7976
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch, 
> LUCENE-7976.patch, LUCENE-7976.patch, LUCENE-7976.patch
>
>
> We're seeing situations "in the wild" where there are very large indexes (on 
> disk) handled quite easily in a single Lucene index. This is particularly 
> true as features like docValues move data into MMapDirectory space. The 
> current TMP algorithm allows on the order of 50% deleted documents as per a 
> dev list conversation with Mike McCandless (and his blog here:  
> https://www.elastic.co/blog/lucenes-handling-of-deleted-documents).
> Especially in the current era of very large indexes in aggregate, (think many 
> TB) solutions like "you need to distribute your collection over more shards" 
> become very costly. Additionally, the tempting "optimize" button exacerbates 
> the issue since once you form, say, a 100G segment (by 
> optimizing/forceMerging) it is not eligible for merging until 97.5G of the 
> docs in it are deleted (current default 5G max segment size).
> The proposal here would be to add a new parameter to TMP, something like 
>  (no, that's not serious name, suggestions 
> welcome) which would default to 100 (or the same behavior we have now).
> So if I set this parameter to, say, 20%, and the max segment size stays at 
> 5G, the following would happen when segments were selected for merging:
> > any segment with > 20% deleted documents would be merged or rewritten NO 
> > MATTER HOW LARGE. There are two cases,
> >> the segment has < 5G "live" docs. In that case it would be merged with 
> >> smaller segments to bring the resulting segment up to 5G. If no smaller 
> >> segments exist, it would just be rewritten
> >> The segment has > 5G "live" docs (the result of a forceMerge or optimize). 
> >> It would be rewritten into a single segment removing all deleted docs no 
> >> matter how big it is to start. The 100G example above would be rewritten 
> >> to an 80G segment for instance.
> Of course this would lead to potentially much more I/O which is why the 
> default would be the same behavior we see now. As it stands now, though, 
> there's no way to recover from an optimize/forceMerge except to re-index from 
> scratch. We routinely see 200G-300G Lucene indexes at this point "in the 
> wild" with 10s of  shards replicated 3 or more times. And that doesn't even 
> include having these over HDFS.
> Alternatives welcome! Something like the above seems minimally invasive. A 
> new merge policy is certainly an alternative.



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

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

[jira] [Commented] (SOLR-11982) Add support for indicating preferred replica types for queries

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-11982:
--

+1

> Add support for indicating preferred replica types for queries
> --
>
> Key: SOLR-11982
> URL: https://issues.apache.org/jira/browse/SOLR-11982
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.4, master (8.0)
>Reporter: Ere Maijala
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
>  Labels: patch-available, patch-with-test
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11982-preferReplicaTypes.patch, 
> SOLR-11982-preferReplicaTypes.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch
>
>
> It would be nice to have the possibility to easily sort the shards in the 
> preferred order e.g. by replica type. The attached patch adds support for 
> {{shards.sort}} parameter that allows one to sort e.g. PULL and TLOG replicas 
> first with \{{shards.sort=replicaType:PULL|TLOG }}(which would mean that NRT 
> replicas wouldn't be hit with queries unless they're the only ones available) 
> and/or to sort by replica location (like preferLocalShards=true but more 
> versatile).



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

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

[jira] [Comment Edited] (SOLR-11982) Add support for indicating preferred replica types for queries

[JIRA]

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

Tomás Fernández Löbbe edited comment on SOLR-11982 at 6/5/18 5:49 PM:
--

I think this is expected, at least with the current state of things. A TLOG 
replica that is leader doesn't stop being a TLOG replica (the replica type is 
recorded on the cluster state and doesn't change). IMO, what we want is a rule 
that one can use to prefer leader (or not leader, which would be more common). 
Something like {{shards.preference=isLeader:false replicaType:TLOG}}


was (Author: tomasflobbe):
I think this is expected, at least with the current state of things. A TLOG 
replica that is leader doesn't stop being a TLOG replica (the replica type is 
recorded on the cluster state and doesn't change). IMO, what we want is a rule 
that one can use to prefer leader (or not leader, which would be more common). 
Something like {{shards.prefernce=isLeader:false replicaType:TLOG}}

> Add support for indicating preferred replica types for queries
> --
>
> Key: SOLR-11982
> URL: https://issues.apache.org/jira/browse/SOLR-11982
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.4, master (8.0)
>Reporter: Ere Maijala
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
>  Labels: patch-available, patch-with-test
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-11982-preferReplicaTypes.patch, 
> SOLR-11982-preferReplicaTypes.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch
>
>
> It would be nice to have the possibility to easily sort the shards in the 
> preferred order e.g. by replica type. The attached patch adds support for 
> {{shards.sort}} parameter that allows one to sort e.g. PULL and TLOG replicas 
> first with \{{shards.sort=replicaType:PULL|TLOG }}(which would mean that NRT 
> replicas wouldn't be hit with queries unless they're the only ones available) 
> and/or to sort by replica location (like preferLocalShards=true but more 
> versatile).



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

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

Re: Badapple report, rehabilitating annotated tests. Please read the intro and comment.

[Erick Erickson]

Got it, thanks Adrien.

Anyone else: If you have tests you don't want enabled, let me know.
I'll add to a permanent list and add to the report.



On Tue, Jun 5, 2018 at 10:06 AM, Adrien Grand  wrote:
> Hi Erick,
>
> Le mar. 5 juin 2018 à 18:19, Erick Erickson  a
> écrit :
>>
>>  TestControlledRealTimeReopenThread.testCRTReopen
>
>
> This test relies on wall clock time, it needs to be refactored before being
> enabled again.
>
>> TestICUNormalizer2CharFilter.testRandomStrings
>
>
> We did several ICU4J upgrades since we disabled that one, so it's not
> impossible that the issue got fixed. I just ran 1000 beasting iterations
> without a failure. I'm good with re-enabling it.
>
>>
>>  TestICUTokenizerCJK
>
>
> This one is due to a bug in ICU4J which still affects the latest release,
> let's keep it disabled.
>

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

Re: Badapple report, rehabilitating annotated tests. Please read the intro and comment.

[Adrien Grand]

Hi Erick,

Le mar. 5 juin 2018 à 18:19, Erick Erickson  a
écrit :

>  TestControlledRealTimeReopenThread.testCRTReopen


This test relies on wall clock time, it needs to be refactored before being
enabled again.

TestICUNormalizer2CharFilter.testRandomStrings
>

We did several ICU4J upgrades since we disabled that one, so it's not
impossible that the issue got fixed. I just ran 1000 beasting iterations
without a failure. I'm good with re-enabling it.


>  TestICUTokenizerCJK
>

This one is due to a bug in ICU4J which still affects the latest release,
let's keep it disabled.

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-12444:
--

Hi Noble,

Can the test not use System.out.println and use a logger?

Also shouldn't we be asserting the new policy "cores < 3" to verify if the 
update was successful ?

> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[jira] [Commented] (LUCENE-8347) BlendedInfixSuggester to handle multi term matches better

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8347:


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


This message was automatically generated.



> BlendedInfixSuggester to handle multi term matches better
> -
>
> Key: LUCENE-8347
> URL: https://issues.apache.org/jira/browse/LUCENE-8347
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8347.patch
>
>
> Currently the blendedInfix suggester considers just the first match position 
> when scoring a suggestion.
> From the lucene-dev mailing list :
> "
> If I write more than one term in the query, let's say 
>  
> "Mini Bar Fridge" 
>  
> I would expect in the results something like (note that allTermsRequired=true 
> and the schema weight field always returns 1000)
>  
> - *Mini Bar Fridge* something
> - *Mini Bar Fridge* something else
> - *Mini Bar* something *Fridge*        
> - *Mini Bar* something else *Fridge*
> - *Mini* something *Bar Fridge*
> ...
>  
> Instead I see this: 
>  
> - *Mini Bar* something *Fridge*        
> - *Mini Bar* something else *Fridge*
> - *Mini Bar Fridge* something
> - *Mini Bar Fridge* something else
> - *Mini* something *Bar Fridge*
> ...
>  
> After having a look at the suggester code 
> (BlendedInfixSuggester.createCoefficient), I see that the component takes in 
> account only one 

[JENKINS] Lucene-Solr-repro - Build # 761 - Still unstable

[Apache Jenkins Server]

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

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

[repro] Revision: e7a0a12926c399758a4021715a7419e22e59dab6

[repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9
[repro] Repro line:  ant test  -Dtestcase=SolrRrdBackendFactoryTest 
-Dtests.method=testBasic -Dtests.seed=63F72A1C4CC41B54 -Dtests.multiplier=2 
-Dtests.locale=es-UY -Dtests.timezone=America/Goose_Bay -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] Repro line:  ant test  -Dtestcase=TestRandomFlRTGCloud 
-Dtests.method=testRandomizedUpdatesAndRTGs -Dtests.seed=63F72A1C4CC41B54 
-Dtests.multiplier=2 -Dtests.locale=es -Dtests.timezone=Iceland 
-Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

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

[...truncated 2 lines...]
[repro] git checkout e7a0a12926c399758a4021715a7419e22e59dab6

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

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

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

[...truncated 3299 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.TestRandomFlRTGCloud|*.SolrRrdBackendFactoryTest" 
-Dtests.showOutput=onerror 
-DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 
-Dtests.seed=63F72A1C4CC41B54 -Dtests.multiplier=2 -Dtests.locale=es 
-Dtests.timezone=Iceland -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1

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

[repro] Failures:
[repro]   1/5 failed: org.apache.solr.metrics.rrd.SolrRrdBackendFactoryTest
[repro]   2/5 failed: org.apache.solr.cloud.TestRandomFlRTGCloud
[repro] git checkout c587598096cde769c299594fb26d0a23b7bd5930

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

[...truncated 5 lines...]

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 24176 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2214 links (1768 relative) to 3107 anchors in 246 files
 [echo] Validated Links & Anchors via: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz
 into 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

[ASF subversion and git services (JIRA)]

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

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

Commit 3694bbdaaf9f9b094db364c892cd707facb0d680 in lucene-solr's branch 
refs/heads/branch_7x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3694bbd ]

LUCENE-7960: fix Solr test to include mandatory args

(cherry picked from commit c587598)


> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Assignee: Robert Muir
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch, 
> LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



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

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

[jira] [Resolved] (SOLR-12451) Not able to run Solr application

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-12451.
---
Resolution: Information Provided

This issue tracker is not a support portal. Please raise this question on the 
user's list at solr-u...@lucene.apache.org, see: 
(http://lucene.apache.org/solr/community.html#mailing-lists-irc) there are a 
_lot_ more people watching that list who may be able to help and you'll 
probably get responses much more quickly.

If it's determined that this really is a code issue in Solr and not a 
configuration/usage problem, we can raise a new JIRA or reopen this one.

It's very unlikely that any fixes will be made to 4x, and it's highly likely 
that this is "pilot error" or someone would have noticed it in the last 5 years.

> Not able to run Solr application
> 
>
> Key: SOLR-12451
> URL: https://issues.apache.org/jira/browse/SOLR-12451
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.3
> Environment: 
> http://maven.apache.org/POM/4.0.0;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>  4.0.0
>  com.citi.solrsearch
>  spark-solr
>  1.0-SNAPSHOT
>  
>  
>  org.apache.spark
>  spark-core_2.10
>  1.6.0
>  
>  
>  
>  com.lucidworks.spark
>  spark-solr
>  2.1.0
>  
>  
>  
>  org.apache.solr
>  solr-core
>  4.10.3
>  
>  
>  
>  
>  
>  
>  
>  
>  maven-compiler-plugin
>  3.5.1
>  
>  1.7
>  1.7
>  
>  
>  
>  org.apache.maven.plugins
>  maven-assembly-plugin
>  2.4.1
>  
>  
>  jar-with-dependencies
>  
>  
>  
>  
>  make-assembly
>  package
>  
>  single
>  
>  
>  
>  
>  
>  
> 
>  
> ===
> export 
> HADOOP_CLASSPATH=/opt/cloudera/parcels/CDH-5.9.1-1.cdh5.9.1.p2964.3211/jars
>  export CLASSPATH="$CLASSPATH:$HADOOP_CLASSPATH"
>  spark-submit \
>  --master yarn-client \
>  --class com.citi.solrsearch.SolrSearch \
>  --conf 
> spark.executor.extraJavaOptions=-Djava.security.auth.login.config=/home/icttdnee/Sprinter/solrCitiscreening/jaas-client.conf
>  \
>  --conf 
> spark.jars.excludes=/opt/cloudera/parcels/CDH-5.9.1-1.cdh5.9.1.p2964.3211/jars/httpclient-4.2.5.jar
>  \
>  --conf 
> spark.jars.excludes=/opt/cloudera/parcels/CDH-5.9.1-1.cdh5.9.1.p2964.3211/jars/httpcore-4.2.5.jar
>  \
>  --conf spark.driver.userClassPathFirst=false \
>  --conf spark.executor.userClassPathFirst=false \
>  --conf spark.driver.userClassPathFirst=false \
>  --conf spark.executor.userClassPathFirst=false \
>  --conf 
> spark.driver.extraClassPath=/home/icttdnee/citiscreen_solr/httpclient-4.4.1.jar,/home/icttdnee/citiscreen_solr/httpcore-4.4.1.jar
>  \
>  --conf 
> spark.executor.extraClassPath=/home/icttdnee/citiscreen_solr/httpclient-4.4.1.jar,/home/icttdnee/citiscreen_solr/httpcore-4.4.1.jar
>  \
>  --jars 
> /home/icttdnee/citiscreen_solr/spark-solr-2.1.0.jar,/home/pd94468/scala-logging_2.11-3.4.0.jar,/home/icttdnee/citiscreen_solr/spark-core_2.11-1.6.0.jar,/home/icttdnee/citiscreen_solr/httpclient-4.4.1.jar,/home/icttdnee/citiscreen_solr/httpcore-4.4.1.jar
>  \
>  
> /home/icttdnee/citiscreen_solr/spark-solr-1.0-SNAPSHOT-jar-with-dependencies.jar
>  \
>  https://bdgtr012x07h2.nam.nsroot.net:8985/solr/icttdnee_ttsd_collection \
>  =alert_id:[16000%20TO%20*]
>Reporter: Pravin Dahare
>Priority: Major
>
> Exception in thread "main" com.google.common.util.concurrent.ExecutionError: 
> java.lang.VerifyError: Bad return type
> Exception Details:
>  Location:
>  
> org/apache/solr/client/solrj/impl/HttpClientUtil.createClient(Lorg/apache/solr/common/params/SolrParams;Lorg/apache/http/conn/ClientConnectionManager;)Lorg/apache/http/impl/client/CloseableHttpClient;
>  @58: areturn
>  Reason:
>  Type 'org/apache/http/impl/client/DefaultHttpClient' (current frame, 
> stack[0]) is not assignable to 
> 'org/apache/http/impl/client/CloseableHttpClient' (from method signature)
>  Current Frame:
>  bci: @58
>  flags: \{ }
>  locals: \{ 'org/apache/solr/common/params/SolrParams', 
> 'org/apache/http/conn/ClientConnectionManager', 
> 'org/apache/solr/common/params/ModifiableSolrParams', 
> 'org/apache/http/impl/client/DefaultHttpClient' }
>  stack: \{ 'org/apache/http/impl/client/DefaultHttpClient' }
>  Bytecode:
>  0x000: bb00 0359 2ab7 0004 4db2 0005 b900 0601
>  0x010: 0099 001e b200 05bb 0007 59b7 0008 1209
>  0x020: b600 0a2c b600 0bb6 000c b900 0d02 002b
>  0x030: b800 104e 2d2c b800 0f2d b0
>  Stackmap Table:
>  append_frame(@47,Object[#143])
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232)
>  at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
>  at 

[jira] [Commented] (LUCENE-7960) NGram filters -- preserve the original token when it is outside the min/max size range

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7960: fix Solr test to include mandatory args


> NGram filters -- preserve the original token when it is outside the min/max 
> size range
> --
>
> Key: LUCENE-7960
> URL: https://issues.apache.org/jira/browse/LUCENE-7960
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Shawn Heisey
>Assignee: Robert Muir
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-7960.patch, LUCENE-7960.patch, LUCENE-7960.patch, 
> LUCENE-7960.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When ngram or edgengram filters are used, any terms that are shorter than the 
> minGramSize are completely removed from the token stream.
> This is probably 100% what was intended, but I've seen it cause a lot of 
> problems for users.  I am not suggesting that the default behavior be 
> changed.  That would be far too disruptive to the existing user base.
> I do think there should be a new boolean option, with a name like 
> keepShortTerms, that defaults to false, to allow the short terms to be 
> preserved.



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

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

[jira] [Resolved] (SOLR-12453) Allow extending QueryElevationComponent

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-12453.
-
Resolution: Duplicate

Markus, please see SOLR-11865 and let me know (there) if it ought to be even 
more extensible.

> Allow extending QueryElevationComponent
> ---
>
> Key: SOLR-12453
> URL: https://issues.apache.org/jira/browse/SOLR-12453
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12453.patch
>
>
> Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
> elevator as well. Up until now i had to copy all code and it becomes a real 
> mess like this.



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

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

[jira] [Commented] (SOLR-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-12233:
-

Here's a patch, updated to master, which meant adding FilterQParserPlugin.
I'm running the test stuite / precommit and will commit if it checks out.  My 
tentative CHANGES.txt will be as follows:

(Optimizations)
* SOLR-12233: QParserPlugin's built-in static qparser registry now holds actual 
QParserPlugin instances instead of class references. This is consistent with 
other plugin registries and allows a SolrCore to load faster.  (Jeff Miller, 
David Smiley)

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12233.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[jira] [Commented] (SOLR-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[Jeff Miller (JIRA)]

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

Jeff Miller commented on SOLR-12233:


[~elyograg] I just saw your comment,  interesting you brought that up.  I did 
disable a bunch of the implicit handlers in the json file since they were 
showing up as heavy hitter during profiling also.  Another issue I'm tracking 
but isn't an easy fix is PluginBag loading of plugins from SolrConfig.java,  
the class seems to look for anything implementing those interfaces and uses 
reflection to look up and create instances of the classes. This is real heavy 
work if a lot of core loads are happening.

Apparently very few customers use core loading often so this doesn't seem to be 
widely benefitting and some of it ends up staying custom code on our side.

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12233.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[jira] [Updated] (SOLR-12233) QParserPlugin maintains a list of classes recreated every time a Solrcore object is created

[David Smiley (JIRA)]

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

David Smiley updated SOLR-12233:

Attachment: SOLR-12233.patch

> QParserPlugin maintains a list of classes recreated every time a Solrcore 
> object is created
> ---
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.1.1
>Reporter: Jeff Miller
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-12233.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and 
> everytime we create a SolrCore object this causes a lot of overhead doing 
> classloader lookups.  Our system runs a lot of cores and the classloader gets 
> bogged down when a lot of threads are creating solrcore objects.  
> There's no need to create these objects every time, similar classes such as 
> TransformerFactory store the object one time and reference it over and over 
> again



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

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

[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Michael Braun (JIRA)]

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

Michael Braun commented on LUCENE-8345:
---

Thanks for the feedback - will have an update in the next day!

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Assignee: Uwe Schindler
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[jira] [Commented] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11865:
-

Here's our final patch. My CHANGES.txt will be as follows:

New Features:
 * The QueryElevationComponent now has a useConfiguredElevatedOrder setting. 
When multiple docs are elevated, this specifies wether their relative order 
should be the order in the configuration file or if not then should they be 
subject to whatever the sort criteria is.

Other:
 * Extensive refactoring of internals of the QueryElevationComponent to allow 
for better customization. Affects tie-ins with CollapseQParser & marker doc 
transformers that honor QEC's adjustments.

> Refactor QueryElevationComponent to prepare query subset matching
> -
>
> Key: SOLR-11865
> URL: https://issues.apache.org/jira/browse/SOLR-11865
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Affects Versions: master (8.0)
>Reporter: Bruno Roustant
>Priority: Minor
>  Labels: QueryComponent
> Fix For: master (8.0)
>
> Attachments: 
> 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, 
> 0002-Refactor-QueryElevationComponent-after-review.patch, 
> 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch, 
> SOLR-11865.patch, SOLR-11865.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The goal is to prepare a second improvement to support query terms subset 
> matching or query elevation rules.
> Before that, we need to refactor the QueryElevationComponent. We make it 
> extendible. We introduce the ElevationProvider interface which will be 
> implemented later in a second patch to support subset matching. The current 
> full-query match policy becomes a default simple MapElevationProvider.
> - Add overridable methods to handle exceptions during the component 
> initialization.
> - Add overridable methods to provide the default values for config properties.
> - No functional change beyond refactoring.
> - Adapt unit test.



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

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

[jira] [Updated] (SOLR-11865) Refactor QueryElevationComponent to prepare query subset matching

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11865:

Attachment: SOLR-11865.patch

> Refactor QueryElevationComponent to prepare query subset matching
> -
>
> Key: SOLR-11865
> URL: https://issues.apache.org/jira/browse/SOLR-11865
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SearchComponents - other
>Affects Versions: master (8.0)
>Reporter: Bruno Roustant
>Priority: Minor
>  Labels: QueryComponent
> Fix For: master (8.0)
>
> Attachments: 
> 0001-Refactor-QueryElevationComponent-to-introduce-Elevat.patch, 
> 0002-Refactor-QueryElevationComponent-after-review.patch, 
> 0003-Remove-exception-handlers-and-refactor-getBoostDocs.patch, 
> SOLR-11865.patch, SOLR-11865.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The goal is to prepare a second improvement to support query terms subset 
> matching or query elevation rules.
> Before that, we need to refactor the QueryElevationComponent. We make it 
> extendible. We introduce the ElevationProvider interface which will be 
> implemented later in a second patch to support subset matching. The current 
> full-query match policy becomes a default simple MapElevationProvider.
> - Add overridable methods to handle exceptions during the component 
> initialization.
> - Add overridable methods to provide the default values for config properties.
> - No functional change beyond refactoring.
> - Adapt unit test.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 22182 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22182/
Java: 64bit/jdk-10.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC

8 tests failed.
FAILED:  org.apache.solr.update.TransactionLogTest.testBigLastAddSize

Error Message:
For input string: "00014585187184600904052"

Stack Trace:
java.lang.NumberFormatException: For input string: 
"00014585187184600904052"
at 
__randomizedtesting.SeedInfo.seed([A0139866407ED4D5:B8E936CDA93028D4]:0)
at 
java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Long.parseLong(Long.java:692)
at java.base/java.lang.Long.parseLong(Long.java:817)
at org.apache.solr.update.TransactionLog.(TransactionLog.java:153)
at org.apache.solr.update.TransactionLog.(TransactionLog.java:141)
at 
org.apache.solr.update.TransactionLogTest.testBigLastAddSize(TransactionLogTest.java:34)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
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:  org.apache.solr.update.TransactionLogTest.testBigLastAddSize

Error Message:
For input string: "00017562828306972596406"

Stack Trace:
java.lang.NumberFormatException: For input string: 
"00017562828306972596406"
at 
__randomizedtesting.SeedInfo.seed([A0139866407ED4D5:B8E936CDA93028D4]:0)

Re: Lucene/Solr 7.4

[Christian Moen]

+1

On Tue, Jun 5, 2018 at 5:24 PM Adrien Grand  wrote:

> Hi all,
>
> We released 7.3 two months ago on April 4th and we accumulated quite a
> number of features, enhancements and fixes that are not released yet, so
> I'd like to start working on releasing Lucene/Solr 7.4.0.
>
> I propose to create the 7.4 branch later this week and build the first RC
> early next week if that works for everyone. Please let me know if that are
> bug fixes that we think should make it to 7.4 and might not be ready by
> then.
>
> Adrien
>

RE: Lucene/Solr 7.4

[Uwe Schindler]

Hi,

 

+1 for doing this. I just need some time to bring in a security-related fix.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Adrien Grand  
Sent: Tuesday, June 5, 2018 9:24 AM
To: Lucene Dev 
Subject: Lucene/Solr 7.4

 

Hi all,

We released 7.3 two months ago on April 4th and we accumulated quite a number 
of features, enhancements and fixes that are not released yet, so I'd like to 
start working on releasing Lucene/Solr 7.4.0.

I propose to create the 7.4 branch later this week and build the first RC early 
next week if that works for everyone. Please let me know if that are bug fixes 
that we think should make it to 7.4 and might not be ready by then.

Adrien

[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8345:
---

Maybe we should also add {{new String(String)}}, has same issue. There is only 
a legal use case for doing this if you need something that is not identical to 
an already interened string. But String interning is no longer a use-case in 
Lucene (since Lucene 4).

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Assignee: Uwe Schindler
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8345:
---

Hi,
looks fine!

I compared it with the autogenerated Java 9 deprecations already shipped with 
forbiddenapis:
- 
https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-deprecated-9.txt#L185-L193
- 
https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-deprecated-9.txt#L185-L193
- 
https://github.com/policeman-tools/forbidden-apis/blob/master/src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-deprecated-9.txt#L214-L215

You also added the Character ctor, cool!

I will take this issue, but I am on travel at the moment, so I will commit that 
tomorrow!

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[jira] [Assigned] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned LUCENE-8345:
-

Assignee: Uwe Schindler

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Assignee: Uwe Schindler
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[GitHub] lucene-solr pull request #392: LUCENE-8345 - add wrapper class constructors ...

[uschindler]

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

https://github.com/apache/lucene-solr/pull/392#discussion_r193109013
  
--- Diff: lucene/tools/forbiddenApis/base.txt ---
@@ -40,3 +40,21 @@ java.util.Collections#shuffle(java.util.List) @ Use 
shuffle(List, Random) instea
 
 java.util.Locale#forLanguageTag(java.lang.String) @ use new 
Locale.Builder().setLanguageTag(...).build() which has error handling
 java.util.Locale#toString() @ use Locale#toLanguageTag() for a 
standardized BCP47 locale name
+
+@defaultMessage Constructors for wrapper classes of Java primitives should 
be avoided in favor of the public static methods available or autoboxingT
--- End diff --

there is a typo at the end!


---

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

[jira] [Commented] (SOLR-12417) velocity response writer v.json should enforce valid function name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12417:


Commit 90e8be7a8e4251f896aba844324189e161d18a3c in lucene-solr's branch 
refs/heads/branch_7x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=90e8be7 ]

SOLR-12417: doc: fix CHANGES credit


> velocity response writer v.json should enforce valid function name
> --
>
> Key: SOLR-12417
> URL: https://issues.apache.org/jira/browse/SOLR-12417
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: VelocityResponseWriter should enforce that v.json 
> parameter is just a function name
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Attachments: SOLR-12417.patch
>
>




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

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

[jira] [Commented] (SOLR-12417) velocity response writer v.json should enforce valid function name

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12417:


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

SOLR-12417: doc: fix CHANGES credit


> velocity response writer v.json should enforce valid function name
> --
>
> Key: SOLR-12417
> URL: https://issues.apache.org/jira/browse/SOLR-12417
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: VelocityResponseWriter should enforce that v.json 
> parameter is just a function name
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
>Priority: Major
> Attachments: SOLR-12417.patch
>
>




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

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

[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-12453:
-
Fix Version/s: 7.4

> Allow extending QueryElevationComponent
> ---
>
> Key: SOLR-12453
> URL: https://issues.apache.org/jira/browse/SOLR-12453
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12453.patch
>
>
> Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
> elevator as well. Up until now i had to copy all code and it becomes a real 
> mess like this.



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

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

[jira] [Comment Edited] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

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

mosh edited comment on SOLR-12209 at 6/5/18 2:29 PM:
-

[~joel.bernstein]
I have just uploaded a new patch in which the tests were moved to 
StreamDecoratorTest.


was (Author: moshebla):
I have just uploaded a new patch in which the tests were moved to 
StreamDecoratorTest.

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: mosh
>Priority: Major
> Attachments: SOLR-12209.patch, SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



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

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

[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-12453:
-
Attachment: SOLR-12453.patch

> Allow extending QueryElevationComponent
> ---
>
> Key: SOLR-12453
> URL: https://issues.apache.org/jira/browse/SOLR-12453
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-12453.patch
>
>
> Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
> elevator as well. Up until now i had to copy all code and it becomes a real 
> mess like this.



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

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

[jira] [Commented] (SOLR-12453) Allow extending QueryElevationComponent

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-12453:
--

This patch changes:
* private to protected
* protected where no visibility is specified
* properly indents inner class ElevationComparatorSource


> Allow extending QueryElevationComponent
> ---
>
> Key: SOLR-12453
> URL: https://issues.apache.org/jira/browse/SOLR-12453
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: SOLR-12453.patch
>
>
> Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
> elevator as well. Up until now i had to copy all code and it becomes a real 
> mess like this.



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

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

[jira] [Updated] (SOLR-12453) Allow extending QueryElevationComponent

[Markus Jelsma (JIRA)]

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

Markus Jelsma updated SOLR-12453:
-
Environment: (was: Similar to SOLR-7968 for extending QueryComponent, i 
would love to extend the elevator as well. Up until now i had to copy all code 
and it becomes a real mess like this.


)
Description: 
Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
elevator as well. Up until now i had to copy all code and it becomes a real 
mess like this.




> Allow extending QueryElevationComponent
> ---
>
> Key: SOLR-12453
> URL: https://issues.apache.org/jira/browse/SOLR-12453
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.3.1
>Reporter: Markus Jelsma
>Priority: Minor
> Fix For: master (8.0)
>
>
> Similar to SOLR-7968 for extending QueryComponent, i would love to extend the 
> elevator as well. Up until now i had to copy all code and it becomes a real 
> mess like this.



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

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

[jira] [Created] (SOLR-12453) Allow extending QueryElevationComponent

[Markus Jelsma (JIRA)]

Markus Jelsma created SOLR-12453:


 Summary: Allow extending QueryElevationComponent
 Key: SOLR-12453
 URL: https://issues.apache.org/jira/browse/SOLR-12453
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.3.1
 Environment: Similar to SOLR-7968 for extending QueryComponent, i 
would love to extend the elevator as well. Up until now i had to copy all code 
and it becomes a real mess like this.



Reporter: Markus Jelsma
 Fix For: master (8.0)






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

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

[jira] [Commented] (LUCENE-8345) Add wrapper class constructors to forbiddenapis

[Michael Braun (JIRA)]

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

Michael Braun commented on LUCENE-8345:
---

[~thetaphi] does this patch look sufficient? 

> Add wrapper class constructors to forbiddenapis
> ---
>
> Key: LUCENE-8345
> URL: https://issues.apache.org/jira/browse/LUCENE-8345
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael Braun
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Wrapper classes for the Java primitives (Boolean, Byte, Short, Character, 
> Integer, Long, Float, Double) have constructors which will always create new 
> objects. These constructors are officially deprecated as of Java 9 and it is 
> recommended to use the public static methods since these can reuse the same 
> underlying objects. In 99% of cases we should be doing this, so these 
> constructors should be added to forbiddenapis and code corrected to use 
> autoboxing or call the static methods (.valueOf, .parse*) explicitly. 



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

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

[jira] [Commented] (LUCENE-8299) Geo3D: Change factory method for polygons

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8299:
--

Works for me.

> Geo3D: Change factory method for polygons
> -
>
> Key: LUCENE-8299
> URL: https://issues.apache.org/jira/browse/LUCENE-8299
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-8299.patch
>
>
> In LUCENE-8220 it was introduced a new factory method that chooses the best 
> technology for the provided polygon. In particular, this factory provides a 
> better support when creating a polygon with a list of points > 100 and in 
> some situations when tiling of the polygon is not possible.



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

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

[jira] [Commented] (LUCENE-8299) Geo3D: Change factory method for polygons

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8299:
--

[~jpountz], is it ok to push this chage for 7.4? It improves the support for 
large polygons of the Geo3D wrapper.

> Geo3D: Change factory method for polygons
> -
>
> Key: LUCENE-8299
> URL: https://issues.apache.org/jira/browse/LUCENE-8299
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-8299.patch
>
>
> In LUCENE-8220 it was introduced a new factory method that chooses the best 
> technology for the provided polygon. In particular, this factory provides a 
> better support when creating a polygon with a list of points > 100 and in 
> some situations when tiling of the polygon is not possible.



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

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

[jira] [Assigned] (LUCENE-8299) Geo3D: Change factory method for polygons

[Ignacio Vera (JIRA)]

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

Ignacio Vera reassigned LUCENE-8299:


Assignee: Ignacio Vera

> Geo3D: Change factory method for polygons
> -
>
> Key: LUCENE-8299
> URL: https://issues.apache.org/jira/browse/LUCENE-8299
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-8299.patch
>
>
> In LUCENE-8220 it was introduced a new factory method that chooses the best 
> technology for the provided polygon. In particular, this factory provides a 
> better support when creating a polygon with a list of points > 100 and in 
> some situations when tiling of the polygon is not possible.



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

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

Re: Lucene/Solr 7.4

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 5 giu 2018 alle ore 14:53 Michael McCandless <
luc...@mikemccandless.com> ha scritto:

> +1
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Jun 5, 2018 at 4:24 AM, Adrien Grand  wrote:
>
>> Hi all,
>>
>> We released 7.3 two months ago on April 4th and we accumulated quite a
>> number of features, enhancements and fixes that are not released yet, so
>> I'd like to start working on releasing Lucene/Solr 7.4.0.
>>
>> I propose to create the 7.4 branch later this week and build the first RC
>> early next week if that works for everyone. Please let me know if that are
>> bug fixes that we think should make it to 7.4 and might not be ready by
>> then.
>>
>> Adrien
>>
>
>

[jira] [Commented] (SOLR-6734) Standalone solr as *two* applications -- Solr and a controlling agent

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6734:


I've been thinking about how an agent might facilitate setting up a fault 
tolerant SolrCloud, complete with ZK servers.

Users would start out by running a command like "bin/solr cloudbuild start" on 
one node that has been installed as a service.  This would start or reconfigure 
the agent in a mode where it can begin communicating with other agents.  Then 
another command or set of commands would be run on that first node to set it up 
with necessary services for the cluster.

If multicast communication can be written in Java with relatively simple code, 
that would allow the agents to communicate with each other on LAN subnet and 
form a SolrCloud cluster without explicit address/hostname configuration.  If 
somebody got really ambitious and configured multicast routing, they could even 
do it on different subnets or across datacenters.

I envision using 239.89.83.0 as a default multicast address.  UDP port 8983 
seems fitting to use as a default.  As each node is configured, with additional 
"bin/solr cloudbuild" commands, it will begin sending periodic status packets 
on the configured multicast group, which every node will listen to and build a 
whole picture of the cluster.

Once there are at least three nodes configured, another command, perhaps 
"bin/solr cloudbuild build", can be called.  If the overall cluster config 
passes validation, this will signal each node to write its configuration for ZK 
and Solr, start (or restart) the services, and turn off cloudbuild mode.  If 
everything goes well, the user will have a functional fault-tolerant SolrCloud 
install, without any need to worry about how to install ZK as a separate 
service.

I have most of this idea mapped out in my head at a high level.  It will 
require fleshing out to realize as usable code.


> Standalone solr as *two* applications -- Solr and a controlling agent
> -
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Shawn Heisey
>Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a 
> standalone app, Mark Miller included the idea of making Solr into two 
> applications, rather than just one.  There would be Solr itself, and an agent 
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 22181 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22181/
Java: 32bit/jdk1.8.0_172 -client -XX:+UseConcMarkSweepGC

8 tests failed.
FAILED:  org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir

Error Message:
Captured an uncaught exception in thread: Thread[id=244, 
name=cdcr-replicator-64-thread-1, state=RUNNABLE, 
group=TGRP-CdcrBidirectionalTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=244, name=cdcr-replicator-64-thread-1, 
state=RUNNABLE, group=TGRP-CdcrBidirectionalTest]
Caused by: java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([2F9556F55C6D0C4C]:0)
at 
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611)
at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125)
at 
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir

Error Message:
Captured an uncaught exception in thread: Thread[id=18843, 
name=cdcr-replicator-4297-thread-1, state=RUNNABLE, 
group=TGRP-CdcrBidirectionalTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=18843, name=cdcr-replicator-4297-thread-1, 
state=RUNNABLE, group=TGRP-CdcrBidirectionalTest]
Caused by: java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([2F9556F55C6D0C4C]:0)
at 
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611)
at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125)
at 
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.core.ResourceLoaderTest.testAwareCompatibility

Error Message:
Configuration Error: missing parameter 'minGramSize'

Stack Trace:
java.lang.IllegalArgumentException: Configuration Error: missing parameter 
'minGramSize'
at 
__randomizedtesting.SeedInfo.seed([2F9556F55C6D0C4C:6DF514852541E519]:0)
at 
org.apache.lucene.analysis.util.AbstractAnalysisFactory.require(AbstractAnalysisFactory.java:97)
at 
org.apache.lucene.analysis.util.AbstractAnalysisFactory.requireInt(AbstractAnalysisFactory.java:157)
at 
org.apache.lucene.analysis.ngram.NGramFilterFactory.(NGramFilterFactory.java:44)
at 
org.apache.solr.core.ResourceLoaderTest.testAwareCompatibility(ResourceLoaderTest.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
   

[jira] [Commented] (SOLR-12387) Have cluster-wide defaults for numShards, nrtReplicas, tlogReplicas, pullReplicas

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12387:


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

SOLR-12387: fixing a test failure


> Have cluster-wide defaults for numShards, nrtReplicas, tlogReplicas, 
> pullReplicas
> -
>
> Key: SOLR-12387
> URL: https://issues.apache.org/jira/browse/SOLR-12387
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12387.patch
>
>
> These will be cluster properties and the commands can omit these and the 
> command would pick it up from the cluster properties
>  
> the cluster property names are
> {code}
>  "collectionDefaults": {
>  "numShards":1
>  "nrtReplicas":1
>  "tlogReplicas":1
>  }
> {code}



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

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

[jira] [Commented] (SOLR-12387) Have cluster-wide defaults for numShards, nrtReplicas, tlogReplicas, pullReplicas

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12387:
---

a test failure
{code}
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateCollWithDefaultClusterProperties

Failing for the past 1 build (Since Unstable#634 )
Took 1.7 sec.
Error Message
Error from server at https://127.0.0.1:40716/solr: numShards is a required 
param (when using CompositeId router).
Stacktrace
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:40716/solr: numShards is a required param 
(when using CompositeId router).
at 
__randomizedtesting.SeedInfo.seed([C5B61E61129CAF52:76627549ECB86DF6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
{code}

> Have cluster-wide defaults for numShards, nrtReplicas, tlogReplicas, 
> pullReplicas
> -
>
> Key: SOLR-12387
> URL: https://issues.apache.org/jira/browse/SOLR-12387
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-12387.patch
>
>
> These will be cluster properties and the commands can omit these and the 
> command would pick it up from the cluster properties
>  
> the cluster property names are
> {code}
>  "collectionDefaults": {
>  "numShards":1
>  "nrtReplicas":1
>  "tlogReplicas":1
>  }
> {code}



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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 2556 - Unstable

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration

Error Message:
did not finish processing in time

Stack Trace:
java.lang.AssertionError: did not finish processing in time
at 
__randomizedtesting.SeedInfo.seed([282E135EB6F5EBB6:7B9751EE54E47E4C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:425)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration

Error Message:
events: [CapturedEvent{timestamp=28458056867832987, stage=STARTED, 
actionName='null', event={   "id":"651a726a4583c3Tdyttr4e1weqaq52lgtv5wco82",   
"source":"index_size_trigger2",   "eventTime":28458051359310787,   

[jira] [Commented] (LUCENE-8344) TokenStreamToAutomaton doesn't ignore trailing posInc when preservePositionIncrements=false

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8344:


{quote}we could simply consider the fix a breaking change and discuss if it's 
acceptable to backport to 7x ?
{quote}
+1

> TokenStreamToAutomaton doesn't ignore trailing posInc when 
> preservePositionIncrements=false
> ---
>
> Key: LUCENE-8344
> URL: https://issues.apache.org/jira/browse/LUCENE-8344
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/suggest
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8344.patch, LUCENE-8344.patch
>
>
> TokenStreamToAutomaton in Lucene core is used by the AnalyzingSuggester 
> (incl. FuzzySuggester subclass ) and NRT Document Suggester and soon the 
> SolrTextTagger.  It has a setting {{preservePositionIncrements}} defaulting 
> to true.  If it's set to false (e.g. to ignore stopwords) and if there is a 
> _trailing_ position increment greater than 1, TS2A will _still_ add position 
> increments (holes) into the automata even though it was configured not to.
> I'm filing this issue separate from LUCENE-8332 where I first found it.  The 
> fix is very simple but I'm concerned about back-compat ramifications so I'm 
> filing it separately.  I'll attach a patch to show the problem.



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

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

Re: Lucene/Solr 7.4

[Michael McCandless]

+1

Mike McCandless

http://blog.mikemccandless.com

On Tue, Jun 5, 2018 at 4:24 AM, Adrien Grand  wrote:

> Hi all,
>
> We released 7.3 two months ago on April 4th and we accumulated quite a
> number of features, enhancements and fixes that are not released yet, so
> I'd like to start working on releasing Lucene/Solr 7.4.0.
>
> I propose to create the 7.4 branch later this week and build the first RC
> early next week if that works for everyone. Please let me know if that are
> bug fixes that we think should make it to 7.4 and might not be ready by
> then.
>
> Adrien
>

[jira] [Resolved] (SOLR-12444) Updating a cluster policy fails

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-12444.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12444:
---

The {{equals()}} implementation of {{Clause}} was wrong

> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12444:


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

SOLR-12444: Updating a cluster policy fails


> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

[jira] [Commented] (SOLR-12444) Updating a cluster policy fails

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12444:


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

SOLR-12444: Updating a cluster policy fails


> Updating a cluster policy fails
> ---
>
> Key: SOLR-12444
> URL: https://issues.apache.org/jira/browse/SOLR-12444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Varun Thacker
>Assignee: Noble Paul
>Priority: Major
>
> If I create a policy like this
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<4","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> Then I can never update this policy subsequently .
> To reproduce try changing the policy to 
> {code:java}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
> "set-cluster-policy": [
> {"cores": "<3","node": "#ANY"}
> ]
> }' http://localhost:8983/solr/admin/autoscaling{code}
> The policy will never change. The workaround is to clear the policy by 
> sending an empty array and then re-creating it 



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

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

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

[Apache Jenkins Server]

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

11 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.prometheus.exporter.SolrExporterTest

Error Message:
Error from server at http://127.0.0.1:39201/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-00

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:39201/solr: KeeperErrorCode = NoNode for 
/overseer/collection-queue-work/qnr-00
at __randomizedtesting.SeedInfo.seed([D8E35C07EF5B25D7]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.prometheus.exporter.SolrExporterTestBase.setupCluster(SolrExporterTestBase.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup

Error Message:
should be at least one inactive event

Stack Trace:
java.lang.AssertionError: should be at least one inactive event
at 
__randomizedtesting.SeedInfo.seed([1592638974C5ABA1:8BEA3FB15868CAA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.autoscaling.ScheduledMaintenanceTriggerTest.testInactiveShardCleanup(ScheduledMaintenanceTriggerTest.java:224)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at