[jira] [Comment Edited] (SOLR-9058) hashJoin does not work when "on" maps fields with "="

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-9058 at 5/5/16 11:09 PM:


This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. 
During construction it checks for an = in the field and if found will split 
into a left and right side field name. If not found then it uses that single 
field name for both the left and right side. It then uses those lists when 
reading tuples from the stream.

[~Osthold], good catch on this one and thank you for the test showing the 
failure (I swiped that and included it in the test case).


was (Author: dpgove):
This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. 
During construction it checks for an = in the field and if found will split 
into a left and right side field name. If not found then it uses that single 
field name for both the left and right side. It then uses those lists when 
reading tuples from the stream.

[~Osthold], good catch on this one and thank you for the test showing the 
failure (I swiped that and included it in the test cast).

> hashJoin does not work when "on" maps fields with "="
> -
>
> Key: SOLR-9058
> URL: https://issues.apache.org/jira/browse/SOLR-9058
> Project: Solr
>  Issue Type: Bug
>Reporter: Stephan Osthold
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9058.patch
>
>
> hashJoin does not work when "on" maps fields with "="
> eg.
> hashJoin(
>  ...
>  on="field1=field2"
> )
> See link for fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9058) hashJoin does not work when "on" maps fields with "="

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-9058 at 5/5/16 11:08 PM:


This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. 
During construction it checks for an = in the field and if found will split 
into a left and right side field name. If not found then it uses that single 
field name for both the left and right side. It then uses those lists when 
reading tuples from the stream.

Stephan, good catch on this one and thank you for the test showing the failure 
(I swiped that and included it in the test cast).


was (Author: dpgove):
This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. It 
checks for an = in the field and if found will split into a left and right side 
field name. If not found then it uses that single field name for both the left 
and right side.

> hashJoin does not work when "on" maps fields with "="
> -
>
> Key: SOLR-9058
> URL: https://issues.apache.org/jira/browse/SOLR-9058
> Project: Solr
>  Issue Type: Bug
>Reporter: Stephan Osthold
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9058.patch
>
>
> hashJoin does not work when "on" maps fields with "="
> eg.
> hashJoin(
>  ...
>  on="field1=field2"
> )
> See link for fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9058) hashJoin does not work when "on" maps fields with "="

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-9058 at 5/5/16 11:09 PM:


This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. 
During construction it checks for an = in the field and if found will split 
into a left and right side field name. If not found then it uses that single 
field name for both the left and right side. It then uses those lists when 
reading tuples from the stream.

[~Osthold], good catch on this one and thank you for the test showing the 
failure (I swiped that and included it in the test cast).


was (Author: dpgove):
This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. 
During construction it checks for an = in the field and if found will split 
into a left and right side field name. If not found then it uses that single 
field name for both the left and right side. It then uses those lists when 
reading tuples from the stream.

Stephan, good catch on this one and thank you for the test showing the failure 
(I swiped that and included it in the test cast).

> hashJoin does not work when "on" maps fields with "="
> -
>
> Key: SOLR-9058
> URL: https://issues.apache.org/jira/browse/SOLR-9058
> Project: Solr
>  Issue Type: Bug
>Reporter: Stephan Osthold
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9058.patch
>
>
> hashJoin does not work when "on" maps fields with "="
> eg.
> hashJoin(
>  ...
>  on="field1=field2"
> )
> See link for fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+116) - Build # 16665 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16665/
Java: 32bit/jdk-9-ea+116 -client -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers

Error Message:
exception w/handler: '/graph'

Stack Trace:
java.lang.RuntimeException: exception w/handler: '/graph'
at 
__randomizedtesting.SeedInfo.seed([9C2D63DA9E029EEA:7133D8E0150F9F6E]:0)
at 
org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers(MinimalSchemaTest.java:130)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)
Caused by: java.lang.RuntimeException: Exception during query
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:785)
at 
org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers(MinimalSchemaTest.java:121)
... 39 more
Caused by: org.xml.sax.SAXParseException; 

[jira] [Updated] (SOLR-8996) Add Random Streaming Expression

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-8996:
--
Attachment: SOLR-8996-decrease-failure-probability.patch

Increases the # of records in the test collection to reduce the probability of 
a failure from 1 in 5! (1 in 120) to 1 in 1000! (1 in basically never).

This still doesn't guarantee a passing test but greatly increases the 
probability of a passing test.

> Add Random Streaming Expression
> ---
>
> Key: SOLR-8996
> URL: https://issues.apache.org/jira/browse/SOLR-8996
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Dennis Gove
> Fix For: 6.1
>
> Attachments: RandomStream.java, 
> SOLR-8996-decrease-failure-probability.patch, SOLR-8996.patch
>
>
> The random Streaming Expression will return a *limited* random stream of 
> Tuples that match a query. This will be useful in many different scenarios 
> where random data sets are needed.
> Proposed syntax:
> {code}
> random(baskets, q="productID:productX", rows="100", fl="basketID") 
> {code}
> The sample code above will query the *baskets* collection and return 100 
> random *basketID's* where the productID is productX.
> The underlying implementation will rely on Solr's random field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-5.5-Java7 - Build # 25 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java7/25/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud

Error Message:
3 threads leaked from SUITE scope at 
org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=14171, 
name=Thread-5460, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud]   
  at java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
 at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355) 
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
 at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
 at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
 at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)   
  at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:915) 
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2603) at 
org.apache.solr.cloud.ZkController$5.run(ZkController.java:2479)2) 
Thread[id=13761, name=Thread-5403, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native 
Method) at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
 at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355) 
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
 at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
 at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
 at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)   
  at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:915) 
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2603) at 
org.apache.solr.cloud.ZkController$5.run(ZkController.java:2479)3) 
Thread[id=14567, name=Thread-5505, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud] at java.lang.Thread.sleep(Native 
Method) at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
 at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355) 
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
 at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
 at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
 at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)   
  at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:915) 
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2603) at 
org.apache.solr.cloud.ZkController$5.run(ZkController.java:2479)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE 
scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 
   1) Thread[id=14171, name=Thread-5460, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355)
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:915)
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2603)
at org.apache.solr.cloud.ZkController$5.run(ZkController.java:2479)
   2) Thread[id=13761, name=Thread-5403, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355)
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:915)
at 

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 266 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/266/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:36313/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:36313/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([91AE8EA7EC777680:19FAB17D428B1B78]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Shikha Somani (JIRA)]

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

Shikha Somani commented on SOLR-8297:
-

No.
HttpSolrClient was the only way through which join queries can be done in Solr 
4.x. Join query was not supported in cloud mode, it threw exception: 
"Cross-core join: no such core"

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8996) Add Random Streaming Expression

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-8996:
---

[~joel.bernstein], I saw a failure of the test for this stream. Because there 
are only 5 records in the collection during the test I believe there is a 
probability of 1 in 5! that the test will fail (1 in 120) because the two 
streams return the records in the same order. Below is a small patch that 
increases the # of records to 1000 thus decreasing the probability of a failure 
to 1 in 1000! (1 in basically never). Do you think it's worth re-opening this 
and applying the patch?

{code}
diff --git 
a/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java
 
