[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_141) - Build # 77 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/77/
Java: 32bit/jdk1.8.0_141 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.core.TestJmxIntegration.testJmxRegistration

Error Message:
org.apache.lucene.store.AlreadyClosedException: Already closed

Stack Trace:
javax.management.RuntimeMBeanException: 
org.apache.lucene.store.AlreadyClosedException: Already closed
at 
__randomizedtesting.SeedInfo.seed([9E623FDC5347D63C:10B35BE63E068E59]:0)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:651)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at 
org.apache.solr.core.TestJmxIntegration.testJmxRegistration(TestJmxIntegration.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 17 - Still Failing

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([DBC497A8C3B6A198:791CD972A744889E]:0)
at 
org.apache.lucene.util.packed.Packed8ThreeBlocks.(Packed8ThreeBlocks.java:41)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:963)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:939)
at 
org.apache.lucene.util.packed.GrowableWriter.ensureCapacity(GrowableWriter.java:80)
at 
org.apache.lucene.util.packed.GrowableWriter.set(GrowableWriter.java:88)
at 
org.apache.lucene.util.packed.AbstractPagedMutable.set(AbstractPagedMutable.java:98)
at org.apache.lucene.util.fst.NodeHash.addNew(NodeHash.java:152)
at org.apache.lucene.util.fst.NodeHash.rehash(NodeHash.java:169)
at org.apache.lucene.util.fst.NodeHash.add(NodeHash.java:133)
at org.apache.lucene.util.fst.Builder.compileNode(Builder.java:200)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:296)
at org.apache.lucene.util.fst.Builder.add(Builder.java:400)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.writeFST(MemoryDocValuesConsumer.java:373)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:416)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:406)
at 
org.apache.lucene.codecs.DocValuesConsumer.mergeSortedField(DocValuesConsumer.java:527)
at 
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:139)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:151)
at 
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:181)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:125)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4392)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4032)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2235)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5050)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1720)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1462)
at 
org.apache.lucene.index.TestIndexSorting.testRandom3(TestIndexSorting.java:2301)
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)


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