b/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java
index d273477..267eeca 100644
--- 
a/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java
+++ 
b/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java
@@ -483,13 +483,12 @@ public class StreamExpressionTest extends 
SolrCloudTestCase {
   @Test
   public void testRandomStream() throws Exception {

-new UpdateRequest()
-.add(id, "0", "a_s", "hello0", "a_i", "0", "a_f", "0")
-.add(id, "2", "a_s", "hello2", "a_i", "2", "a_f", "0")
-.add(id, "3", "a_s", "hello3", "a_i", "3", "a_f", "3")
-.add(id, "4", "a_s", "hello4", "a_i", "4", "a_f", "4")
-.add(id, "1", "a_s", "hello1", "a_i", "1", "a_f", "1")
-.commit(cluster.getSolrClient(), COLLECTION);
+UpdateRequest update = new UpdateRequest();
+for(int idx = 0; idx < 1000; ++idx){
+  String idxString = new Integer(idx).toString();
+  update.add(id,idxString, "a_s", "hello" + idxString, "a_i", idxString, 
"a_f", idxString);
+}
+update.commit(cluster.getSolrClient(), COLLECTION);

 StreamExpression expression;
 TupleStream stream;
@@ -504,17 +503,17 @@ public class StreamExpressionTest extends 
SolrCloudTestCase {
 try {
   context.setSolrClientCache(cache);

-  expression = StreamExpressionParser.parse("random(" + COLLECTION + ", 
q=\"*:*\", rows=\"10\", fl=\"id, a_i\")");
+  expression = StreamExpressionParser.parse("random(" + COLLECTION + ", 
q=\"*:*\", rows=\"1000\", fl=\"id, a_i\")");
   stream = factory.constructStream(expression);
   stream.setStreamContext(context);
   List tuples1 = getTuples(stream);
-  assert (tuples1.size() == 5);
+  assert (tuples1.size() == 1000);

-  expression = StreamExpressionParser.parse("random(" + COLLECTION + ", 
q=\"*:*\", rows=\"10\", fl=\"id, a_i\")");
+  expression = StreamExpressionParser.parse("random(" + COLLECTION + ", 
q=\"*:*\", rows=\"1000\", fl=\"id, a_i\")");
   stream = factory.constructStream(expression);
   stream.setStreamContext(context);
   List tuples2 = getTuples(stream);
-  assert (tuples2.size() == 5);
+  assert (tuples2.size() == 1000);

   boolean different = false;
   for (int i = 0; i < tuples1.size(); i++) {
{code}

> Add Random Streaming Expression
> ---
>
> Key: SOLR-8996
> URL: https://issues.apache.org/jira/browse/SOLR-8996
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: RandomStream.java, SOLR-8996.patch
>
>
> The random Streaming Expression will return a *limited* random stream of 
> Tuples that match a query. This will be useful in many different scenarios 
> where random data sets are needed.
> Proposed syntax:
> {code}
> random(baskets, q="productID:productX", rows="100", fl="basketID") 
> {code}
> The sample code above will query the *baskets* collection and return 100 
> random *basketID's* where the productID is productX.
> The underlying implementation will rely on Solr's random field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 575 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/575/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers

Error Message:
exception w/handler: '/graph'

Stack Trace:
java.lang.RuntimeException: exception w/handler: '/graph'
at 
__randomizedtesting.SeedInfo.seed([474E911E2550F381:AA502A24AE5DF205]:0)
at 
org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers(MinimalSchemaTest.java:130)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: Exception during query
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:786)
at 
org.apache.solr.MinimalSchemaTest.testAllConfiguredHandlers(MinimalSchemaTest.java:121)
... 39 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; 
Content is not allowed in prolog.
at 

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-9065:
-

bq. can you please send a message to the dev list to announce your refactoring 
plans/schedule so help us coordinate our efforts? 

Will do so in the next couple of days.  Sorry for stepping on your toes, guys.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9058) hashJoin does not work when "on" maps fields with "="

[Dennis Gove (JIRA)]

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

Dennis Gove updated SOLR-9058:
--
Attachment: SOLR-9058.patch

This patch fixes up both hashJoin and outerHashJoin and adds tests for the 
scenario to both. 

The approach taken is to have a left and right list of fields to hash on. It 
checks for an = in the field and if found will split into a left and right side 
field name. If not found then it uses that single field name for both the left 
and right side.

> hashJoin does not work when "on" maps fields with "="
> -
>
> Key: SOLR-9058
> URL: https://issues.apache.org/jira/browse/SOLR-9058
> Project: Solr
>  Issue Type: Bug
>Reporter: Stephan Osthold
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9058.patch
>
>
> hashJoin does not work when "on" maps fields with "="
> eg.
> hashJoin(
>  ...
>  on="field1=field2"
> )
> See link for fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8996) Add Random Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8996:
--

Sure, sounds good.

> Add Random Streaming Expression
> ---
>
> Key: SOLR-8996
> URL: https://issues.apache.org/jira/browse/SOLR-8996
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: RandomStream.java, SOLR-8996.patch
>
>
> The random Streaming Expression will return a *limited* random stream of 
> Tuples that match a query. This will be useful in many different scenarios 
> where random data sets are needed.
> Proposed syntax:
> {code}
> random(baskets, q="productID:productX", rows="100", fl="basketID") 
> {code}
> The sample code above will query the *baskets* collection and return 100 
> random *basketID's* where the productID is productX.
> The underlying implementation will rely on Solr's random field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-9065 at 5/5/16 8:10 PM:
---

bq. just a "shout out" 

Follow the mailing list. We are not a *review then commit* project. The result 
that happened is how this should work. Then 9 out of 10 times we move fast, and 
once we make an adjustment to the commit.

Everyone just needs to relax. No one owns any area of the code, no one has to 
be checked with before changes. It's on anyone who cares to follow email and 
JIRA. This did not appear to be a controversial change, a patch went up, 
hossman +1'd.

This is how it's all supposed to work.


was (Author: markrmil...@gmail.com):
bq. just a "shout out" 

Follow the mailing list. We are not a commit then review project. The result 
that happened is how this should work. Then 9 out of 10 times we move fast, and 
once we make an adjustment to the commit.

Everyone just needs to relax. No one owns any area of the code, no one has to 
be checked with before changes. It's on anyone who cares to follow email and 
JIRA. This did not appear to be a controversial change, a patch went up, 
hossman +1'd.

This is how it's all supposed to work.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7271:
-
Description: 
Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
discussed in this mailing list thread...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E

The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0)}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.

I'm using this issue to track this work.



Detailed Check list of planned steps:

* S1: Generate a CSV report listing all resolved/closed Jira's with 
'fixVersion=master AND fixVersion=6.1'
** 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the 
fixVersion set correctly if/when they are resolved in the future
* S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
every issue currently assocaited with fixVersion=6.0 or fixVersio=master
** The comments will include unique strings based on the the specific query 
done, and will map the list back to this issue (ex 
{{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
** These comments will serve as a backup plan making it possible to find all 
issues affected (by merging jira's concepts of 'master' and '6.0') after the 
fact if need be.
** Queries to use for bulk edits:
*** master: 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
*** 6.0: 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
* S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
** This needs to be done distinctly for both LUCENE and SOLR
* S4: Add a new "master (7.0)" version to Jira
** This needs to be done distinctly for both LUCENE and SOLR
* S5: audit every issue in the CSV file from S1 above to determine if/when the 
issue should get fixVersion="master (7.0)" *added* to it or fixVersion="6.0" 
*removed* from it:
** if it only ever had commits to master (ie: before branch_6x was made on 
March 2nd) then no action needed.
** if it has distinct commits to both master after branch_6x was made on March 
2nd, then fixVersion="master (7.0)" should definitely be added.
** if it has no commits to branch_6_0, and the only commits to branch_6x are 
after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
removed.
** if there are no obvious commits in the issue comments, then sanity check why 
it has any fixVersion at all (can't reproduce? dup? etc...)
* S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
fixVersion="master (7.0)" on the handful of issues where appropriate in case 
they fell through the cracks in S5:
** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
features
*** currently only 1 jira mentioned in either files in 7.0 section
** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
'^\+'}} to find changesets on master that were not included in 6.0
*** currently ~40 commits
** before removing fixVersion=6.0 from any of these issues, sanity check if 
this is a deprecation type situation (involving diff commits in both 6.0 and 
master) in which case fixVersion="master (7.0)" should be _added_ in addition 
to fixVersion=6.0




  was:
Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
discussed in this mailing list thread...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E

The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0}}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.

I'm using this issue to track this work.



Detailed Check list of planned steps:

* S1: Generate a CSV report listing all resolved/closed Jira's with 
'fixVersion=master AND fixVersion=6.1'
** 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the 
fixVersion set correctly if/when they are resolved in the future
* S2: Use Jira's 

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_92) - Build # 157 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/157/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 8 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, TransactionLog, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, 
TransactionLog, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([18545C88E3F8E230]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.000:
 java.nio.file.FileSystemException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog\tlog.000:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data\tlog

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_18545C88E3F8E230-001\tempDir-001\node1\testschemaapi_shard1_replica2\data

[jira] [Commented] (SOLR-9076) Update to Hadoop 2.7.2

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9076:
---

I hit SOLR-7115 for some reason trying to get this to work. A workaround is 
currently included in this patch.

> Update to Hadoop 2.7.2
> --
>
> Key: SOLR-9076
> URL: https://issues.apache.org/jira/browse/SOLR-9076
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9076.patch, SOLR-9076.patch, SOLR-9076.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: SOLR-8323

[markrmiller]

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/32#issuecomment-217291207
  
> Although, thinking more about that, we already have a separate executor 
for watchers, don't we?

Yes, every watch firing event should run from a dedicated executor rather 
than using ZK's event thread. I have not dug in enough here to know it covers 
what you guys are talking about, but holding up a Watcher thread should no 
longer interfere with ZK clients internal event thread.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-8323) Add CollectionWatcher API to ZkStateReader

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8323:
--

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/32#issuecomment-217291207
  