Error Message:
The Monkey ran for over 45 seconds and no jetties were stopped - this is worth 
investigating!

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([F5AA0A713AE9B538:7DFE35AB9415D8C0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Comment Edited] (SOLR-6086) Replica active during Warming

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar edited comment on SOLR-6086 at 7/26/17 4:07 AM:
--

Here is patch with the fix and tests.

All in all, the following are the ways which cause this issue:
# Replica is the only one in the shard -- hence on startup becomes leader, 
skips recovery, becomes active without waiting for warming to complete
# Replica goes into recovery, discovers that it is the leader, becomes active 
without waiting for warming to complete
# When peersync fails but replication reports that there is nothing to 
replicate then replica becomes active without waiting for warming to complete. 
This can happen in the following ways:
## peersync could be skipped if firstTime=false which can happen if recovering 
on startup we discover that last operation in ulog had flag gap set
## peersync could be skipped if firstTime=false because the previous recovery 
attempt failed and we're retrying recovery
## peersync could fail if the peersync request failed due to exceptions

The fix in this patch (based on Tim's patch) ensure that there is a registered 
searcher before we publish any replica as active. Doing it inside 
RecoveryStrategy was not sufficient because that does not cover scenario 1. The 
tests in this patch inject failure into peer sync and simulate wrong index 
fingerprint computation to reproduce the problem. The scenarios that I could 
not reliably simulate were 2 and 3.1 but the fix should cover both of them. 
Tim's patch had a bug where openSearcher was called without 
returnSearcher=true. This can return a null future sometimes if there is an on 
deck searcher already and no new registration is needed. The correct fix is to 
send returnSearcher=true as well as waitFuture and check for both.


was (Author: shalinmangar):
Here is patch with the fix and tests.

All in all, the following are the ways which cause this issue:
# Replica is the only one in the shard -- hence on startup becomes leader, 
skips recovery, becomes active without waiting for warming to complete
# Replica goes into recovery, discovers that it is the leader, becomes active 
without waiting for warming to complete
# When peersync fails but replication reports that there is nothing to 
replicate then replica becomes active without waiting for warming to complete. 
This can happen in the following ways:
## peersync could be skipped if firstTime=false which can happen if recovering 
on startup we discover that last operation in ulog had flag gap set or if the 
previous recovery attempt failed and we're retrying recovery
## peersync could fail if the peersync request failed due to exceptions

The fix in this patch (based on Tim's patch) ensure that there is a registered 
searcher before we publish any replica as active. Doing it inside 
RecoveryStrategy was not sufficient because that does not cover scenario 1. The 
tests in this patch inject failure into peer sync and simulate wrong index 
fingerprint computation to reproduce the problem. The scenarios that I could 
not reliably simulate were 2 and 3.1 but the fix should cover both of them. 
Tim's patch had a bug where openSearcher was called without 
returnSearcher=true. This can return a null future sometimes if there is an on 
deck searcher already and no new registration is needed. The correct fix is to 
send returnSearcher=true as well as waitFuture and check for both.

> Replica active during Warming
> -
>
> Key: SOLR-6086
> URL: https://issues.apache.org/jira/browse/SOLR-6086
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.6.1, 4.8.1
>Reporter: Ludovic Boutros
>Assignee: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Attachments: SOLR-6086.patch, SOLR-6086.patch, SOLR-6086.patch, 
> SOLR-6086-temp.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> At least with Solr 4.6.1, replica are considered as active during the warming 
> process.
> This means that if you restart a replica or create a new one, queries will  
> be send to this replica and the query will hang until the end of the warming  
> process (If cold searchers are not used).
> You cannot add or restart a node silently anymore.
> I think that the fact that the replica is active is not a bad thing.
> But, the HttpShardHandler and the CloudSolrServer class should take the 
> warming process in account.
> Currently, I have developped a new very simple component which check that a 
> searcher is registered.
> I am also developping custom HttpShardHandler and CloudSolrServer classes 
> which will check the warming process in addition to the ACTIVE status in the 
> cluster state.
> This seems to be more a 

[jira] [Comment Edited] (SOLR-6086) Replica active during Warming

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar edited comment on SOLR-6086 at 7/26/17 4:06 AM:
--

Here is patch with the fix and tests.

All in all, the following are the ways which cause this issue:
# Replica is the only one in the shard -- hence on startup becomes leader, 
skips recovery, becomes active without waiting for warming to complete
# Replica goes into recovery, discovers that it is the leader, becomes active 
without waiting for warming to complete
# When peersync fails but replication reports that there is nothing to 
replicate then replica becomes active without waiting for warming to complete. 
This can happen in the following ways:
## peersync could be skipped if firstTime=false which can happen if recovering 
on startup we discover that last operation in ulog had flag gap set or if the 
previous recovery attempt failed and we're retrying recovery
## peersync could fail if the peersync request failed due to exceptions

The fix in this patch (based on Tim's patch) ensure that there is a registered 
searcher before we publish any replica as active. Doing it inside 
RecoveryStrategy was not sufficient because that does not cover scenario 1. The 
tests in this patch inject failure into peer sync and simulate wrong index 
fingerprint computation to reproduce the problem. The scenarios that I could 
not reliably simulate were 2 and 3.1 but the fix should cover both of them. 
Tim's patch had a bug where openSearcher was called without 
returnSearcher=true. This can return a null future sometimes if there is an on 
deck searcher already and no new registration is needed. The correct fix is to 
send returnSearcher=true as well as waitFuture and check for both.


was (Author: shalinmangar):
Here is patch with the fix and tests.

All in all, the following are the ways which cause this issue:
# Replica is the only one in the shard -- hence on startup becomes leader, 
skips recovery, becomes active without waiting for warming to complete
# Replica goes into recovery, discovers that it is the leader, becomes active 
without waiting for warming to complete
# When peersync fails but replication reports that there is nothing to 
replicate then replica becomes active without waiting for warming to complete. 
This can happen in the following ways:
## peersync could be skipped if firstTime=false which can happen if recovering 
on startup we discover that last operation in ulog had flag gap set or if the 
previous recovery attempt failed and we're retrying recovery
## peersync could fail if the peersync request failed due to exceptions

The fix in this patch (based on Tim's patch) ensure that there is a registered 
searcher before we publish any replica as active. Doing it inside 
RecoveryStrategy was not sufficient because that does not cover scenario 1. The 
tests in this patch inject failure into peer sync and simulate wrong index 
fingerprint computation to reproduce the problem. The one scenario that I could 
not reliably simulate was 2 and 3.1 but the fix should cover both of them. 
Tim's patch had a bug where openSearcher was called without 
returnSearcher=true. This can return a null future sometimes if there is an on 
deck searcher already and no new registration is needed. The correct fix is to 
send returnSearcher=true as well as waitFuture and check for both.

> Replica active during Warming
> -
>
> Key: SOLR-6086
> URL: https://issues.apache.org/jira/browse/SOLR-6086
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.6.1, 4.8.1
>Reporter: Ludovic Boutros
>Assignee: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Attachments: SOLR-6086.patch, SOLR-6086.patch, SOLR-6086.patch, 
> SOLR-6086-temp.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> At least with Solr 4.6.1, replica are considered as active during the warming 
> process.
> This means that if you restart a replica or create a new one, queries will  
> be send to this replica and the query will hang until the end of the warming  
> process (If cold searchers are not used).
> You cannot add or restart a node silently anymore.
> I think that the fact that the replica is active is not a bad thing.
> But, the HttpShardHandler and the CloudSolrServer class should take the 
> warming process in account.
> Currently, I have developped a new very simple component which check that a 
> searcher is registered.
> I am also developping custom HttpShardHandler and CloudSolrServer classes 
> which will check the warming process in addition to the ACTIVE status in the 
> cluster state.
> This seems to be more a workaround than a solution but that's all I can 

[jira] [Updated] (SOLR-6086) Replica active during Warming

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-6086:

Attachment: SOLR-6086.patch

Here is patch with the fix and tests.

All in all, the following are the ways which cause this issue:
# Replica is the only one in the shard -- hence on startup becomes leader, 
skips recovery, becomes active without waiting for warming to complete
# Replica goes into recovery, discovers that it is the leader, becomes active 
without waiting for warming to complete
# When peersync fails but replication reports that there is nothing to 
replicate then replica becomes active without waiting for warming to complete. 
This can happen in the following ways:
## peersync could be skipped if firstTime=false which can happen if recovering 
on startup we discover that last operation in ulog had flag gap set or if the 
previous recovery attempt failed and we're retrying recovery
## peersync could fail if the peersync request failed due to exceptions

The fix in this patch (based on Tim's patch) ensure that there is a registered 
searcher before we publish any replica as active. Doing it inside 
RecoveryStrategy was not sufficient because that does not cover scenario 1. The 
tests in this patch inject failure into peer sync and simulate wrong index 
fingerprint computation to reproduce the problem. The one scenario that I could 
not reliably simulate was 2 and 3.1 but the fix should cover both of them. 
Tim's patch had a bug where openSearcher was called without 
returnSearcher=true. This can return a null future sometimes if there is an on 
deck searcher already and no new registration is needed. The correct fix is to 
send returnSearcher=true as well as waitFuture and check for both.

> Replica active during Warming
> -
>
> Key: SOLR-6086
> URL: https://issues.apache.org/jira/browse/SOLR-6086
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 4.6.1, 4.8.1
>Reporter: Ludovic Boutros
>Assignee: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Attachments: SOLR-6086.patch, SOLR-6086.patch, SOLR-6086.patch, 
> SOLR-6086-temp.patch
>
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> At least with Solr 4.6.1, replica are considered as active during the warming 
> process.
> This means that if you restart a replica or create a new one, queries will  
> be send to this replica and the query will hang until the end of the warming  
> process (If cold searchers are not used).
> You cannot add or restart a node silently anymore.
> I think that the fact that the replica is active is not a bad thing.
> But, the HttpShardHandler and the CloudSolrServer class should take the 
> warming process in account.
> Currently, I have developped a new very simple component which check that a 
> searcher is registered.
> I am also developping custom HttpShardHandler and CloudSolrServer classes 
> which will check the warming process in addition to the ACTIVE status in the 
> cluster state.
> This seems to be more a workaround than a solution but that's all I can do in 
> this version.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.core.TestJmxIntegration.testJmxRegistration

Error Message:
org.apache.lucene.store.AlreadyClosedException: Already closed

Stack Trace:
javax.management.RuntimeMBeanException: 
org.apache.lucene.store.AlreadyClosedException: Already closed
at 
__randomizedtesting.SeedInfo.seed([CED3F3FFADB2C629:400297C5C0F39E4C]:0)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrow(DefaultMBeanServerInterceptor.java:839)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.rethrowMaybeMBeanException(DefaultMBeanServerInterceptor.java:852)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:651)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
at 
org.apache.solr.core.TestJmxIntegration.testJmxRegistration(TestJmxIntegration.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-10814 at 7/26/17 4:01 AM:


bq.A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.

This looks OK. But where does a user set this 
{{solr.authorization.useShortName}}? in a system property? No . We must avoid 
system properties as much as possible. It could be a global property at the 
same level as {{authentication}} & {{authorization}}

{code:title=security.json}
{
"useShortUserName": true,
"authentication":{},
"authorization":{}
}
{code}

We will need to add a command to toggle this flag 


was (Author: noble.paul):
bq.A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.

This looks OK. But where does a user set this 
{{solr.authorization.useShortName}}? in a system property? No . We must avoid 
system properties as much as possible. It could be a global property at the 
same level {{authentication}} & {{authorization}}

> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based permission definitions which are assigned to 
> users.
> The authorization framework in Solr passes the information about the request 
> (to be authorized) using an instance of AuthorizationContext class. Currently 
> the only way to extract authenticated user is via getUserPrincipal() method 
> which returns an instance of java.security.Principal class. The 
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the 
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName. 
> Hence it works fine. But in case of kerberos authentication, the user 
> principal also contains the RELM information e.g. instead of foo, it would 
> return f...@example.com. This means if the user changes the authentication 
> mechanism, he would also need to change the user-role mapping in 
> authorization section to use f...@example.com instead of foo. This is not 
> good from usability perspective.   



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

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

[jira] [Commented] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-10814:
---

bq.A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.

This looks OK. But where does a user set this 
{{solr.authorization.useShortName}}? in a system property? No . We must avoid 
system properties as much as possible. It could be a global property at the 
same level {{authentication}} & {{authorization}}

> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based permission definitions which are assigned to 
> users.
> The authorization framework in Solr passes the information about the request 
> (to be authorized) using an instance of AuthorizationContext class. Currently 
> the only way to extract authenticated user is via getUserPrincipal() method 
> which returns an instance of java.security.Principal class. The 
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the 
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName. 
> Hence it works fine. But in case of kerberos authentication, the user 
> principal also contains the RELM information e.g. instead of foo, it would 
> return f...@example.com. This means if the user changes the authentication 
> mechanism, he would also need to change the user-role mapping in 
> authorization section to use f...@example.com instead of foo. This is not 
> good from usability perspective.   



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

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

[jira] [Resolved] (SOLR-9606) Remove GeoHashField from Solr

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-9606.

Resolution: Duplicate

It's debatable but I'll close as a duplicate.  When we're ready to remove 
deprecated stuff from 8.0, we'll file an issue larger in scope than this one 
field.

> Remove GeoHashField from Solr
> -
>
> Key: SOLR-9606
> URL: https://issues.apache.org/jira/browse/SOLR-9606
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.0
>
>
> I'd like to remove GeoHashField from Solr -- 7.0.  I see no use-case for it 
> any more.  And it's presence is distracting from spatial fields you *should* 
> be using.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6783/
Java: 32bit/jdk1.8.0_141 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.schema.TestUseDocValuesAsStored2

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores\core

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores

C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores\core
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003\cores
   
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestUseDocValuesAsStored2_4E985D18EE97EE47-001\tempDir-003

at __randomizedtesting.SeedInfo.seed([4E985D18EE97EE47]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 11 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:817)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1084)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1115)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1212)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:560)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
Caused by: 

[jira] [Commented] (SOLR-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-11070:
-

Seems fine, +1

> DocValues range query behaves different than Trie/Point range queries for 
> Float/Double "Infinity"
> -
>
> Key: SOLR-11070
> URL: https://issues.apache.org/jira/browse/SOLR-11070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: 7.0
>
> Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, 
> SOLR-11070.patch, SOLR-11070.patch
>
>




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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.TestPullReplica.testKillLeader

Error Message:
Replica state not updated in cluster state null Live Nodes: 
[127.0.0.1:41809_solr, 127.0.0.1:36496_solr] Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
   "pullReplicas":"1",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   
"core":"pull_replica_test_kill_leader_shard1_replica_n1",   
"base_url":"http://127.0.0.1:36496/solr;,   
"node_name":"127.0.0.1:36496_solr",   "state":"down",   
"type":"NRT",   "leader":"true"}, "core_node4":{   
"core":"pull_replica_test_kill_leader_shard1_replica_p2",   
"base_url":"http://127.0.0.1:41809/solr;,   
"node_name":"127.0.0.1:41809_solr",   "state":"active",   
"type":"PULL",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"100",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Replica state not updated in cluster state
null
Live Nodes: [127.0.0.1:41809_solr, 127.0.0.1:36496_solr]
Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
  "pullReplicas":"1",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"pull_replica_test_kill_leader_shard1_replica_n1",
  "base_url":"http://127.0.0.1:36496/solr;,
  "node_name":"127.0.0.1:36496_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true"},
"core_node4":{
  "core":"pull_replica_test_kill_leader_shard1_replica_p2",
  "base_url":"http://127.0.0.1:41809/solr;,
  "node_name":"127.0.0.1:41809_solr",
  "state":"active",
  "type":"PULL",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"100",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([47ADDA8921218EB3:EBB2E3D439A1AE5]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:401)
at 
org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 

[jira] [Updated] (SOLR-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11070:
-
Fix Version/s: 7.0

I'll commit this patch and backport the fix to 7.0 tomorrow

> DocValues range query behaves different than Trie/Point range queries for 
> Float/Double "Infinity"
> -
>
> Key: SOLR-11070
> URL: https://issues.apache.org/jira/browse/SOLR-11070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: 7.0
>
> Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, 
> SOLR-11070.patch, SOLR-11070.patch
>
>




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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+178) - Build # 143 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/143/
Java: 64bit/jdk-9-ea+178 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([A8214D7A908E5FD8:23069EABD188F45C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:183)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:907)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:436)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
   

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 76 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/76/

2 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([41E05768EED17DC:FD5396D9B2985A56]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:279)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9321) Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and getActiveSlices()

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9321:
--

[~ichattopadhyaya], do you have time to finish up and commit this 7.0 blocker?

> Removed usage of deprecated clusterstate.getSlicesMap(), getSlices() and 
> getActiveSlices()
> --
>
> Key: SOLR-9321
> URL: https://issues.apache.org/jira/browse/SOLR-9321
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-9321.patch, SOLR-9321.patch, SOLR-9321.patch
>
>




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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([AA612EA7ED865D72]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.analytics.AbstractAnalyticsStatsCloudTest.setupCluster(AbstractAnalyticsStatsCloudTest.java:76)
at 
org.apache.solr.analytics.NoFacetCloudTest.populate(NoFacetCloudTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 15868 lines...]
   [junit4] Suite: org.apache.solr.analytics.NoFacetCloudTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/contrib/solr-analytics/test/J0/temp/solr.analytics.NoFacetCloudTest_AA612EA7ED865D72-001/init-core-data-001
   [junit4]   2> Jul 25, 2017 11:02:00 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 1 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=false): {}, locale=ja-JP, 
timezone=America/Halifax
   [junit4]   2> NOTE: Linux 4.10.0-27-generic i386/Oracle Corporation 
1.8.0_141 (32-bit)/cpus=8,threads=1,free=18062296,total=40693760
   [junit4]   2> NOTE: All tests run in this JVM: 
[AbstractAnalyticsStatsCloudTest, FieldFacetTest, 
AbstractAnalyticsFacetCloudTest, NoFacetCloudTest]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=NoFacetCloudTest 
-Dtests.seed=AA612EA7ED865D72 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ja-JP -Dtests.timezone=America/Halifax -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.00s J0 | NoFacetCloudTest (suite) <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Could not find 
collection:collection1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([AA612EA7ED865D72]:0)
   [junit4]>at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
   [junit4]>at 

Re: 7.0 Release Update

[Steve Rowe]

I worked through the list of issues with the "numeric-tries-to-points” label 
and marked those as 7.0 Blocker that seemed reasonable, on the assumption that 
we should at a minimum give clear error messages for points non-compatibility.

If others don’t agree with the Blocker assessments I’ve made, I’m willing to 
discuss on the issues.

I plan on starting to work on the remaining 7.0 blockers now.  I would welcome 
assistance in clearing them up.

Here’s a JIRA query to see just the remaining 7.0 blockers, of which there are 
currently 12:



--
Steve
www.lucidworks.com

> On Jul 25, 2017, at 2:41 PM, Anshum Gupta  wrote:
> 
> I will *try* to get to it, but can't confirm. If someone else has a spare 
> cycle and can take it up before I get to it, please do.
> 
> -Anshum
> 
> On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett  
> wrote:
> I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
> fields as deprecated) is SOLR-11023, which Hoss was working on. As he
> noted last night, he is off for vacation for the next 2 weeks. Is
> anyone else available to work on it so 7.0 isn't stalled for 2+ more
> weeks?
> 
> Now would also be a good time to look over any other bugs with
> PointFields and make a case if any should be considered blockers for
> 7.0. I think they all share a label:
> https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points
> 
> On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
>  wrote:
> >
> > : So, my overall point is that if A) we agree that we want to deprecate
> > : Trie* numeric fields, and B) we want to hold up the 7.0 release until
> > : that's done, it's more than just updating the example schemas if we
> > : want to ensure a quality app for users. We still need to fix the tests
> > : and also fix bugs that are going to be really painful for users. And
> > : to get all that done soon, we definitely need some more volunteers.
> >
> > I've beefed up the description of SOLR-10807 with tips on how people can
> > help out...
> >
> > https://issues.apache.org/jira/browse/SOLR-10807
> >
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > -
> > 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
> 


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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/76/
Java: 64bit/jdk1.8.0_141 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream

Error Message:
Error from server at http://127.0.0.1:49967/solr/mainCorpus_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /solr/mainCorpus_shard2_replica_n3/update. Reason: Can not 
find: /solr/mainCorpus_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:49967/solr/mainCorpus_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/mainCorpus_shard2_replica_n3/update. Reason:
Can not find: /solr/mainCorpus_shard2_replica_n3/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([D83EEED242A0E06C:65299BCB7B8CDD31]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream(StreamExpressionTest.java:6844)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

[~ivera], arcDistance is defined well for ellipsoids but surfaceDistance 
requires an iterative convergent loop.  Also, the GeoCircle is in fact a single 
plane which slices through the ellipsoid forming an ellipse.  Since 
surfaceDistance is prohibitively expensive to calculate for all but a sphere, 
an approximation is required either way, and the GeoCircle is fitted specially 
to the ellipsoid in order to be a good approximation for WGS84.


> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



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

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

[jira] [Comment Edited] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre edited comment on SOLR-10814 at 7/25/17 9:42 PM:
--

[~noble.paul]

bq. If there is a Ranger Authorization plugin, you want them to implement this 
flag as well?

AFAIK Ranger plugin does not need this flag (or this fix in general) since they 
have already implemented logic to parse Kerberos principal -> short userName. 
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560

The concern here is that it "assumes" kerberos authentication. I don't know if 
this works for any authentication type other than Kerberos (e.g. basic auth).

bq.  The framework is supposed to take care of these things.

I agree. In the hindsight, it was a mistake for Solr authorization framework to 
provide java.security.Principal as part of AuthorizationContext (instead of 
short userName) since the Principal representation depends upon the type of the 
authentication scheme. 

bq. All authentication plugins should extend the AuthenticationPlugin class. 
So, it should decide what details it should return. This has nothing to do with 
what underlying authentication is used. 

How would we do that? By overriding getUserPrincipal() method in the 
HttpServletRequest class ? I would be concerned with that. Since  
getUserPrincipal() is a public method and can be used by downstream components 
(e.g. custom request handlers, plugins etc.), this would be a backwards 
incompatible change.

A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.
https://github.com/apache/lucene-solr/blob/10875143b2eb4c6cd72c7a93e65783398b66/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L1034

{code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
  @Override
  public Principal getUserPrincipal() {
if (Boolean.getBoolean("solr.authorization.useShortName") {
  return new BasicUserPrincipal(getReq().getRemoteUser());
}
return getReq().getUserPrincipal();
  }
{code}








was (Author: hgadre):
[~noble.paul]

bq. If there is a Ranger Authorization plugin, you want them to implement this 
flag as well?

AFAIK Ranger plugin does not need this flag (or this fix in general) since they 
have already implemented logic to parse Kerberos principal -> short userName. 
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560

The concern here is that it "assumes" kerberos authentication. I don't know if 
this works for any authentication type other than Kerberos (e.g. basic auth).

bq.  The framework is supposed to take care of these things.

I agree. In the hindsight, it was a mistake for Solr authorization framework to 
provide java.security.Principal as part of AuthorizationContext (instead of 
short userName) since the Principal representation depends upon the type of the 
authentication scheme. 

bq. All authentication plugins should extend the AuthenticationPlugin class. 
So, it should decide what details it should return. This has nothing to do with 
what underlying authentication is used. 

How would we do that? By overriding getUserPrincipal() method in the 
HttpServletRequest class ? I would be concerned with that. Since this is a 
public method and can be used by downstream components (e.g. custom request 
handlers, plugins etc.), this would be a backwards incompatible change.

A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.
https://github.com/apache/lucene-solr/blob/10875143b2eb4c6cd72c7a93e65783398b66/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L1034

{code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
  @Override
  public Principal getUserPrincipal() {
if (Boolean.getBoolean("solr.authorization.useShortName") {
  return new BasicUserPrincipal(getReq().getRemoteUser());
}
return getReq().getUserPrincipal();
  }
{code}







> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based 

[jira] [Commented] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-10814:
-

[~noble.paul]

bq. If there is a Ranger Authorization plugin, you want them to implement this 
flag as well?

AFAIK Ranger plugin does not need this flag (or this fix in general) since they 
have already implemented logic to parse Kerberos principal -> short userName. 
https://github.com/apache/ranger/blame/16f3dd3c350ac9ea85b157b81ceddfcdb761e128/agents-audit/src/main/java/org/apache/ranger/audit/provider/MiscUtil.java#L560

The concern here is that it "assumes" kerberos authentication. I don't know if 
this works for any authentication type other than Kerberos (e.g. basic auth).

bq.  The framework is supposed to take care of these things.

I agree. In the hindsight, it was a mistake for Solr authorization framework to 
provide java.security.Principal as part of AuthorizationContext (instead of 
short userName) since the Principal representation depends upon the type of the 
authentication scheme. 

bq. All authentication plugins should extend the AuthenticationPlugin class. 
So, it should decide what details it should return. This has nothing to do with 
what underlying authentication is used. 

How would we do that? By overriding getUserPrincipal() method in the 
HttpServletRequest class ? I would be concerned with that. Since this is a 
public method and can be used by downstream components (e.g. custom request 
handlers, plugins etc.), this would be a backwards incompatible change.

A safer alternative may be to let authorization framework handle this global 
flag and return short username (or user principal) accordingly.
https://github.com/apache/lucene-solr/blob/10875143b2eb4c6cd72c7a93e65783398b66/solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java#L1034

{code:theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
  @Override
  public Principal getUserPrincipal() {
if (Boolean.getBoolean("solr.authorization.useShortName") {
  return new BasicUserPrincipal(getReq().getRemoteUser());
}
return getReq().getUserPrincipal();
  }
{code}







> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based permission definitions which are assigned to 
> users.
> The authorization framework in Solr passes the information about the request 
> (to be authorized) using an instance of AuthorizationContext class. Currently 
> the only way to extract authenticated user is via getUserPrincipal() method 
> which returns an instance of java.security.Principal class. The 
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the 
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName. 
> Hence it works fine. But in case of kerberos authentication, the user 
> principal also contains the RELM information e.g. instead of foo, it would 
> return f...@example.com. This means if the user changes the authentication 
> mechanism, he would also need to change the user-role mapping in 
> authorization section to use f...@example.com instead of foo. This is not 
> good from usability perspective.   



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

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

[jira] [Commented] (SOLR-10831) Document Replica Types

[JIRA]

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

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

Yes, that was my plan. I was thinking the explanation and use could be taken 
from the description of SOLR-10233 (updated to the final naming)

> Document Replica Types
> --
>
> Key: SOLR-10831
> URL: https://issues.apache.org/jira/browse/SOLR-10831
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: 7.0
>
>




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

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

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitStaticIndexReplication

Error Message:
Shard shard1_0 replicas do not have same number of documents expected:<32> but 
was:<0>

Stack Trace:
java.lang.AssertionError: Shard shard1_0 replicas do not have same number of 
documents expected:<32> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([3AD09E3EBF453B74:709A0A3E2EED1471]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.ShardSplitTest.assertConsistentReplicas(ShardSplitTest.java:243)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitStaticIndexReplication(ShardSplitTest.java:217)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS-EA] Lucene-Solr-7.0-Linux (64bit/jdk-9-ea+178) - Build # 86 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/86/
Java: 64bit/jdk-9-ea+178 -XX:+UseCompressedOops -XX:+UseG1GC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([E010701EA46B08D6:5AC21F662745E6C3]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:885)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
... 39 more




Build Log:
[...truncated 12142 lines...]
   [junit4] Suite: 

[jira] [Created] (SOLR-11146) Analytics Component 2.0 Bug Fixes

[Houston Putman (JIRA)]

Houston Putman created SOLR-11146:
-

 Summary: Analytics Component 2.0 Bug Fixes
 Key: SOLR-11146
 URL: https://issues.apache.org/jira/browse/SOLR-11146
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Houston Putman
Priority: Critical
 Fix For: 7.0


The new Analytics Component has several small bugs in mapping functions and 
other places. This ticket is a fix for a large number of them. This patch 
should allow all unit tests created in SOLR-11145 to pass.



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

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

[jira] [Created] (SOLR-11145) Comprehensive Unit Tests for the Analytics Component

[Houston Putman (JIRA)]

Houston Putman created SOLR-11145:
-

 Summary: Comprehensive Unit Tests for the Analytics Component
 Key: SOLR-11145
 URL: https://issues.apache.org/jira/browse/SOLR-11145
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.1
Reporter: Houston Putman
Priority: Critical
 Fix For: 7.0


Adding comprehensive unit tests for the new Analytics Component.



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

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

[jira] [Created] (SOLR-11144) Analytics Component Documentation

[Houston Putman (JIRA)]

Houston Putman created SOLR-11144:
-

 Summary: Analytics Component Documentation
 Key: SOLR-11144
 URL: https://issues.apache.org/jira/browse/SOLR-11144
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.0, 7.1
Reporter: Houston Putman
Priority: Critical


Adding a Solr Reference Guide page for the Analytics Component.



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

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

[jira] [Commented] (SOLR-10033) facet.mincount=0 not working with using PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10033:
---

I'm marking this as a 7.0 Blocker, for error message cleanup; at a minimum, the 
user should get a clear error when attempting this operation.

> facet.mincount=0 not working with using PointFields
> ---
>
> Key: SOLR-10033
> URL: https://issues.apache.org/jira/browse/SOLR-10033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>




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

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

[jira] [Updated] (SOLR-10033) facet.mincount=0 not working with using PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10033:
--
Fix Version/s: 7.0

> facet.mincount=0 not working with using PointFields
> ---
>
> Key: SOLR-10033
> URL: https://issues.apache.org/jira/browse/SOLR-10033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>




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

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

[jira] [Updated] (SOLR-10033) facet.mincount=0 not working with using PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10033:
--
Priority: Blocker  (was: Major)

> facet.mincount=0 not working with using PointFields
> ---
>
> Key: SOLR-10033
> URL: https://issues.apache.org/jira/browse/SOLR-10033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>




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

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

[jira] [Commented] (SOLR-10845) GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only fields?)

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10845:
---

Marked as a 7.0 Blocker, for error message cleanup; as Hoss wrote in the 
description:

bq. GraphTermsQParserPlugin should either be enhanced to work correctly with 
Points based fields, or should give a clear error if the isPointsField() 
returns true for the field type being used. At present, it silently matches no 
documents.

> GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only 
> fields?)
> --
>
> Key: SOLR-10845
> URL: https://issues.apache.org/jira/browse/SOLR-10845
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> GraphTermsQParserPlugin (aka {{graphTerms}}) doesn't work if the {{f}} field 
> being used to build the graph is "Points" based (because the field won't have 
> any {{Terms}})
> GraphTermsQParserPlugin should either be enhanced to work correctly with 
> Points based fields, or should give a clear error if the {{isPointsField()}} 
> returns true for the field type being used.  At present, it silently matches 
> no documents.
> (Note: It appears at first glance that the same basic problem probably exists 
> for any trie/string field which is {{docValues="true" indexed="false}} ?)



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

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

[jira] [Updated] (SOLR-10845) GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only fields?)

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10845:
--
Fix Version/s: 7.0

> GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only 
> fields?)
> --
>
> Key: SOLR-10845
> URL: https://issues.apache.org/jira/browse/SOLR-10845
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> GraphTermsQParserPlugin (aka {{graphTerms}}) doesn't work if the {{f}} field 
> being used to build the graph is "Points" based (because the field won't have 
> any {{Terms}})
> GraphTermsQParserPlugin should either be enhanced to work correctly with 
> Points based fields, or should give a clear error if the {{isPointsField()}} 
> returns true for the field type being used.  At present, it silently matches 
> no documents.
> (Note: It appears at first glance that the same basic problem probably exists 
> for any trie/string field which is {{docValues="true" indexed="false}} ?)



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

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

[jira] [Updated] (SOLR-10845) GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only fields?)

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10845:
--
Priority: Blocker  (was: Major)

> GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only 
> fields?)
> --
>
> Key: SOLR-10845
> URL: https://issues.apache.org/jira/browse/SOLR-10845
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> GraphTermsQParserPlugin (aka {{graphTerms}}) doesn't work if the {{f}} field 
> being used to build the graph is "Points" based (because the field won't have 
> any {{Terms}})
> GraphTermsQParserPlugin should either be enhanced to work correctly with 
> Points based fields, or should give a clear error if the {{isPointsField()}} 
> returns true for the field type being used.  At present, it silently matches 
> no documents.
> (Note: It appears at first glance that the same basic problem probably exists 
> for any trie/string field which is {{docValues="true" indexed="false}} ?)



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

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

[jira] [Commented] (SOLR-10846) ExternalFileField/FileFloatSource throws NPE if keyField is Points based

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10846:
---

Marking this as a 7.0 Blocker, for error message cleanup; as Hoss wrote:

bq. If there is no straight forward way to make FileFloatSource work with Point 
fields, then ExternalFileField should throw a clear error on init if the 
true==keyFieldType.isPointField()

> ExternalFileField/FileFloatSource throws NPE if keyField is Points based
> 
>
> Key: SOLR-10846
> URL: https://issues.apache.org/jira/browse/SOLR-10846
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> FileFloatSource (and by extension ExternalFileField) currently throws an NPE 
> if the {{keyField}} is Points based.
> This seems to be due to hardcoded assumptions about 
> {{MultiFields.getTerms(...)}} returning a non-null value for the keyField 
> (which I suspect could also lead to an NPE in situations where the index is 
> completley empty? ... not sure)
> In general, the error handling in FileFloatSource should be improved. 
>  
> If there is no straight forward way to make FileFloatSource work with Point 
> fields, then ExternalFileField should throw a clear error on init if the 
> {{true==keyFieldType.isPointField()}}



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

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

[jira] [Updated] (SOLR-10786) Add DBSCAN clustering Streaming Evaluator

[Joel Bernstein (JIRA)]

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

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

Added a test case for the nodeVectors. Will add a test case for the dbscan 
clustering shortly.

> Add DBSCAN clustering Streaming Evaluator
> -
>
> Key: SOLR-10786
> URL: https://issues.apache.org/jira/browse/SOLR-10786
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10786.patch, SOLR-10786.patch
>
>
> The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
> DBSCAN clustering algorithm.
> Clustering implementation will be provided by Apache Commons Math.



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

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

[jira] [Commented] (SOLR-10936) ArrayIndexOutOfBoundsException: -65536 when indexing large document

[Matthew Caruana Galizia (JIRA)]

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

Matthew Caruana Galizia commented on SOLR-10936:


Made some schema changes and now I get the following logged, instead of the 
previous message:

{{An exception was thrown while processing field text_sensitive}}

The definition of {{text_sensitive}} in the managed schema:

{{}}

The definition of the type, also in the managed schema:

  

  
  
  
  


  
  
  

  

> ArrayIndexOutOfBoundsException: -65536 when indexing large document
> ---
>
> Key: SOLR-10936
> URL: https://issues.apache.org/jira/browse/SOLR-10936
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Ubuntu 16
> Output of {{java -version}}:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
>
> I'm currently trying to index a large document with thousands of child 
> documents. I see the following in solr.log. After that, the IndexWriter is 
> closed and all subsequent updates fail.
> {code:java}
> 2017-06-21 19:33:37.284 ERROR (qtp959447386-21) [   x:kc] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Exception 
> writing document id 
> 033c9919dfeb06dd6ae7166aad554652b8eadd6c6c602c6dd837d3324f715f99 to the 
> index; possible analysis error.
>   at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:336)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:122)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:271)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
>   at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:173)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:187)
>   at 

[jira] [Updated] (SOLR-10846) ExternalFileField/FileFloatSource throws NPE if keyField is Points based

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10846:
--
Fix Version/s: 7.0

> ExternalFileField/FileFloatSource throws NPE if keyField is Points based
> 
>
> Key: SOLR-10846
> URL: https://issues.apache.org/jira/browse/SOLR-10846
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> FileFloatSource (and by extension ExternalFileField) currently throws an NPE 
> if the {{keyField}} is Points based.
> This seems to be due to hardcoded assumptions about 
> {{MultiFields.getTerms(...)}} returning a non-null value for the keyField 
> (which I suspect could also lead to an NPE in situations where the index is 
> completley empty? ... not sure)
> In general, the error handling in FileFloatSource should be improved. 
>  
> If there is no straight forward way to make FileFloatSource work with Point 
> fields, then ExternalFileField should throw a clear error on init if the 
> {{true==keyFieldType.isPointField()}}



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

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

[jira] [Updated] (SOLR-10846) ExternalFileField/FileFloatSource throws NPE if keyField is Points based

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10846:
--
Priority: Blocker  (was: Major)

> ExternalFileField/FileFloatSource throws NPE if keyField is Points based
> 
>
> Key: SOLR-10846
> URL: https://issues.apache.org/jira/browse/SOLR-10846
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> FileFloatSource (and by extension ExternalFileField) currently throws an NPE 
> if the {{keyField}} is Points based.
> This seems to be due to hardcoded assumptions about 
> {{MultiFields.getTerms(...)}} returning a non-null value for the keyField 
> (which I suspect could also lead to an NPE in situations where the index is 
> completley empty? ... not sure)
> In general, the error handling in FileFloatSource should be improved. 
>  
> If there is no straight forward way to make FileFloatSource work with Point 
> fields, then ExternalFileField should throw a clear error on init if the 
> {{true==keyFieldType.isPointField()}}



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

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

[jira] [Commented] (SOLR-10847) TermsComponent doesn't work with Points fields - confusing errors when using terms.list

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10847:
---

I set this as 7.0 Blocker: I think error message cleanup should block the 
release.

> TermsComponent doesn't work with Points fields - confusing errors when using 
> terms.list
> ---
>
> Key: SOLR-10847
> URL: https://issues.apache.org/jira/browse/SOLR-10847
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> TermsComponent doesn't work if the field in question is "Points" based 
> (because the field won't have any Terms)
> Given the nature of TermsComponent, maybe this is fine? but it should 
> probably throw an error in this case instead of silently returning nothing by 
> default (current behavior) and throwing an UnSupOpEx if "terms.list" is 
> specified.



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

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

[jira] [Updated] (SOLR-10847) TermsComponent doesn't work with Points fields - confusing errors when using terms.list

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10847:
--
Fix Version/s: 7.0

> TermsComponent doesn't work with Points fields - confusing errors when using 
> terms.list
> ---
>
> Key: SOLR-10847
> URL: https://issues.apache.org/jira/browse/SOLR-10847
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> TermsComponent doesn't work if the field in question is "Points" based 
> (because the field won't have any Terms)
> Given the nature of TermsComponent, maybe this is fine? but it should 
> probably throw an error in this case instead of silently returning nothing by 
> default (current behavior) and throwing an UnSupOpEx if "terms.list" is 
> specified.



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

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

[jira] [Updated] (SOLR-10847) TermsComponent doesn't work with Points fields - confusing errors when using terms.list

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10847:
--
Priority: Blocker  (was: Major)

> TermsComponent doesn't work with Points fields - confusing errors when using 
> terms.list
> ---
>
> Key: SOLR-10847
> URL: https://issues.apache.org/jira/browse/SOLR-10847
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> TermsComponent doesn't work if the field in question is "Points" based 
> (because the field won't have any Terms)
> Given the nature of TermsComponent, maybe this is fine? but it should 
> probably throw an error in this case instead of silently returning nothing by 
> default (current behavior) and throwing an UnSupOpEx if "terms.list" is 
> specified.



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

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11023:
--
Fix Version/s: 7.0

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



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

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

[jira] [Updated] (SOLR-10919) ord & rord functions give confusing errors with PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10919:
--
Fix Version/s: 7.0

> ord & rord functions give confusing errors with PointFields
> ---
>
> Key: SOLR-10919
> URL: https://issues.apache.org/jira/browse/SOLR-10919
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> as discovered in SOLR-10807...
> If you try to use either the {{ord()}} or {{rord()}} functions on a Numeric 
> PointsField, the error is confusing.  
> We should make them give clean errors if someone attempts this.



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

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

[jira] [Commented] (SOLR-10919) ord & rord functions give confusing errors with PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10919:
---

I'd like to get this error message cleanup into 7.0, so I set it as a Blocker 
for the release.

> ord & rord functions give confusing errors with PointFields
> ---
>
> Key: SOLR-10919
> URL: https://issues.apache.org/jira/browse/SOLR-10919
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> as discovered in SOLR-10807...
> If you try to use either the {{ord()}} or {{rord()}} functions on a Numeric 
> PointsField, the error is confusing.  
> We should make them give clean errors if someone attempts this.



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

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

[jira] [Updated] (SOLR-10919) ord & rord functions give confusing errors with PointFields

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10919:
--
Priority: Blocker  (was: Major)

> ord & rord functions give confusing errors with PointFields
> ---
>
> Key: SOLR-10919
> URL: https://issues.apache.org/jira/browse/SOLR-10919
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
>
> as discovered in SOLR-10807...
> If you try to use either the {{ord()}} or {{rord()}} functions on a Numeric 
> PointsField, the error is confusing.  
> We should make them give clean errors if someone attempts this.



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

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

[jira] [Commented] (SOLR-10926) increase the odds of randomly choosing point fields in our SolrTestCaseJ4 numeric type randomization

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10926:
---

I marked this issue as a blocker for 7.0.  Points testing IMO should be 
increased with 7.0+.

> increase the odds of randomly choosing point fields in our SolrTestCaseJ4 
> numeric type randomization
> 
>
> Key: SOLR-10926
> URL: https://issues.apache.org/jira/browse/SOLR-10926
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> currently it's a 50/50 chance of using point fields vs trie fields ... once 
> we are more confident in the utility/reliability of point fields and/or they 
> are the "default" in our example configsets, we should tweak those odds so 
> Point fields get tested much more often then TrieFields



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

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

[jira] [Updated] (SOLR-10926) increase the odds of randomly choosing point fields in our SolrTestCaseJ4 numeric type randomization

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10926:
--
Priority: Blocker  (was: Major)

> increase the odds of randomly choosing point fields in our SolrTestCaseJ4 
> numeric type randomization
> 
>
> Key: SOLR-10926
> URL: https://issues.apache.org/jira/browse/SOLR-10926
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
>
> currently it's a 50/50 chance of using point fields vs trie fields ... once 
> we are more confident in the utility/reliability of point fields and/or they 
> are the "default" in our example configsets, we should tweak those odds so 
> Point fields get tested much more often then TrieFields



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

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

[jira] [Resolved] (SOLR-10949) analytics component has hard coded assumptions about Trie numeric fields -- tests fail with randomized point fields

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10949.
---
Resolution: Fixed

As noted in comments above, this issue can be resolved.

> analytics component has hard coded assumptions about Trie numeric fields -- 
> tests fail with randomized point fields
> ---
>
> Key: SOLR-10949
> URL: https://issues.apache.org/jira/browse/SOLR-10949
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
>
> Found as part of SOLR-10947... attempting to use numeric PointFields in 
> contrib/analytics tests cause problems in some tests due to classes like 
> StatsCollectorSupplierFactory, RangeEndpointCalculator, and AnalyticsParsers 
> having hard coded assumptions about using Trie based numeric fields (via 
> instanceof and clas equality checks)
> (It's not immediately obvious if replacing these checks with inspection of 
> {{FieldType.getNumberType()}} would solve all the problems, or if other 
> assumptions are made down stream in the code)



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

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

[jira] [Commented] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11023:
---

I marked this issue explicitly as a Blocker for 7.0. 

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



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

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11023:
--
Priority: Blocker  (was: Major)

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch, SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



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

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

[jira] [Assigned] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-10924:
-

Assignee: Steve Rowe

> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>  Labels: numeric-tries-to-points
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



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

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

[jira] [Commented] (SOLR-10924) PointField multivalued docValues don't "dedup" like TrieField

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10924:
---

If there are no objections, tomorrow I'll resolve this as Won't Fix, because as 
Hoss wrote in his comment on this issue:

{quote}
I've filed this "bug" so we have a record of the discrepency, but personally I 
don't think there is anything we should really do to "fix" it. If users are 
sending duplicate values to a field and want to dedup just like Trie fields 
did, they can use UniqFieldsUpdateProcessorFactory on all numeric fields.
{quote}

> PointField multivalued docValues don't "dedup" like TrieField
> -
>
> Key: SOLR-10924
> URL: https://issues.apache.org/jira/browse/SOLR-10924
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
>
> As noted by Tomas in SOLR-10835, since the numeric FooPointField classes use 
> SortedNumericDocValues, the docvalues don't "dedup" when the same value 
> exists multiple times for a single document -- this is different from the 
> numeric TrieFooField classes that use SortedSetDocValues - which are by 
> definition a _set_ -- so multiple instances of the same value are 
> de-duplicated.
> This impacts things like the ExportWriter, as well as fields that 
> {{useDocValuesAsStored="true"}} if users have particular expecations when 
> converting from Trie fields to Point fields.



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

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

[jira] [Commented] (SOLR-10936) ArrayIndexOutOfBoundsException: -65536 when indexing large document

[Matthew Caruana Galizia (JIRA)]

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

Matthew Caruana Galizia commented on SOLR-10936:


Weirdly, it seems that the problem is coming from the field that stores 
spelling tokens. I turned on infoStream logging and saw this message just 
before the stack trace was printed:

{{An exception was thrown while processing field spell_text}}

In the managed schema, the relevant parts that define this field are:

...
  

  
  
  
  
  

  
...

...

...

The field {{tika_content}} contains the text extracted from the document using 
Tika.

The spellchecker component has the following definition:

...

text_spell

text
spell_text
./spell_text
0.7
true


...

> ArrayIndexOutOfBoundsException: -65536 when indexing large document
> ---
>
> Key: SOLR-10936
> URL: https://issues.apache.org/jira/browse/SOLR-10936
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
> Environment: Ubuntu 16
> Output of {{java -version}}:
> java version "1.8.0_131"
> Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
>Reporter: Matthew Caruana Galizia
>
> I'm currently trying to index a large document with thousands of child 
> documents. I see the following in solr.log. After that, the IndexWriter is 
> closed and all subsequent updates fail.
> {code:java}
> 2017-06-21 19:33:37.284 ERROR (qtp959447386-21) [   x:kc] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Exception 
> writing document id 
> 033c9919dfeb06dd6ae7166aad554652b8eadd6c6c602c6dd837d3324f715f99 to the 
> index; possible analysis error.
>   at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:206)
>   at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:979)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1192)
>   at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:748)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:336)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>   at 
> org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
>   at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:180)
>   at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:136)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:306)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:251)
>   at 
> 