> Although, thinking more about that, we already have a separate executor 
for watchers, don't we?

Yes, every watch firing event should run from a dedicated executor rather 
than using ZK's event thread. I have not dug in enough here to know it covers 
what you guys are talking about, but holding up a Watcher thread should no 
longer interfere with ZK clients internal event thread.


> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

No problem, and thanks for your work on the tests. It's a big improvement!

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (SOLR-8996) Add Random Streaming Expression

[Dennis Gove (JIRA)]

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

Dennis Gove reopened SOLR-8996:
---
  Assignee: Dennis Gove  (was: Joel Bernstein)

Re-opening to apply updated test.

> Add Random Streaming Expression
> ---
>
> Key: SOLR-8996
> URL: https://issues.apache.org/jira/browse/SOLR-8996
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Dennis Gove
> Fix For: 6.1
>
> Attachments: RandomStream.java, SOLR-8996.patch
>
>
> The random Streaming Expression will return a *limited* random stream of 
> Tuples that match a query. This will be useful in many different scenarios 
> where random data sets are needed.
> Proposed syntax:
> {code}
> random(baskets, q="productID:productX", rows="100", fl="basketID") 
> {code}
> The sample code above will query the *baskets* collection and return 100 
> random *basketID's* where the productID is productX.
> The underlying implementation will rely on Solr's random field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: solr.common.util.Pair --> commons.lang3.tuple.Pair

[Erick Erickson]

Or upgrade commons-lang

On Thu, May 5, 2016 at 10:01 AM, Shawn Heisey  wrote:
> On 5/5/2016 10:38 AM, Erick Erickson wrote:
>> Even for a trivial class, +1 to going to the commons version if it
>> doesn't include a new dependency.
>
> Solr currently has commons-lang 2.6 as a dependency.  The class
> mentioned in the subject says "lang3" ... so I think that would be a new
> dependency.  It would probably coexist with 2.6, but adding another 2
> megabytes to the download size for a trivial class does not seem like a
> good idea.
>
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Created] (SOLR-9076) Update to Hadoop 2.7.2

[Mark Miller (JIRA)]

Mark Miller created SOLR-9076:
-

 Summary: Update to Hadoop 2.7.2
 Key: SOLR-9076
 URL: https://issues.apache.org/jira/browse/SOLR-9076
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein reopened SOLR-9065:
--

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9075) Look at using hdfs-client jar in HDFS 2.8 for smaller core dependency.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9075:
--

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/34#issuecomment-217233476
  
I filed https://issues.apache.org/jira/browse/SOLR-9075 to look at 
shrinking the hdfs client dependency jars.


> Look at using hdfs-client jar in HDFS 2.8 for smaller core dependency.
> --
>
> Key: SOLR-9075
> URL: https://issues.apache.org/jira/browse/SOLR-9075
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

Yeah, but this was a wholesale change, committed one day after the patch went 
up. 

It's not hard to some have consideration for other peoples work. A simple heads 
up will suffice.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

A large patch went up yesterday for this ticket. The it's committed very 
quickly without consulting the people who are working these test cases.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9065 at 5/5/16 5:00 PM:
--

A large patch went up yesterday for this ticket. Then it's committed very 
quickly without consulting the people who are working with these test cases.


was (Author: joel.bernstein):
A large patch went up yesterday for this ticket. The it's committed very 
quickly without consulting the people who are working these test cases.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9065 at 5/5/16 5:01 PM:
--

Can we revert this ticket? I have a bunch of test cases ready to go for the 6.1 
release for the new Graph traversal features. This has blindsided me completely.


was (Author: joel.bernstein):
Can revert this ticket? I have a bunch of test cases ready to go for the 6.1 
release for the new Graph traversal features. This has blindsided me completely.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9070) how to range search on the field which contains multiple decimal point (eg: 2.5.0.4)

[David Smiley (JIRA)]

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

David Smiley updated SOLR-9070:
---
Affects Version/s: (was: 3.6.1)
 Priority: Major  (was: Blocker)
   Issue Type: Improvement  (was: Bug)

> how to range search on the field which contains multiple decimal point (eg: 
> 2.5.0.4)
> 
>
> Key: SOLR-9070
> URL: https://issues.apache.org/jira/browse/SOLR-9070
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Santhosh
>
> Hi,
> I have issue in my server. As I stated in the subject I want to do range 
> search query on the field (eg: filed name is “version”) which contains value 
> like (2.5.0.1, 2.5.0.4 and 2.5.0.10 etc).
> When I do range search on the “version” field with criteria [* TO 2.5.0.5], 
> it gave me all the value like (2.5.0.1, 2.5.0.10, 2.5.0.4). But this is wrong 
> result. Since I was expecting only 2.5.0.1 and 2.5.0.4. 
> But it include 2.5.0.10 with the results. I googled and found that solr does 
> lexical sorting. But I want numerical sorting. I declared the field type as 
> string in schema.xml.
> I did the following solution but nothing worked. 
> • Converted the field type to number. But it gave me 
> “NumberFormatException”.  Because java does not allow multiple decimal point.
> • I added left pad 0 with the value while adding document in solr. But no 
> luck
> Can you please give me good solution to come out of the issue?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: Don't allocate GeoPoints we aren't going to return.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7271:
--

I haven't seen any objections to this plan, and i haven't been able to think of 
any flaws or possible improvements.

My plan is to start working through these steps tomorrow (Friday) morning ~9AM 
my time, (~1600 UTC)

Steps S1-S4 will need to be done carefully and in a single block to reduce the 
risk of missing issues edited between steps (but obviously skimming mail for 
issues people modify during that window can be done after the fact).

Steps S5 & S6 should be done ASAP after that to reduce confusion as people 
read/edit jiras, but don't need to be rushed (ie: i'll go to lunch at some 
point) and can be divided up among multiple people if other folks want to 
volunteer.

I'll track progress with comments here, and attach the reports i generate from 
S1, S5, and S6 to this issue as i go.

I'll be on freenodes #lucene IRC channel the whole time if people have concerns 
or want to coordinate on helping out with S5 & S6.

> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0}}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if the 
> issue should get fixVersion="master (7.0)" *added* to it
> ** if it has distinct commits to both master & branch_6x then 
> fixVersion="master (7.0)" should be added
> ** if it only ever had commits to master (ie: before branch_6x was made) then 
> no action needed
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropraite:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



--
This message was 

Re: solr.common.util.Pair --> commons.lang3.tuple.Pair

[Erick Erickson]

Even for a trivial class, +1 to going to the commons version if it
doesn't include a new dependency.

On Thu, May 5, 2016 at 7:29 AM, Mark Miller  wrote:
> I probably made the Solr one. I don't know what else existed and didn't look
> - if I remember right, someone committed a Pair reference that came from a
> library not included on all platforms and I just made the class to fix the
> build since it's about 10 lines of boiler plate.
>
> - Mark
>
> On Thu, May 5, 2016 at 8:07 AM Christine Poerschke (BLOOMBERG/ LONDON)
>  wrote:
>>
>> Steve Davids wrote on another email thread: Though, out of curiosity why
>> not just use the Pair class in Apache Commons-Lang?
>>
>> http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/Pair.html
>>
>> I'd be +1 to switching over to org.apache.commons.lang3.tuple.Pair - it
>> seems possible now, perhaps the commons class didn't exist when the solr
>> variant was first created?
>>
>> Christine
>
> --
> - Mark
> about.me/markrmiller

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

Re: lucene-solr:master: added a couple of extra methods

[Erick Erickson]

Or use the apache commons Pair class and blame any inconsistencies on them ;)

On Wed, May 4, 2016 at 11:31 PM, Noble Paul  wrote:
> There is nothing more I hate than bikeshedding. So, here we go
>
> I'm gonna remove the getKey(), getValue() from pair and replace them with
> fist() and second(). No deprecation or anything.
> if anyone has any objection, please raise your hand and go ahead with your
> preferred names. I can live with any name because we have enough instances
> in Solr where naming is totally screwed up and I have managed to maintain my
> sanity all these years.
>
> Cheers
>
> On Thu, May 5, 2016 at 8:15 AM, Scott Blum  wrote:
>>
>> Thanks Hoss, I think I just spit coffee all over my keyboard :D
>>
>> Sometimes you just gotta grow a Pair API.
>>
>> On Wed, May 4, 2016 at 2:29 PM, Chris Hostetter 
>> wrote:
>>>
>>>
>>> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
>>>
>>> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
>>>
>>> how do those method names sound?
>>>
>>>
>>> : Date: Wed, 4 May 2016 14:26:41 -0400
>>> : From: Scott Blum 
>>> : Reply-To: dev@lucene.apache.org
>>> : To: dev@lucene.apache.org
>>> : Subject: Re: lucene-solr:master: added a couple of extra methods
>>> :
>>> : Or left() and right()
>>> :
>>> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
>>> : ichattopadhy...@gmail.com> wrote:
>>> :
>>> : > Another option to consider could be: first() and second()
>>> : >
>>> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>>> : >
>>> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
>>> wrote:
>>> : >
>>> : >> The names getKey() and getValue() are not always relevant for a pair
>>> : >> object. it's not necessarily a key and value. In that case, it makes
>>> sense
>>> : >> to use the index .
>>> : >>
>>> : >>
>>> : >> This is a convention followed Scala. Tuple2 (
>>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>>> : >>
>>> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter
>>> >> : >> > wrote:
>>> : >>
>>> : >>>
>>> : >>> WTF is this?
>>> : >>>
>>> : >>> why are these (poorly named) alternatives for getKey and getValue
>>> useful?
>>> : >>>
>>> : >>>
>>> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>>> : >>> : From: no...@apache.org
>>> : >>> : Reply-To: dev@lucene.apache.org
>>> : >>> : To: comm...@lucene.apache.org
>>> : >>> : Subject: lucene-solr:master: added a couple of extra methods
>>> : >>> :
>>> : >>> : Repository: lucene-solr
>>> : >>> : Updated Branches:
>>> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>>> : >>> :
>>> : >>> :
>>> : >>> : added a couple of extra methods
>>> : >>> :
>>> : >>> :
>>> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>>> : >>> : Commit:
>>> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>>> : >>> : Tree:
>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>>> : >>> : Diff:
>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>>> : >>> :
>>> : >>> : Branch: refs/heads/master
>>> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>>> : >>> : Parents: 0ebe6b0
>>> : >>> : Author: Noble Paul 
>>> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
>>> : >>> : Committer: Noble Paul 
>>> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
>>> : >>> :
>>> : >>> :
>>> --
>>> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
>>> 
>>> : >>> :  1 file changed, 8 insertions(+)
>>> : >>> :
>>> --
>>> : >>> :
>>> : >>> :
>>> : >>> :
>>> : >>>
>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : >>> :
>>> --
>>> : >>> : diff --git
>>> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : >>> : index 423f94c..f87323c 100644
>>> : >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : >>> : @@ -27,6 +27,14 @@ public class Pair implements
>>> Serializable {
>>> : >>> :
>>> : >>> :private V value;
>>> : >>> :
>>> : >>> : +  public K _1() {
>>> : >>> : +return key;
>>> : >>> : +  }
>>> : >>> : +
>>> : >>> : +  public V _2() {
>>> : >>> : +return value;
>>> : >>> : +  }
>>> : >>> : +
>>> : >>> :public V getValue() {
>>> : >>> :  return value;
>>> : >>> :}
>>> : >>> :
>>> : >>> :
>>> : >>>
>>> : >>> -Hoss
>>> : >>> 

Re: solr.common.util.Pair --> commons.lang3.tuple.Pair

[Shawn Heisey]

On 5/5/2016 10:38 AM, Erick Erickson wrote:
> Even for a trivial class, +1 to going to the commons version if it
> doesn't include a new dependency.

Solr currently has commons-lang 2.6 as a dependency.  The class
mentioned in the subject says "lang3" ... so I think that would be a new
dependency.  It would probably coexist with 2.6, but adding another 2
megabytes to the download size for a trivial class does not seem like a
good idea.

Shawn


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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

The following test cases were clearly under development at the time when this 
ticket was committed:

solr/solrj/src/test/org/apache/solr/client/solrj/io/graph/GraphExpressionTest.java
solr/solrj/src/test/org/apache/solr/client/solrj/io/graph/GraphTest.java
solr/solrj/src/test/org/apache/solr/client/solrj/io/sql/JdbcTest.java
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/JDBCStreamTest.java
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java
solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamingTest.java

All that needed to be done was to notify the committers who maintain these 
tests and let them know a wholesale change was coming. Then there could have 
been a conversation about how to move forward without stepping on peoples work. 
Instead a patch went up and the next day it was committed. 



> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9065:
---

We have a commit then review policy and generally favor forward progress.

I appreciate that Alan's work here has caused some concern around other work 
and 6.1. So what? Alan's work was fine and had multiple eyes on it. Now there 
are more eyes and Alan will be open to working with them as he always is.

If one of the tests that was converted needs to be un-converted or briefly 
un-converted, so what? Perhaps there are other short term options as well. It's 
a large code base and many issues cross a lot of code. We will step on each 
other's toes, it's part of the game.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: Move hdfs stuff out into a new contrib

[markrmiller]

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/34#issuecomment-217233476
  
I filed https://issues.apache.org/jira/browse/SOLR-9075 to look at 
shrinking the hdfs client dependency jars.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

Can revert this ticket? I have a bunch of test cases ready to go for the 6.1 
release for the new Graph traversal features. This has blindsided me completely.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

I'm going to put the old version of the GraphExpressionTest back in place so I 
can move forward.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9068:
---
Attachment: SOLR-9068.patch


bq. If this works I see not problem with the patch, because it is used during 
tests only. Right?

Correct, this is only a question of what SecureRandom source we use during 
tests (the idea being to prevent so low entropy jenkins machines from blocking 
when randomizing SSL testing)

bq. ... and for now disable the tests with assumeFalse(Constants.SUN_OS).

While this one test in particular seems to always trigger some Padding related 
problem in the SSLEngine, the underlying problem is something that *could* 
affect any SSL test (note that even with this test, the jenkins failures have 
*diff* Padding related Exceptions between master and 6x, presumably because 
some small amount of information in the Solr request/response payload is 
slightly diff between branches?) ... so if we do ultimately need to have 
special case logic when {{Constants.SUN_OS}} it shouldn't be specific to this 
test class/method, it should be part of the {{SSLTestConfig}} so we don't get 
confusing failures from any other test that might randomize SSL.

I've uploaded a new quick & dirty patch that uses a {{java.util.Random}} inside 
our {{NullSecureRandom}}.

[~thetaphi]: can you please try this new patch out?

* If this patch solves the problem I can come up with a better final fix that 
includes 2 diff "mock" SecureRandom instances and picks which one we use in 
SSLTestConfig depending on the {{Constants.SUN_OS}}.
* If this patch doesn't solve the problem then there is something more 
fundementally odd going on on Solaris (maybe our custom SecureRandomSpi is 
tickling some assumption in the JVM?) and I'll give up and just change 
SSLTestConfig to simply use the platform default SecureRandom on that OS.

bq. If you like a can give you an account on the Solaris machine to try 
yourself (keep in mind, it has neither GIT nor ANT installed, totally blank - 
all is provided by Jenkins).

No thank you -- that sounds terrible.  This is/should-be the last patch I'll 
ask you to manually try on Solaris

bq. Maybe we should open a bug report at Oracle ...

Probably, but from what i've seen you have to deal with in the past, don't have 
the time or patience to try and deal with their process.  If you want to file 
one by all means go ahead -- but you might want to wait until we figure out if 
using {{java.utilRandom}} under the covers works as a workarround, or if there 
is just some fundemental bug when using custom SecureRandom instances.




> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: Move hdfs stuff out into a new contrib

[markrmiller]

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/34#issuecomment-217231828
  
I'm not currently for this change. HDFS is currently built in and supported 
first class. I don't see a need to make anyone that wants to use it jump any 
more hoops to save a few dependency jars. I'm still looking at making the first 
class integration better rather than separating things further.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (SOLR-9074) solrj CloudSolrClient.directUpdate tweak

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9074:
---

+1

> solrj CloudSolrClient.directUpdate tweak
> 
>
> Key: SOLR-9074
> URL: https://issues.apache.org/jira/browse/SOLR-9074
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Trivial
> Attachments: SOLR-9074.patch
>
>
> Defer two NamedList allocations and initialCapacity one of them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

The wholesale reworking of tests needs to be coordinated with the people who 
wrote the original tests and maintain those tests.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9070) how to range search on the field which contains multiple decimal point (eg: 2.5.0.4)

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9070:


The solution is to left-pad with 0's.  You said you did that... but did you 
leave the field type as a string?  That should definitely work.  Next time for 
something like this, I suggest using the solr-user mailing list to ask how to 
do something.

I think I'll just close this issue as "not a problem".  I started by changing 
the issue to an improvement request but realistically I don't see it happening. 
 Of course if someone goes ahead and does it then great.

> how to range search on the field which contains multiple decimal point (eg: 
> 2.5.0.4)
> 
>
> Key: SOLR-9070
> URL: https://issues.apache.org/jira/browse/SOLR-9070
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Santhosh
>
> Hi,
> I have issue in my server. As I stated in the subject I want to do range 
> search query on the field (eg: filed name is “version”) which contains value 
> like (2.5.0.1, 2.5.0.4 and 2.5.0.10 etc).
> When I do range search on the “version” field with criteria [* TO 2.5.0.5], 
> it gave me all the value like (2.5.0.1, 2.5.0.10, 2.5.0.4). But this is wrong 
> result. Since I was expecting only 2.5.0.1 and 2.5.0.4. 
> But it include 2.5.0.10 with the results. I googled and found that solr does 
> lexical sorting. But I want numerical sorting. I declared the field type as 
> string in schema.xml.
> I did the following solution but nothing worked. 
> • Converted the field type to number. But it gave me 
> “NumberFormatException”.  Because java does not allow multiple decimal point.
> • I added left pad 0 with the value while adding document in solr. But no 
> luck
> Can you please give me good solution to come out of the issue?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-9070) how to range search on the field which contains multiple decimal point (eg: 2.5.0.4)