[jira] [Commented] (SOLR-10797) Numeric PointsFields: test ranges with IndexOrDocValuesQuery

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10797:
---

I removed this issue as a sub-task of SOLR-9995, since I don't think it should 
block the release of 7.0.

> Numeric PointsFields: test ranges with IndexOrDocValuesQuery
> 
>
> Key: SOLR-10797
> URL: https://issues.apache.org/jira/browse/SOLR-10797
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> TestPointFields.testIndexOrDocValuesQuery() tests that IndexOrDocValuesQuery 
> is created under the appropriate circumstances, but these queries are not 
> functionally tested.



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

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

[jira] [Updated] (SOLR-10797) Numeric PointsFields: test ranges with IndexOrDocValuesQuery

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10797:
--
Issue Type: Test  (was: Sub-task)
Parent: (was: SOLR-9995)

> Numeric PointsFields: test ranges with IndexOrDocValuesQuery
> 
>
> Key: SOLR-10797
> URL: https://issues.apache.org/jira/browse/SOLR-10797
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> TestPointFields.testIndexOrDocValuesQuery() tests that IndexOrDocValuesQuery 
> is created under the appropriate circumstances, but these queries are not 
> functionally tested.



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

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

[jira] [Resolved] (SOLR-10794) Numeric PointsFields: need more testing of sorting/boosting by numeric functions

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10794.
---
   Resolution: Fixed