[David Smiley (JIRA)]

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

David Smiley closed SOLR-9070.
--
Resolution: Not A Problem

> how to range search on the field which contains multiple decimal point (eg: 
> 2.5.0.4)
> 
>
> Key: SOLR-9070
> URL: https://issues.apache.org/jira/browse/SOLR-9070
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Santhosh
>
> Hi,
> I have issue in my server. As I stated in the subject I want to do range 
> search query on the field (eg: filed name is “version”) which contains value 
> like (2.5.0.1, 2.5.0.4 and 2.5.0.10 etc).
> When I do range search on the “version” field with criteria [* TO 2.5.0.5], 
> it gave me all the value like (2.5.0.1, 2.5.0.10, 2.5.0.4). But this is wrong 
> result. Since I was expecting only 2.5.0.1 and 2.5.0.4. 
> But it include 2.5.0.10 with the results. I googled and found that solr does 
> lexical sorting. But I want numerical sorting. I declared the field type as 
> string in schema.xml.
> I did the following solution but nothing worked. 
> • Converted the field type to number. But it gave me 
> “NumberFormatException”.  Because java does not allow multiple decimal point.
> • I added left pad 0 with the value while adding document in solr. But no 
> luck
> Can you please give me good solution to come out of the issue?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9075) Look at using hdfs-client jar in HDFS 2.8 for smaller core dependency.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9075:
---

https://issues.apache.org/jira/browse/HDFS-6200

> Look at using hdfs-client jar in HDFS 2.8 for smaller core dependency.
> --
>
> Key: SOLR-9075
> URL: https://issues.apache.org/jira/browse/SOLR-9075
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9075) Look at using hdfs-client jar in HDFS 2.8 for smaller core dependency.

[Mark Miller (JIRA)]

Mark Miller created SOLR-9075:
-

 Summary: Look at using hdfs-client jar in HDFS 2.8 for smaller 
core dependency.
 Key: SOLR-9075
 URL: https://issues.apache.org/jira/browse/SOLR-9075
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9065:
---

There was a heads up on this issue. 9 times out of 10, this would have caused 
no concern. These kind of changes are made all the time. If we had to reach out 
to each person that might give a damn and wait a week for every change, we 
would slow down a little.

It's commit then review. Alan committed, no you are reviewing. That is how we 
do it.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9071) rename the getters in org.apache.solr.common.util.Pair class

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9071:
--

Noble:

There was a note I saw go by (not on this patch) asking if it would be better 
just to switch to the Apache commons pair class and remove the solr.common.util 
one

http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/Pair.html

Haven't looked personally, so don't know which makes more sense. 

> rename the getters in org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Attachments: SOLR-9071.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9065:
--

The wholesale reworking of the tests is making keeping 8467 up to date 
"interesting". Do we have a good read on when 6.1 will be coming out? If it's 
very far in the future I'd like to put 8467 to bed.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-9065 at 5/5/16 6:30 PM:
---

There was a heads up on this issue. 9 times out of 10, this would have caused 
no concern. These kind of changes are made all the time. If we had to reach out 
to each person that might give a damn and wait a week for every change, we 
would slow down a little.

It's commit then review. Alan committed, now you are reviewing. That is how we 
do it.


was (Author: markrmil...@gmail.com):
There was a heads up on this issue. 9 times out of 10, this would have caused 
no concern. These kind of changes are made all the time. If we had to reach out 
to each person that might give a damn and wait a week for every change, we 
would slow down a little.

It's commit then review. Alan committed, no you are reviewing. That is how we 
do it.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9065:
--

But this patch had 7000 lines of code and it went up yesterday. I think that's 
too fast. 

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Old Solr releases -- making it easier to find them

[Erick Erickson]

Good catch! Whenever I want a past version I already know to click on
the past archives link and didn't even notice that the page
disappears!

Actually, when I google for "apache solr", the second hit is the
downloads page and if you go there directly it doesn't automatically
go to the current version.

Personally I like not automatically redirecting

Erick