Fix Version/s: 7.0

I think with ubiquitous points randomization we can resolve this as Fixed.

> Numeric PointsFields: need more testing of sorting/boosting by numeric 
> functions
> 
>
> Key: SOLR-10794
> URL: https://issues.apache.org/jira/browse/SOLR-10794
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0
>
>
> Places to audit for points testing: TestQueryTypes, SortByFunctionTest, 
> TestFunctionQuery



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

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

[jira] [Updated] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11130:

Fix Version/s: 7.0

> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward 
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, 
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] 
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
>   at 
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName + 
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which 
> does not have any replica for the collection. Now in v1 API, solrj would 
> refuse to send the request and complain that no default collection is set but 
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without 
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node 
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default 
> collection
> # We detect that users are trying to invoke a collection specific v2 api and 
> we add a new method in V2RequestBuilder to specify a collection name and 
> ensure that the user calls it.



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

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

[jira] [Comment Edited] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Anshum Gupta (JIRA)]

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

Anshum Gupta edited comment on SOLR-11130 at 7/25/17 6:57 PM:
--

+1. Please push it to 7.0.
Thanks Shalin, and Noble.


was (Author: anshumg):
+1. Please push it to 7.0.
Thanks Shalin.

> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward 
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, 
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] 
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
>   at 
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName + 
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which 
> does not have any replica for the collection. Now in v1 API, solrj would 
> refuse to send the request and complain that no default collection is set but 
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without 
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node 
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default 
> collection
> # We detect that users are trying to invoke a collection specific v2 api and 
> we add a new method in V2RequestBuilder to specify a collection name and 
> ensure that the user calls it.



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

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