On Thu, May 5, 2016 at 8:01 AM, Shawn Heisey  wrote:
> When somebody is looking for an older release of Solr, currently it is
> somewhat non-obvious how to find it.  The "download" link on the Solr
> website *briefly* lands on a page with the proper link, but it only
> takes three seconds for this page to disappear and be replaced with a
> "mirror chooser" page where only the latest release can be found.
>
> I see two solutions, and we might want to consider implementing both:
>
> 1) Increase the delay on the download page before redirecting to the
> mirror chooser (15-30 seconds) or eliminate the automatic redirect
> entirely and just put a link to the mirror chooser on the page.
>
> 2) Place a link on the mirror chooser page for the archives.  Since this
> page is automatically generated by a script, I am not sure how much
> control we have over what shows up there.
>
> Normally I think links on the word "here" are bad form, because they are
> not easily located by site visitors.  An archives link on the mirror
> chooser page is an example of a time when it just might be appropriate.
> We could have something on the mirror chooser page that says "For older
> versions, visit the archives here".  In this case, it's actually a
> *good* thing to make that particular link require a second look -- so
> that a typical user that *does* want the latest version will not be
> drawn to the link.  Perhaps Infra could do this on the mirror chooser
> page for all projects.  I can open an issue with Infra.
>
> Thanks,
> Shawn
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9068:
-

Hi Hoss,

unfortunately, your patch did not change anything. I ran it with and without, 
in both cases it always failed on first time when beasting or running 
standalone.
Maybe we should open a bug report at Oracle and for now disable the tests with 
{{assumeFalse(Constants.SUN_OS)}}.

If you like a can give you an account on the Solaris machine to try yourself 
(keep in mind, it has neither GIT nor ANT installed, totally blank - all is 
provided by Jenkins).

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 57 - Still Failing

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:58336

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:58336
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:601)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:399)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:457)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: Don't allocate GeoPoints we aren't going to return.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9076) Update to Hadoop 2.7.2

[Mark Miller (JIRA)]

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

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

> Update to Hadoop 2.7.2
> --
>
> Key: SOLR-9076
> URL: https://issues.apache.org/jira/browse/SOLR-9076
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9076.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: solr.common.util.Pair --> commons.lang3.tuple.Pair

[Shawn Heisey]

On 5/5/2016 11:07 AM, Erick Erickson wrote:
> Or upgrade commons-lang

I did think of that, and thought it probably would not work because
commons-lang 2.x was almost guaranteed to be a sub-dependency to one of
Solr's other dependencies.

Just for giggles, I updated the ivy config to pull in 3.4 instead of
2.6.  I did "ant clean clean-jars clean-eclipse eclipse" and refreshed
the eclipse project ... I managed to figure out the correct ivy changes.

Then I used "organize imports" in Eclipse to fix the majority of the
errors - a bit of a sledgehammer approach, I admit.  There was one
source file where I had to adjust actual code, but the change was very
minor, and the javadoc suggested it wouldn't be an issue.  Then I ran
"ant clean server" and "bin\solr start -f" in the solr directory to see
if there would be any *obvious* problems where one of Solr's *other*
dependencies expected the legacy commons-lang jar.

Surprisingly, there were no immediate indications of problems.  Solr
started and the admin UI worked.  I did not try any other operations.

After a little more investigating, and seeing a ton of cloud tests
failing, I did learn that zookeeper (even 3.5 alpha versions) has an
optional dependency on commons-lang-2.4, so I tried "bin\solr -e cloud
-noprompt".  That's when it became apparent that this wasn't going to
work.  There are errors in the log about commons.lang classes not being
found.

Thanks,
Shawn


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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9065:


I agree with Joel.  And I don't think there's any hard feelings, just a "shout 
out" as Joel said would have been great.  [~romseygeek] can you please send a 
message to the dev list to announce your refactoring plans/schedule so help us 
coordinate our efforts?  That would be very helpful -- thanks in advance.

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8297:


Could you briefly clarify an early observed behavior: how many shards you had 
in "from" and "to" collections, one or many?  

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9054) The new GUI is using hardcoded paths

[Valerio Di Cagno (JIRA)]

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

Valerio Di Cagno commented on SOLR-9054:


Yes, we had to manually reenable the support for the jndi because the 
jetty-plus and the jetty-jndi modules were missing.

Also we need to make it possible to have different versions of Solr running at 
the same time and make the client work even if there is a rewrite rule or an 
host alias is active.


> The new GUI is using hardcoded paths
> 
>
> Key: SOLR-9054
> URL: https://issues.apache.org/jira/browse/SOLR-9054
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 6.0
>Reporter: Valerio Di Cagno
>
> If Apache Solr 6.0 is started without using the default context root "/solr"
> every admin service will not work properly and is not possible to use the 
> provided links to go back to the old GUI.
> In the javascript files sometimes the parameter config.solr_path is ignored
> or replaced with the value /solr returning 404 on access.
> Affected files: 
> solr-webapp/webapp/js/services.js
> Suggested solution:
> Complete the integration with /js/scripts/app.js



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [VOTE] Release Lucene/Solr 5.5.1

[Michael McCandless]

Good idea ;)

Mike McCandless

http://blog.mikemccandless.com

On Wed, May 4, 2016 at 4:45 PM, Joel Bernstein  wrote:

> 3 bugs fixes in Lucene! We should preface this with Lucene is riddled with
> bugs!
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Wed, May 4, 2016 at 4:04 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Oh sorry I thought there were 0 changes ;)
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Wed, May 4, 2016 at 3:16 PM, Anshum Gupta 
>> wrote:
>>
>>> Mike, there were 3 bug fixes as per the change log. Also, no fixes != no
>>> bugs :).
>>>
>>> On Wed, May 4, 2016 at 11:50 AM, Michael McCandless <
>>> luc...@mikemccandless.com> wrote:
>>>
 I think there were no Lucene changes in this release vs 5.5.0?

 So maybe the release notes should simply say:

   Lucene is perfect and has no bugs.

 Mike McCandless

 http://blog.mikemccandless.com

 On Wed, May 4, 2016 at 1:39 PM, Anshum Gupta 
 wrote:

> Here is a draft of the release notes. Feel free to edit and fix
> something that I missed,
>
> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
> Solr: https://wiki.apache.org/solr/ReleaseNote551
>
> On Wed, May 4, 2016 at 12:06 AM, Adrien Grand 
> wrote:
>
>> +1 SUCCESS! [0:57:52.080980]
>>
>> Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
>> écrit :
>>
>>> FYI, we generally don't consider weekends for the 72 hour window so
>>> we'd be waiting until Wednesday to close this one out.
>>> Thought I'd let everyone who's waiting know about this.
>>>
>>> On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta <
>>> ans...@anshumgupta.net> wrote:
>>>
 Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.

 Artifacts:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58

 Smoke tester:

   python3 -u dev-tools/scripts/smokeTestRelease.py
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58


 Here's my +1:

 SUCCESS! [0:26:44.452268]

 --
 Anshum Gupta

>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>
>
> --
> Anshum Gupta
>


>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>

[jira] [Updated] (SOLR-9071) rename the getters in org.apache.solr.common.util.Pair class

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9071:
-
Summary: rename the getters in org.apache.solr.common.util.Pair class  
(was: rename the getters in Org.apache.solr.common.util.Pair class)

> rename the getters in org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9071) rename the getters in Org.apache.solr.common.util.Pair class

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9071:
-
Summary: rename the getters in Org.apache.solr.common.util.Pair class  
(was: rename the getters in rg.apache.solr.common.util.Pair class)

> rename the getters in Org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-8993) New UI can't show DIH

[Javier (JIRA)]

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

Javier edited comment on SOLR-8993 at 5/5/16 8:07 AM:
--

I have the similar problem. I have two DIH's but in the new UI doesn't load the 
right configuration. In the new UI "dataimport-cacheable" and "dataimport" load 
data-config.xml
{code:xml}

  
  
  ${datasource.user} 
  ${datasource.password} 
  ${datasource.url} 
  
  
  data-config-full.xml
  
  

  
  
  ${datasource.user} 
  ${datasource.password} 
  ${datasource.url} 
  
  
  data-config.xml
  
  
{code}



was (Author: zeanrehivaj):
I have the similar problem. I have two DIH's but in the new UI doesn't load the 
right configuration. In the new UI "dataimport-cacheable" and "dataimport" load 
data-config.xml


  
  
  ${datasource.user} 
  ${datasource.password} 
  ${datasource.url} 
  
  
  data-config-full.xml
  
  

  
  
  ${datasource.user} 
  ${datasource.password} 
  ${datasource.url} 
  
  
  data-config.xml
  
  


> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, 
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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/jdk1.8.0_92) - Build # 16660 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16660/
Java: 64bit/jdk1.8.0_92 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaShard1LeaderClient

Error Message:
Could not load collection from ZK: test_col

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
test_col
at 
__randomizedtesting.SeedInfo.seed([A81520E8A096FD8:E32811B65A5ED8EB]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1036)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:570)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:211)
at 
org.apache.solr.common.cloud.ClusterState.hasCollection(ClusterState.java:113)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1203)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:925)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.assertQueryDocIds(TestTolerantUpdateProcessorCloud.java:1020)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletes(TestTolerantUpdateProcessorCloud.java:378)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaShard1LeaderClient(TestTolerantUpdateProcessorCloud.java:288)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:50755/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:50755/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([553B61DE0B2FA2F6:DD6F5E04A5D3CF0E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:661)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9068:
-

I can try this out. I will aply the patch and "ant beast" one of the tests. I 
will report here. If this prooves to be the right thing, we should maybe open a 
bug report at Oracle.

If this works I see not problem with the patch, because it is used during tests 
only. Right?

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9054) The new GUI is using hardcoded paths

[Valerio Di Cagno (JIRA)]

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

Valerio Di Cagno updated SOLR-9054:
---
Description: 
(Edited)
If Apache Solr 6.0 is started without using the default context root "/solr"
every admin service will not work properly and is not possible to use the 
provided links to go back to the old GUI.

In the javascript files sometimes the parameter config.solr_path is ignored
or replaced with the value /solr returning 404 on access.

Affected files:  solr-webapp/webapp/js/services.js
Suggested solution: Complete the integration with /js/scripts/app.js

Some common use case which should be considered:
- Different version of Solr coexist in the same host.
- Sometimes users have no direct access to the hosts but must use a proxied 
gateway (to interact with an external authentication system)
- A common practice is to hide internal hosts between an alias when behind a 
load balancer.
  "server.org/app1",  "server.org/app2" and  "server.org/app3" may actually be 
running 3 different machines, but the user should not care about it.



  was:
If Apache Solr 6.0 is started without using the default context root "/solr"
every admin service will not work properly and is not possible to use the 
provided links to go back to the old GUI.

In the javascript files sometimes the parameter config.solr_path is ignored
or replaced with the value /solr returning 404 on access.

Affected files: 
solr-webapp/webapp/js/services.js

Suggested solution:
Complete the integration with /js/scripts/app.js



> The new GUI is using hardcoded paths
> 
>
> Key: SOLR-9054
> URL: https://issues.apache.org/jira/browse/SOLR-9054
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 6.0
>Reporter: Valerio Di Cagno
>
> (Edited)
> If Apache Solr 6.0 is started without using the default context root "/solr"
> every admin service will not work properly and is not possible to use the 
> provided links to go back to the old GUI.
> In the javascript files sometimes the parameter config.solr_path is ignored
> or replaced with the value /solr returning 404 on access.
> Affected files:  solr-webapp/webapp/js/services.js
> Suggested solution: Complete the integration with /js/scripts/app.js
> Some common use case which should be considered:
> - Different version of Solr coexist in the same host.
> - Sometimes users have no direct access to the hosts but must use a proxied 
> gateway (to interact with an external authentication system)
> - A common practice is to hide internal hosts between an alias when behind a 
> load balancer.
>   "server.org/app1",  "server.org/app2" and  "server.org/app3" may actually 
> be running 3 different machines, but the user should not care about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9071) rename the getters in rg.apache.solr.common.util.Pair class

[Noble Paul (JIRA)]

Noble Paul created SOLR-9071:


 Summary: rename the getters in rg.apache.solr.common.util.Pair 
class
 Key: SOLR-9071
 URL: https://issues.apache.org/jira/browse/SOLR-9071
 Project: Solr
  Issue Type: Bug
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Trivial






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+116) - Build # 574 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/574/
Java: 64bit/jdk-9-ea+116 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([8AB64B253D5463ED:2E274FF93A80E15]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9071) rename the getters in org.apache.solr.common.util.Pair class

[Noble Paul (JIRA)]

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

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

I plan to commit this soon

> rename the getters in org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Attachments: SOLR-9071.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[RESULT] Lucene/Solr 5.5.1 RC1 Release vote

[Anshum Gupta]

The release vote for Lucene/Solr 5.5.1 RC1 has passed. I will work on
publishing it tomorrow.

Thanks to everyone who voted and helped with the release process!

-- 
Anshum Gupta

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: For rare cases, don't precompute stuff.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-5.5-Java8 - Build # 26 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java8/26/