[jira] [Updated] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11130:

Priority: Blocker  (was: Major)

> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward 
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, 
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] 
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
>   at 
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName + 
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which 
> does not have any replica for the collection. Now in v1 API, solrj would 
> refuse to send the request and complain that no default collection is set but 
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without 
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node 
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default 
> collection
> # We detect that users are trying to invoke a collection specific v2 api and 
> we add a new method in V2RequestBuilder to specify a collection name and 
> ensure that the user calls it.



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

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

[jira] [Commented] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-11130:
-

+1. Please push it to 7.0.
Thanks Shalin.

> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward 
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, 
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] 
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
>   at 
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName + 
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which 
> does not have any replica for the collection. Now in v1 API, solrj would 
> refuse to send the request and complain that no default collection is set but 
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without 
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node 
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default 
> collection
> # We detect that users are trying to invoke a collection specific v2 api and 
> we add a new method in V2RequestBuilder to specify a collection name and 
> ensure that the user calls it.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_141) - Build # 20198 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream

Error Message:
Error from server at https://127.0.0.1:38621/solr/workQueue_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /solr/workQueue_shard2_replica_n3/update. Reason: Can not 
find: /solr/workQueue_shard2_replica_n3/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:38621/solr/workQueue_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/workQueue_shard2_replica_n3/update. Reason:
Can not find: /solr/workQueue_shard2_replica_n3/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([F4AA8A2FFD6CB6:22342B710C9746A6]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream(StreamExpressionTest.java:6774)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

Re: 7.0 Release Update

[Anshum Gupta]

I will *try* to get to it, but can't confirm. If someone else has a spare
cycle and can take it up before I get to it, please do.

-Anshum

On Tue, Jul 25, 2017 at 10:44 AM Cassandra Targett 
wrote:

> I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
> fields as deprecated) is SOLR-11023, which Hoss was working on. As he
> noted last night, he is off for vacation for the next 2 weeks. Is
> anyone else available to work on it so 7.0 isn't stalled for 2+ more
> weeks?
>
> Now would also be a good time to look over any other bugs with
> PointFields and make a case if any should be considered blockers for
> 7.0. I think they all share a label:
>
> https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points
>
> On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
>  wrote:
> >
> > : So, my overall point is that if A) we agree that we want to deprecate
> > : Trie* numeric fields, and B) we want to hold up the 7.0 release until
> > : that's done, it's more than just updating the example schemas if we
> > : want to ensure a quality app for users. We still need to fix the tests
> > : and also fix bugs that are going to be really painful for users. And
> > : to get all that done soon, we definitely need some more volunteers.
> >
> > I've beefed up the description of SOLR-10807 with tips on how people can
> > help out...
> >
> > https://issues.apache.org/jira/browse/SOLR-10807
> >
> >
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > -
> > 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] [Updated] (SOLR-8964) Add CorrelateStream to compute Pearson's correlation coefficient for two streams

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-8964:

Component/s: streaming expressions

> Add CorrelateStream to compute Pearson's correlation coefficient for two 
> streams
> 
>
> Key: SOLR-8964
> URL: https://issues.apache.org/jira/browse/SOLR-8964
> Project: Solr
>  Issue Type: New Feature
>  Components: streaming expressions
>Reporter: Joel Bernstein
> Fix For: 6.2, 7.0
>
>
> The CorrelateStream will compute the Pearsons correlation coefficient for two 
> streams. 
> Sample syntax below will calculate the Pearsons correlation for two time 
> series streams. See SOLR-8963 for the *time* function:
> {code}
> correlate(rollup(time(search()),
>   rollup(time(search()))
> {code}



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

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

[jira] [Updated] (SOLR-8919) Add SELECT COUNT(DISTINCT COL) queries to the SQL Interface

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-8919:

Component/s: Parallel SQL

> Add SELECT COUNT(DISTINCT COL) queries to the SQL Interface
> ---
>
> Key: SOLR-8919
> URL: https://issues.apache.org/jira/browse/SOLR-8919
> Project: Solr
>  Issue Type: Bug
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.2, 7.0
>
>
> While analyzing the Enron emails for SOLR-, I was wishing that 
> COUNT(DISTINCT) was implemented. This ticket is to implement it.



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

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

[jira] [Resolved] (SOLR-10848) V2 API _introspect should point to the new reference guide

[Cassandra Targett (JIRA)]

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

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

Fixed all the links in the specs.

I created SOLR-11143 as a future enhancement to dynamically add the version; 
shouldn't hold up resolving this, though.

> V2 API _introspect should point to the new reference guide
> --
>
> Key: SOLR-10848
> URL: https://issues.apache.org/jira/browse/SOLR-10848
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, v2 API
>Reporter: Tomás Fernández Löbbe
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> It would be nice if we can point to the specific version of the documentation 
> for this particular version of Solr



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

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

[jira] [Created] (SOLR-11143) Dynamically update doc version in v2 API specs

[Cassandra Targett (JIRA)]

Cassandra Targett created SOLR-11143:


 Summary: Dynamically update doc version in v2 API specs
 Key: SOLR-11143
 URL: https://issues.apache.org/jira/browse/SOLR-11143
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: v2 API
Reporter: Cassandra Targett
Priority: Minor


SOLR-10848 updated documentation links in the v2 API specs to the new Ref 
Guide. It would be nice, however, if those links could dynamically add the Solr 
version based on the built version of Solr the specs are included with.

So, for Solr 7.5 (hypothetically), something like this:

{{"documentation": 
"https://lucene.apache.org/solr/guide/collections-api.html#create"}}

would become this:

"documentation": 
"https://lucene.apache.org/solr/guide/7_5/collections-api.html#create;



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

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

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

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10933:
-
Component/s: streaming expressions

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



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

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

[jira] [Updated] (SOLR-10651) Streaming Expressions statistical functions library

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10651:
-
Component/s: streaming expressions

> Streaming Expressions statistical functions library
> ---
>
> Key: SOLR-10651
> URL: https://issues.apache.org/jira/browse/SOLR-10651
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
> Fix For: 7.0
>
>
> This is a ticket for organizing the new statistical programming features of 
> Streaming Expressions. It's also a place for the community to discuss what 
> functions are needed to support statistical programming. 
> Basic Syntax:
> {code}
> let(a = timeseries(...),
> b = timeseries(...),
> c = col(a, count(*)),
> d = col(b, count(*)),
> r = regress(c, d),
> tuple(p = predict(r, 50)))
> {code}
> The expression above is doing the following:
> 1) The let expression is setting variables (a, b, c, d, r).
> 2) Variables *a* and *b* are the output of timeseries() Streaming 
> Expressions. These will be stored in memory as lists of Tuples containing the 
> time series results.
> 3) Variables *c* and *d* are set using the *col* evaluator. The col evaluator 
> extracts a column of numbers from a list of tuples. In the example *col* is 
> extracting the count\(*\) field from the two time series result sets.
> 4) Variable *r* is the output from the *regress* evaluator. The regress 
> evaluator performs a simple regression analysis on two columns of numbers.
> 5) Once the variables are set, a single Streaming Expression is run by the 
> *let* expression. In the example the *tuple* expression is run. The tuple 
> expression outputs a single Tuple with name/value pairs. Any Streaming 
> Expression can be run by the *let* expression so this can be a complex 
> program. The streaming expression run by *let* has access to all the 
> variables defined earlier.
> 6) The tuple expression in the example has one name / value pair. The name 
> *p* is set to the output of the *predict* evaluator. The predict evaluator is 
> predicting the value of a dependent variable based on the independent 
> variable 50. The regression result stored in variable *r* is used to make the 
> prediction.
> 7) The output of this expression will be a single tuple with the value of the 
> predict function in the *p* field.
> The growing list of issues linked to this ticket are the array manipulation 
> and statistical functions that will form the basis of the stats library. The 
> vast majority of these functions are backed by algorithms in Apache Commons 
> Math. Other machine learning and math libraries will follow.



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

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

[jira] [Resolved] (SOLR-10314) Spellcheck with SnowballPorterFilterFactory and Synonyms doesn't work well

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-10314.
--
   Resolution: Information Provided
Fix Version/s: (was: 6.7)
   (was: 7.0)

I'm going to close this issue as it seems there isn't a ton that can be done 
about it - it's expected behavior for the most part, and the solution would be 
much larger than this narrow use case.

> Spellcheck with SnowballPorterFilterFactory and Synonyms doesn't work well
> --
>
> Key: SOLR-10314
> URL: https://issues.apache.org/jira/browse/SOLR-10314
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Reporter: Cassandra Targett
>
> As noted in SOLR-10252, the default spellcheck configuration in the 
> data_driven_schema_configs (and basic_configs) uses the {{\_text_}} field as 
> the default field for spellcheck. This field is {{text_general}} field type.
> If I use this default configuration for spellcheck, but modify the 
> {{text_general}} field to use the SnowballPorterFilterFactory (with 
> language=German in this case), and have synonyms in my analysis chain, 
> queries to the {{/spell}} request handler will fail when there are 2 or more 
> terms which are both preceded with a {{+}} operator. 
> Note that the default spellcheck configuration also enables 
> spellcheck.collate - if I disable that, I do not get any error. I also do not 
> get an error if I use only 1 term, even if it is spelled "correctly". If at 
> least one of the terms is spelled incorrectly, that also does not give an 
> error.
> So, in summary, there's a pretty specific list of variables at work here:
> # {{/spell}} request handler
> # 2 or more terms, both spelled correctly (or, both terms exist in the index)
> # all terms required with {{+}}
> # synonyms (there is a big list in this case, which I cannot share...see 
> SOLR-10252 for an example of the parsed query to see how big the list can get)
> # SnowballPorterFilter
> # spellcheck.collate=true
> The error returned is: 
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
> from server at http://localhost:7574/solr/spelltest3_shard1_replica2: String 
> index out of range: -1
> {code}
> I made several experiments and found that if synonyms are removed from the 
> field type (and thus the query analysis chain), the query is successful with 
> collations enabled. So it's not SnowballPorterFilter by itself, but with 
> {{+}} and synonyms and collation.
> The field type definition is:
> {code}
>positionIncrementGap="100" multiValued="true">
> 
>   
>ignoreCase="true"/>
>   
>   
> 
> 
>   
>ignoreCase="true"/>
>ignoreCase="true" synonyms="synonyms.txt"/>
>   
>   
> 
>   
> {code}
> This problem was found with 5.5.2, but I verified it still exists in 6.4 and 
> 6.5.



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

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