4 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([7F5E2DD882F4730:184F932A584F81F5]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:136)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh(ZkStateReaderTest.java:42)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
ObjectTracker found 4 object(s) that were not released!!! [SolrCore, 
MockDirectoryWrapper, 

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: Another minor optimization.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 573 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/573/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([5BDB8779A2DB9146]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:256)
at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([5BDB8779A2DB9146:D38FB8A30C27FCBE]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_92) - Build # 156 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/156/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([FEAE9974EAA1D597:76FAA6AE445DB86F]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 40519 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (14.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 28.6 MB in 0.03 sec (1087.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 63.0 MB in 0.06 sec (1084.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 73.5 MB in 0.07 sec (1027.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6003 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6003 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 218 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (192.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 37.7 MB in 0.03 sec (1089.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 132.1 MB in 0.13 sec (1037.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 140.7 MB in 0.13 sec (1064.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   

Re: lucene-solr:master: added a couple of extra methods

[Noble Paul]

There is nothing more I hate than bikeshedding. So, here we go

I'm gonna remove the getKey(), getValue() from pair and replace them with
fist() and second(). No deprecation or anything.
if anyone has any objection, please raise your hand and go ahead with your
preferred names. I can live with any name because we have enough instances
in Solr where naming is totally screwed up and I have managed to maintain
my sanity all these years.

Cheers

On Thu, May 5, 2016 at 8:15 AM, Scott Blum  wrote:

> Thanks Hoss, I think I just spit coffee all over my keyboard :D
>
> Sometimes you just gotta grow a Pair API.
>
> On Wed, May 4, 2016 at 2:29 PM, Chris Hostetter 
> wrote:
>
>>
>> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
>>
>> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
>>
>> how do those method names sound?
>>
>>
>> : Date: Wed, 4 May 2016 14:26:41 -0400
>> : From: Scott Blum 
>> : Reply-To: dev@lucene.apache.org
>> : To: dev@lucene.apache.org
>> : Subject: Re: lucene-solr:master: added a couple of extra methods
>> :
>> : Or left() and right()
>> :
>> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
>> : ichattopadhy...@gmail.com> wrote:
>> :
>> : > Another option to consider could be: first() and second()
>> : >
>> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>> : >
>> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
>> wrote:
>> : >
>> : >> The names getKey() and getValue() are not always relevant for a pair
>> : >> object. it's not necessarily a key and value. In that case, it makes
>> sense
>> : >> to use the index .
>> : >>
>> : >>
>> : >> This is a convention followed Scala. Tuple2 (
>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>> : >>
>> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
>> hossman_luc...@fucit.org
>> : >> > wrote:
>> : >>
>> : >>>
>> : >>> WTF is this?
>> : >>>
>> : >>> why are these (poorly named) alternatives for getKey and getValue
>> useful?
>> : >>>
>> : >>>
>> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>> : >>> : From: no...@apache.org
>> : >>> : Reply-To: dev@lucene.apache.org
>> : >>> : To: comm...@lucene.apache.org
>> : >>> : Subject: lucene-solr:master: added a couple of extra methods
>> : >>> :
>> : >>> : Repository: lucene-solr
>> : >>> : Updated Branches:
>> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>> : >>> :
>> : >>> :
>> : >>> : added a couple of extra methods
>> : >>> :
>> : >>> :
>> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> : >>> : Commit:
>> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>> : >>> : Tree:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>> : >>> : Diff:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>> : >>> :
>> : >>> : Branch: refs/heads/master
>> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>> : >>> : Parents: 0ebe6b0
>> : >>> : Author: Noble Paul 
>> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
>> : >>> : Committer: Noble Paul 
>> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
>> : >>> :
>> : >>> :
>> --
>> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
>> 
>> : >>> :  1 file changed, 8 insertions(+)
>> : >>> :
>> --
>> : >>> :
>> : >>> :
>> : >>> :
>> : >>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> :
>> --
>> : >>> : diff --git
>> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : index 423f94c..f87323c 100644
>> : >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : @@ -27,6 +27,14 @@ public class Pair implements
>> Serializable {
>> : >>> :
>> : >>> :private V value;
>> : >>> :
>> : >>> : +  public K _1() {
>> : >>> : +return key;
>> : >>> : +  }
>> : >>> : +
>> : >>> : +  public V _2() {
>> : >>> : +return value;
>> : >>> : +  }
>> : >>> : +
>> : >>> :public V getValue() {
>> : >>> :  return value;
>> : >>> :}
>> : >>> :
>> : >>> :
>> : >>>
>> : >>> -Hoss
>> : >>> http://www.lucidworks.com/
>> : >>>
>> : >>>
>> -
>> : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> : >>>
>> : >>>
>> : >>
>> : >>
>> : >> --

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: Another minor optimization.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9006) RealTime Get (RTG) does not return child documents from the transaction log

[Ariel Lieberman (JIRA)]

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

Ariel Lieberman updated SOLR-9006:
--
Attachment: SOLR-9006(6.0).patch

a fix. check if there is transformer in the request.

> RealTime Get (RTG) does not return child documents from the transaction log
> ---
>
> Key: SOLR-9006
> URL: https://issues.apache.org/jira/browse/SOLR-9006
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.5, 6.0
>Reporter: Ariel Lieberman
>  Labels: RTK, RealTimeGet, TransactionLog
> Attachments: SOLR-9006(6.0).patch
>
>
> {{RealTimeGet}} component does not retrieves child documents from the 
> transaction (update) log.   Although there is no mechanism, using {{/get}} to 
> retrieve parent document with all its children.  Note: that {{\_version\_}} 
> field appears only on in the parent document and the update is only as a 
> whole (parent with all children.)  Therefore, I think the capability (e.g. 
> additional flag) to get parent with all its children is very important..  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9006) RealTime Get (RTG) does not return child documents from the transaction log

[Ariel Lieberman (JIRA)]

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

Ariel Lieberman updated SOLR-9006:
--
Attachment: (was: SOLR-9006(6.0).patch)

> RealTime Get (RTG) does not return child documents from the transaction log
> ---
>
> Key: SOLR-9006
> URL: https://issues.apache.org/jira/browse/SOLR-9006
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.5, 6.0
>Reporter: Ariel Lieberman
>  Labels: RTK, RealTimeGet, TransactionLog
> Attachments: SOLR-9006(6.0).patch
>
>
> {{RealTimeGet}} component does not retrieves child documents from the 
> transaction (update) log.   Although there is no mechanism, using {{/get}} to 
> retrieve parent document with all its children.  Note: that {{\_version\_}} 
> field appears only on in the parent document and the update is only as a 
> whole (parent with all children.)  Therefore, I think the capability (e.g. 
> additional flag) to get parent with all its children is very important..  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5818 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5818/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [InternalHttpClient]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([32DA28CACEAF189D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([32DA28CACEAF189D:BA8E171060537565]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: For rare cases, don't precompute stuff.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9006) RealTime Get (RTG) does not return child documents from the transaction log

[Ariel Lieberman (JIRA)]

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

Ariel Lieberman commented on SOLR-9006:
---

the patch, when retrieving from tlog, does not consider the actual information 
in the child transformer. it just brings all the doc children. 

> RealTime Get (RTG) does not return child documents from the transaction log
> ---
>
> Key: SOLR-9006
> URL: https://issues.apache.org/jira/browse/SOLR-9006
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.5, 6.0
>Reporter: Ariel Lieberman
>  Labels: RTK, RealTimeGet, TransactionLog
> Attachments: SOLR-9006(6.0).patch
>
>
> {{RealTimeGet}} component does not retrieves child documents from the 
> transaction (update) log.   Although there is no mechanism, using {{/get}} to 
> retrieve parent document with all its children.  Note: that {{\_version\_}} 
> field appears only on in the parent document and the update is only as a 
> whole (parent with all children.)  Therefore, I think the capability (e.g. 
> additional flag) to get parent with all its children is very important..  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9030: The 'downnode' overseer command can trip asserts in ZkStateWriter
(cherry picked from commit c2662f2)


> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9030:

Summary: The 'downnode' command can trip asserts in ZkStateWriter  (was: 
The 'downnode' command can trip asserts in ZkStateWriter or cause 
BadVersionException in Overseer)

> The 'downnode' command can trip asserts in ZkStateWriter
> 
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8993) New UI can't show DIH

[Shawn McCorkell (JIRA)]

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

Shawn McCorkell commented on SOLR-8993:
---

This is the same issue I was mentioning above. It is related to this bug.

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, 
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1006 - Still Failing

[Apache Jenkins Server]

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

10 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:43320/ro/n

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:43320/ro/n
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:617)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:516)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:180)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Resolved] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-9030.
-
Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

I renamed the issue to remove the part about BadVersionException because that 
is to be expected with the current design but handled already.

Let's create separate issues for ZkStateWriter/Overseer improvements.

Thanks Mark and Scott!

> The 'downnode' command can trip asserts in ZkStateWriter
> 
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-9014.
-
Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

Let's create separate issues for the other improvements discussed here.

Thanks to all who have contributed!

> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7241: More performance improvements.


> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

solr.common.util.Pair --> commons.lang3.tuple.Pair

[Christine Poerschke (BLOOMBERG/ LONDON)]

Steve Davids wrote on another email thread: Though, out of curiosity why not 
just use the Pair class in Apache Commons-Lang? 
http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/Pair.html

I'd be +1 to switching over to org.apache.commons.lang3.tuple.Pair - it seems 
possible now, perhaps the commons class didn't exist when the solr variant was 
first created?

Christine

[jira] [Updated] (SOLR-9072) Move morphline zk tests to SolrCloudTestCase

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-9072:

Attachment: SOLR-9072.patch

Patch.  This one was pretty straightforward.

> Move morphline zk tests to SolrCloudTestCase
> 
>
> Key: SOLR-9072
> URL: https://issues.apache.org/jira/browse/SOLR-9072
> Project: Solr
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Fix For: 6.1, master
>
> Attachments: SOLR-9072.patch
>
>
> Three tests need moving here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9072) Move morphline zk tests to SolrCloudTestCase

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-9072:
---

 Summary: Move morphline zk tests to SolrCloudTestCase
 Key: SOLR-9072
 URL: https://issues.apache.org/jira/browse/SOLR-9072
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
 Fix For: 6.1, master
 Attachments: SOLR-9072.patch

Three tests need moving here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9030: Added a code comment as to why we use Integer.MAX_VALUE instead of -1

(cherry picked from commit 827573b1a7bda2ae853f03c518f313e5992c1a7c)


> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9014: Deprecate ClusterState.getCollections and introduce a new 
ClusterState.getCollectionsMap instead
(cherry picked from commit f5497a3)


> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9014: Fix javadoc
(cherry picked from commit 6ade999)


> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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