[jira] [Updated] (SOLR-10991) Support removing top N influential observations in the regress Stream Evaluator

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10991:
-
Component/s: streaming expressions

> Support removing top N influential observations in the regress Stream 
> Evaluator
> ---
>
> Key: SOLR-10991
> URL: https://issues.apache.org/jira/browse/SOLR-10991
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.0
>
>
> Influential observations are *outliers* that have a large effect on the slope 
> of a regression line. It is very useful to be able to automatically remove 
> influential observations prior to running a simple regression.
> Syntax:
> {code}
> regress(colA, colB, 10)
> {code}
> The function above regresses colA and colB after removing the top 10 
> influential observations from the data set.
> The approach taken will be to remove each observation one and at a time and 
> re-run the regression on the data set minus the observation. After each run 
> the difference in model fit will be recorded. After completing the regression 
> runs, N observations that had the highest difference of fit will be removed 
> from the data set. The final regression will be run without those 
> observations.



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

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

[jira] [Updated] (SOLR-10766) Allow col Stream Evaluator to pull columns from a stream

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10766:
-
Component/s: streaming expressions

> Allow col Stream Evaluator to pull columns from a stream
> 
>
> Key: SOLR-10766
> URL: https://issues.apache.org/jira/browse/SOLR-10766
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.0
>
>
> Currently the *col* Stream Evaluator pulls a column of number form an 
> in-memory list of Tuples. When pulling large arrays of numbers it will be 
> much more efficient to pull the column directly from the stream.



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

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

[jira] [Updated] (SOLR-10633) Add cosAngle Stream Evaluator

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10633:
-
Component/s: streaming expressions

> Add cosAngle Stream Evaluator
> -
>
> Key: SOLR-10633
> URL: https://issues.apache.org/jira/browse/SOLR-10633
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.0
>
>
> This ticket will add a cosAngle Stream Evaluator to calculate the cosine 
> angle between two vectors. 
> {code}
> a = cosAngle(colA, colB)
> {code}
> The implementation is provided by Apache Commons Numbers



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

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

[jira] [Commented] (SOLR-9606) Remove GeoHashField from Solr

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-9606:
-

[~dsmiley] - You deprecated this field with SOLR-10729. Should this be closed 
as a duplicate? or do you need it open to remove the fields from master for 8.0?

> Remove GeoHashField from Solr
> -
>
> Key: SOLR-9606
> URL: https://issues.apache.org/jira/browse/SOLR-9606
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.0
>
>
> I'd like to remove GeoHashField from Solr -- 7.0.  I see no use-case for it 
> any more.  And it's presence is distracting from spatial fields you *should* 
> be using.



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

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

[jira] [Commented] (SOLR-10831) Document Replica Types

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10831:
--

[~tomasflobbe] - this issue has no description, but from the component it's for 
documentation for the new replica types you added with SOLR-10233, correct?

I was looking at this feature yesterday thinking about docs for it and from 
what I can tell these are the changes needed:

* update Collections API CREATE command docs for new params, {{nrtReplicas}}, 
{{tlogReplicas}}, {{pullReplicas}}. Also update {{replicationFactor}} to 
indicate the default type.
* update Collections API ADDREPLICA command doc for new param {{type}}.
* Some sort of explanation <> on best practices for when to use 
which types and caveats or limitations when using them.

Does that sound right? 

> Document Replica Types
> --
>
> Key: SOLR-10831
> URL: https://issues.apache.org/jira/browse/SOLR-10831
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: 7.0
>
>




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

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

[jira] [Resolved] (SOLR-10871) Remove monospace text from headings in Ref Guide

[Cassandra Targett (JIRA)]

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

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

> Remove monospace text from headings in Ref Guide
> 
>
> Key: SOLR-10871
> URL: https://issues.apache.org/jira/browse/SOLR-10871
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
> Attachments: monospace-in-header-new.png, 
> monospace-in-header-old.png, ref-guide-monospace-headings.txt, Screen Shot 
> 2017-06-12 at 11.20.04 AM.png
>
>
> Monospace text doesn't look great in section headings in the PDF - the font 
> color is different and the size is smaller. With the old way of generating 
> the PDF we could make it the same color & adjust the font size so it was less 
> jarring. We don't have that option now, so the difference is much more 
> pronounced.
> I found 148 instances of this in 40 files. I think we can make that "normal" 
> text without losing any important information for the reader.
> Attaching screenshots of what it used to look like and what it now looks 
> like, to illustrate the difference.



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

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

[jira] [Commented] (SOLR-11093) implement Points/Numeric support for graph query

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-11093:
-

Why is zeroCount an integer instead of simply a hasZero boolean?

Here's my first iteration (subsequently changed futher below).  All I did was 
rename {{hasNext}} to {{positioned}} (which I feel is more clear), added some 
inline comments for what the fields mean, and I added a leading check inside 
next(). So this was simpler than I thought.
{code:java}
/** Returns an iterator over the values in the set. */
  public LongIterator iterator() {
return new LongIterator() {
  // if this set contains zero, this iterator's initial state is already 
positioned
  private boolean positioned = zeroCount > 0;
  private int i = -1; // current index into vals[]
  private long value = 0; // if positioned, this is our current value

  @Override
  public boolean hasNext() {
if (positioned) {
  return true;
}
while (++i < vals.length) {
  value = vals[i];
  if (value != 0) {
return positioned = true;
  }
}
return false;
  }

  @Override
  public long next() {
if (!positioned) {
  if (!hasNext()) {
throw new NoSuchElementException();
  }
}
positioned = false;
return value;
  }

};
  }
{code}

And here's what I think is the most clear approach using a countdown integer:
{code:java}

  /** Returns an iterator over the values in the set. */
  public LongIterator iterator() {
return new LongIterator() {
  private int remainingValues = cardinality();
  private int valsIdx = 0;

  @Override
  public boolean hasNext() {
return remainingValues > 0;
  }

  @Override
  public long next() {
if (!hasNext()) {
  throw new NoSuchElementException();
}
remainingValues--;

if (remainingValues == 0 && zeroCount > 0) {
  return 0;
}

while (true) { // guaranteed to find another value if we get here
  long value = vals[valsIdx++];
  if (value != 0) {
return value;
  }
}
  }

};
{code}
This has the benefit that we don't loop past the last value of the array.  It 
also has fewer state variables. Also, you don't "pay" any advancement cost in 
hasNext(); it's only next() where the value is going to actually be consumed.

> implement Points/Numeric support for graph query
> 
>
> Key: SOLR-11093
> URL: https://issues.apache.org/jira/browse/SOLR-11093
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 7.0
>
> Attachments: SOLR-11093.patch, SOLR-11093.patch, SOLR-11093.patch
>
>
> It looks like GraphQueryTest only has tests for strings.  We should add tests 
> for numeric fields and then enable points randomization.



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

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

[jira] [Commented] (SOLR-10760) Remove trie field types and fields from example schemas

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10760:
---

If there are no objections, I'll commit this tomorrow.

> Remove trie field types and fields from example schemas
> ---
>
> Key: SOLR-10760
> URL: https://issues.apache.org/jira/browse/SOLR-10760
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0
>
> Attachments: SOLR-10760.patch, SOLR-10760.patch
>
>
> In order to make points fields the default, we should remove all trie field 
> types and fields from example schemas.



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

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

[jira] [Updated] (SOLR-10716) Add termVectors Stream Evaluator

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10716:
-
Component/s: streaming expressions

> Add termVectors Stream Evaluator
> 
>
> Key: SOLR-10716
> URL: https://issues.apache.org/jira/browse/SOLR-10716
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.0
>
> Attachments: SOLR-10716.patch
>
>
> The termVectors Stream Evaluator returns tf-idf word vectors for a text field 
> in a list of tuples. A Lucene analyzer can be specified to support flexible 
> word analysis.
> The word vectors can then be used for various machine learning operations.
> Syntax:
> {code}
> r = search()
> v = termVectors(r, fieldA, analyzerFied)
> {code}
>  



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Susheel Kumar (JIRA)]

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

Susheel Kumar commented on SOLR-10944:
--

Thank you so much, Joel.

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Assigned] (SOLR-10845) GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only fields?)

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-10845:
---

Assignee: Yonik Seeley

> GraphTermsQParserPlugin doesn't work with Point fields (or DocValues only 
> fields?)
> --
>
> Key: SOLR-10845
> URL: https://issues.apache.org/jira/browse/SOLR-10845
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Yonik Seeley
>  Labels: numeric-tries-to-points
>
> GraphTermsQParserPlugin (aka {{graphTerms}}) doesn't work if the {{f}} field 
> being used to build the graph is "Points" based (because the field won't have 
> any {{Terms}})
> GraphTermsQParserPlugin should either be enhanced to work correctly with 
> Points based fields, or should give a clear error if the {{isPointsField()}} 
> returns true for the field type being used.  At present, it silently matches 
> no documents.
> (Note: It appears at first glance that the same basic problem probably exists 
> for any trie/string field which is {{docValues="true" indexed="false}} ?)



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

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

[jira] [Resolved] (SOLR-10629) solrcloud 6.5 use dataimport check status appear double status,Can not be distinguished by program

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-10629.
--
   Resolution: Cannot Reproduce
Fix Version/s: (was: 6.7)
   (was: 7.0)

Closing as Cannot Reproduce due to insufficient information provided.

> solrcloud 6.5 use dataimport check status appear double status,Can not be 
> distinguished by program
> --
>
> Key: SOLR-10629
> URL: https://issues.apache.org/jira/browse/SOLR-10629
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: clients - java
>Affects Versions: 6.5
> Environment: centos 6.7 jdk 1.8 version
>Reporter: steven
>Priority: Critical
>
> solrcloud 6.5 use dataimport check status appear double status,Can not be 
> distinguished by program



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

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

Re: 7.0 Release Update

[Cassandra Targett]

I believe the only remaining blocker to SOLR-10803 (to mark all Trie*
fields as deprecated) is SOLR-11023, which Hoss was working on. As he
noted last night, he is off for vacation for the next 2 weeks. Is
anyone else available to work on it so 7.0 isn't stalled for 2+ more
weeks?

Now would also be a good time to look over any other bugs with
PointFields and make a case if any should be considered blockers for
7.0. I think they all share a label:
https://issues.apache.org/jira/issues/?jql=status%20%3D%20Open%20AND%20labels%20%3D%20numeric-tries-to-points

On Tue, Jul 11, 2017 at 4:59 PM, Chris Hostetter
 wrote:
>
> : So, my overall point is that if A) we agree that we want to deprecate
> : Trie* numeric fields, and B) we want to hold up the 7.0 release until
> : that's done, it's more than just updating the example schemas if we
> : want to ensure a quality app for users. We still need to fix the tests
> : and also fix bugs that are going to be really painful for users. And
> : to get all that done soon, we definitely need some more volunteers.
>
> I've beefed up the description of SOLR-10807 with tips on how people can
> help out...
>
> https://issues.apache.org/jira/browse/SOLR-10807
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> 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

[JENKINS] Lucene-Solr-master-Windows () - Build # 6781 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6781/
Java: 

No tests ran.

Build Log:
[...truncated 2 lines...]
FATAL: java.io.IOException: Unexpected termination of the channel
java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2638)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:3113)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:853)
at java.io.ObjectInputStream.(ObjectInputStream.java:349)
at 
hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:48)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:35)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:59)
Caused: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:73)
Caused: hudson.remoting.RequestAbortedException
at hudson.remoting.Request.abort(Request.java:307)
at hudson.remoting.Channel.terminate(Channel.java:905)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:92)
at ..remote call to Windows VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1554)
at hudson.remoting.Request.call(Request.java:172)
at hudson.remoting.Channel.call(Channel.java:838)
at hudson.FilePath.act(FilePath.java:1082)
at 
org.jenkinsci.plugins.envinject.service.EnvironmentVariablesNodeLoader.gatherEnvVarsForNode(EnvironmentVariablesNodeLoader.java:64)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.loadEnvironmentVariablesNode(EnvInjectListener.java:80)
at 
org.jenkinsci.plugins.envinject.EnvInjectListener.setUpEnvironment(EnvInjectListener.java:43)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.createLauncher(AbstractBuild.java:528)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:448)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-master-Windows #6781
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-master-Windows #6781
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-master-Windows #6781
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Updated] (SOLR-10786) Add DBSCAN clustering Streaming Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10786:
--
Description: 
The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
DBSCAN clustering algorithm.

Clustering implementation will be provided by Apache Commons Math.

  was:
The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
DBSCAN clustering algorithm.

Clustering implementation will be provided by Apache Commons Math


> Add DBSCAN clustering Streaming Evaluator
> -
>
> Key: SOLR-10786
> URL: https://issues.apache.org/jira/browse/SOLR-10786
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10786.patch
>
>
> The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
> DBSCAN clustering algorithm.
> Clustering implementation will be provided by Apache Commons Math.



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10944:
---

Thanks [~susheel2...@gmail.com]!

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Updated] (SOLR-10944) Get expression fails to return EOF tuple

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10944:
--
Fix Version/s: 7.1
   master (8.0)

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Resolved] (SOLR-10944) Get expression fails to return EOF tuple

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-10944.
---
Resolution: Resolved

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10944:


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

SOLR-10944: Update CHANGES.txt


> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10944:


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

SOLR-10944: Update CHANGES.txt


> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10944:


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

SOLR-10944: Get expression fails to return EOF tuple


> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Commented] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11130:
--

This is a pretty bad bug since it makes reliably using V2 API requests from 
SolrJ impossible so I'd really like to put it in 7.0. So, if the changes aren't 
too invasive and the testing adequate enough, we should go for it.

> SolrJ routes V2Request to wrong nodes and such nodes are not able to forward 
> these requests correctly
> -
>
> Key: SOLR-11130
> URL: https://issues.apache.org/jira/browse/SOLR-11130
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Affects Versions: 6.6, master (8.0)
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
> Attachments: SOLR-11130.patch
>
>
> I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, 
> I see a weird NullPointerException:
> {code}
> 5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] 
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
> {code}
> and the corresponding exception on the solrj client was:
> {code}
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
> Error from server at http://127.0.0.1:33527/solr: Unknown Error
>   at 
> __randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
>   at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
>   at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
>   at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>   at 
> org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
> {code}
> The code used to invoke the api was:
> {code}
> V2Request request = new V2Request.Builder("/c/" + collectionName + 
> "/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
> solrClient.request(request);
> {code}
> This exception happens when the config API call is sent to a Solr node which 
> does not have any replica for the collection. Now in v1 API, solrj would 
> refuse to send the request and complain that no default collection is set but 
> the V2Request does not do that.
> So there are two bugs here:
> # V2Request tries to send request for collection X to a random node without 
> caring for correct routing
> # The node receiving such request is not able to forward it to the right node 
> and fails with a NPE.
> To solve 1, our options are:
> # Either we start requiring the same for V2 i.e. user must set default 
> collection
> # We detect that users are trying to invoke a collection specific v2 api and 
> we add a new method in V2RequestBuilder to specify a collection name and 
> ensure that the user calls it.



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10944:


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

SOLR-10944: Get expression fails to return EOF tuple


> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Commented] (SOLR-10944) Get expression fails to return EOF tuple

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10944:
---

Patch looks OK to me. I'll commit shortly.

> Get expression fails to return EOF tuple 
> -
>
> Key: SOLR-10944
> URL: https://issues.apache.org/jira/browse/SOLR-10944
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Affects Versions: 6.6
>Reporter: Susheel Kumar
>Priority: Blocker
>  Labels: patch
> Attachments: SOLR-10944.patch
>
>
> Below is a simple let expr where search would not find a match and return 0 
> result.  In that case, we expect get(a) to show a EOF tuple while it is 
> throwing exception.
> ===
> let(a=search(collection1,
> q=id:9, 
> fl="id,business_email",
> sort="business_email asc"),
> get(a)
> )
> {
>   "result-set": {
> "docs": [
>   {
> "EXCEPTION": "Index: 0, Size: 0",
> "EOF": true,
> "RESPONSE_TIME": 8
>   }
> ]
>   }
> }



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

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

[jira] [Updated] (SOLR-11126) Node-level health check handler

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-11126:

Summary: Node-level health check handler  (was: Top level node-level health 
check handler)

> Node-level health check handler
> ---
>
> Key: SOLR-11126
> URL: https://issues.apache.org/jira/browse/SOLR-11126
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Anshum Gupta
>Assignee: Anshum Gupta
>
> Solr used to have the PING handler at core level, but with SolrCloud, we are 
> missing a node level health check handler. It would be good to have. The API 
> would look like:
> * solr/admin/healthcheck (v1 API)
> * solr/node/healthcheck (v2 API)



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

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

[jira] [Comment Edited] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-10814 at 7/25/17 4:03 PM:


The problem with the solution is, the configuration for what feature of 
authentication to use is set in the authorization plugin. Every plugin will 
need to have a special flag to achieve this. This makes no sense to me. The 
framework is supposed to take care of these things. 

If there is a Ranger Authorization plugin, you want them to implement this flag 
as well?


was (Author: noble.paul):
The problem with the solution is, the configuration for what feature of 
authentication to use is set in the authorization plugin. Every plugin will 
need to have a special flag to achieve this. This makes no sense to me. The 
framework is supposed to take care of these things. 

> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based permission definitions which are assigned to 
> users.
> The authorization framework in Solr passes the information about the request 
> (to be authorized) using an instance of AuthorizationContext class. Currently 
> the only way to extract authenticated user is via getUserPrincipal() method 
> which returns an instance of java.security.Principal class. The 
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the 
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName. 
> Hence it works fine. But in case of kerberos authentication, the user 
> principal also contains the RELM information e.g. instead of foo, it would 
> return f...@example.com. This means if the user changes the authentication 
> mechanism, he would also need to change the user-role mapping in 
> authorization section to use f...@example.com instead of foo. This is not 
> good from usability perspective.   



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

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

[jira] [Commented] (SOLR-10814) Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos authentication

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-10814:
---

The problem with the solution is, the configuration for what feature of 
authentication to use is set in the authorization plugin. Every plugin will 
need to have a special flag to achieve this. This makes no sense to me. The 
framework is supposed to take care of these things. 

> Solr RuleBasedAuthorization config doesn't work seamlessly with kerberos 
> authentication
> ---
>
> Key: SOLR-10814
> URL: https://issues.apache.org/jira/browse/SOLR-10814
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> Solr allows configuring roles to control user access to the system. This is 
> accomplished through rule-based permission definitions which are assigned to 
> users.
> The authorization framework in Solr passes the information about the request 
> (to be authorized) using an instance of AuthorizationContext class. Currently 
> the only way to extract authenticated user is via getUserPrincipal() method 
> which returns an instance of java.security.Principal class. The 
> RuleBasedAuthorizationPlugin implementation invokes getName() method on the 
> Principal instance to fetch the list of associated roles.
> https://github.com/apache/lucene-solr/blob/2271e73e763b17f971731f6f69d6ffe46c40b944/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L156
> In case of basic authentication mechanism, the principal is the userName. 
> Hence it works fine. But in case of kerberos authentication, the user 
> principal also contains the RELM information e.g. instead of foo, it would 
> return f...@example.com. This means if the user changes the authentication 
> mechanism, he would also need to change the user-role mapping in 
> authorization section to use f...@example.com instead of foo. This is not 
> good from usability perspective.   



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

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

[jira] [Commented] (SOLR-10786) Add DBSCAN clustering Streaming Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-10786:
---

Initial patch, tests to come.

> Add DBSCAN clustering Streaming Evaluator
> -
>
> Key: SOLR-10786
> URL: https://issues.apache.org/jira/browse/SOLR-10786
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10786.patch
>
>
> The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
> DBSCAN clustering algorithm.
> Clustering implementation will be provided by Apache Commons Math



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

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

[jira] [Updated] (SOLR-10786) Add DBSCAN clustering Streaming Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add DBSCAN clustering Streaming Evaluator
> -
>
> Key: SOLR-10786
> URL: https://issues.apache.org/jira/browse/SOLR-10786
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10786.patch
>
>
> The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
> DBSCAN clustering algorithm.
> Clustering implementation will be provided by Apache Commons Math



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

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

[jira] [Updated] (SOLR-10786) Add DBSCAN clustering Streaming Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10786:
--
Fix Version/s: (was: 7.0)
   7.1
   master (8.0)

> Add DBSCAN clustering Streaming Evaluator
> -
>
> Key: SOLR-10786
> URL: https://issues.apache.org/jira/browse/SOLR-10786
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10786.patch
>
>
> The DBSCAN clustering Stream Evaluator will cluster numeric vectors using the 
> DBSCAN clustering algorithm.
> Clustering implementation will be provided by Apache Commons Math



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

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