[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 423 - Still unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.LIROnShardRestartTest.testAllReplicasInLIR

Error Message:
Path must not end with / character

Stack Trace:
java.lang.IllegalArgumentException: Path must not end with / character
at 
__randomizedtesting.SeedInfo.seed([E36FE4B4C0CCB6C9:B9F7DE72BE4CD12E]:0)
at org.apache.zookeeper.common.PathUtils.validatePath(PathUtils.java:58)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1523)
at 
org.apache.solr.common.cloud.SolrZkClient.lambda$getChildren$4(SolrZkClient.java:346)
at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)
at 
org.apache.solr.common.cloud.SolrZkClient.getChildren(SolrZkClient.java:346)
at 
org.apache.solr.cloud.LIROnShardRestartTest.testAllReplicasInLIR(LIROnShardRestartTest.java:168)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1226 - Failure

[Apache Jenkins Server]

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

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.OverseerRolesTest.testOverseerRole

Error Message:
Timed out waiting for overseer state change

Stack Trace:
java.lang.AssertionError: Timed out waiting for overseer state change
at 
__randomizedtesting.SeedInfo.seed([2DA9998B0D5ECA55:CC62641F36EDFC84]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:63)
at 
org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:145)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Captured an uncaught exception in thread: Thread[id=373, 
name=OverseerCollectionConfigSetProcessor-72141822702321667-127.0.0.1:53491_solr-n_00,
 

[jira] [Commented] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8581:
--

I attached a patch about this.

> Change LatLonShape encoding to use 4 BYTES Per Dimension
> 
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, 
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, 
> LUCENE-8581.patch, LUCENE-8581_bytes.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive 
> encoding with the first four dimensions as the bounding box of the triangle 
> and the last three dimensions as the vertices of the triangle. To encode the 
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be 
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce 
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the 
> bounding box along with the orientation of the triangle. This also opens the 
> door for supporting {{CONTAINS}} queries.



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

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

[jira] [Updated] (LUCENE-8581) Change LatLonShape encoding to use 4 BYTES Per Dimension

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-8581:
-
Attachment: LUCENE-8581_bytes.patch

> Change LatLonShape encoding to use 4 BYTES Per Dimension
> 
>
> Key: LUCENE-8581
> URL: https://issues.apache.org/jira/browse/LUCENE-8581
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Ignacio Vera
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, 
> LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, LUCENE-8581.patch, 
> LUCENE-8581.patch, LUCENE-8581_bytes.patch
>
>
> {{LatLonShape}} tessellated triangles currently use a relatively naive 
> encoding with the first four dimensions as the bounding box of the triangle 
> and the last three dimensions as the vertices of the triangle. To encode the 
> {{x,y}} vertices in the last three dimensions requires {{bytesPerDim}} to be 
> set to 8, with 4 bytes for the x & y axis, respectively. We can reduce 
> {{bytesPerDim}} to 4 by encoding the index(es) of the vertices shared by the 
> bounding box along with the orientation of the triangle. This also opens the 
> door for supporting {{CONTAINS}} queries.



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

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

Re: Feature: Solr implicitly defined field types?

[David Smiley]

On Fri, Jan 4, 2019 at 12:51 PM Shawn Heisey  wrote:

> Looking at what came before, my preference would have been implicitly
> defined default types -- things like int, string, etc, defined in code.
> The only problem with that comes at Solr upgrade time ... what if we
> decide for a later version (even if it's limited to a major release)
> that IntPointField shouldn't be the implicit class for "int"?  Someone
> who upgrades an index using that implicit type to the new version will
> find that Solr will no longer work.  Which makes the idea unworkable.
>

I addressed this earlier -- search for "luceneMatchVersion" which is key.

RE a file based system schema (what Alexandre suggested)... that sounds
workable but a more complex idea that would take more code & documentation
-- at least relative to the very simple idea of some built-ins in the code
(my proposal).  See SOLR-12768.patch

changes to IndexSchema.
-- 
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11) - Build # 7677 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7677/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseParallelGC

6 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas Timeout waiting to see 
state for collection=MissingSegmentRecoveryTest 
:DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:54422/solr;,   
"node_name":"127.0.0.1:54422_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node4":{   
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"http://127.0.0.1:54421/solr;,   
"node_name":"127.0.0.1:54421_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:54421_solr, 127.0.0.1:54422_solr] Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
   "pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"MissingSegmentRecoveryTest_shard1_replica_n1", 
  "base_url":"http://127.0.0.1:54422/solr;,   
"node_name":"127.0.0.1:54422_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   "leader":"true"},  
   "core_node4":{   
"core":"MissingSegmentRecoveryTest_shard1_replica_n2",   
"base_url":"http://127.0.0.1:54421/solr;,   
"node_name":"127.0.0.1:54421_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false",   "nrtReplicas":"2",   "tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
Timeout waiting to see state for collection=MissingSegmentRecoveryTest 
:DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"http://127.0.0.1:54422/solr;,
  "node_name":"127.0.0.1:54422_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node4":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"http://127.0.0.1:54421/solr;,
  "node_name":"127.0.0.1:54421_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
Live Nodes: [127.0.0.1:54421_solr, 127.0.0.1:54422_solr]
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n1",
  "base_url":"http://127.0.0.1:54422/solr;,
  "node_name":"127.0.0.1:54422_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true"},
"core_node4":{
  "core":"MissingSegmentRecoveryTest_shard1_replica_n2",
  "base_url":"http://127.0.0.1:54421/solr;,
  "node_name":"127.0.0.1:54421_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([657A612AB85F5D26:352FF929E17EEB3B]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:289)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:267)
at 

[jira] [Assigned] (SOLR-13118) Redesign integration tests for nodeAdded/nodeLost trigger state restoration

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-13118:
---

  Assignee: Hoss Man
Attachment: SOLR-13118.patch

In the attached patch, I've remedied this (in 
{{TestSimTriggerIntegration.testNodeLostTriggerRestoreState}} ) via the 
following (non-test) API changes:
 * {{SimCloudManager}} now exposes a public {{getOverseerTriggerThread()}} 
method – allowing Sim tests the same level of accesss to the 
OverseerTriggerThread/ScheduledTriggers that non-sim tests can get via the 
Overseer ode (by way of it's JettyRunner->CoreContainer)
 * {{ScheduledTriggers}} now exposes a public (lucene.internal for tests only) 
method to {{getTrigger(String name)}}
 * {{TriggerBase}} has been refactored to expose a public (lucene.internal for 
tests only) method to get a {{deepCopyState()}}

With these changes, the test(s) can now use the following flow...
 * register an initial trigger w/an effectively infinite {{waitFor}} 
configuration
 * create the nodeAdd/nodeLost situation
 * reach into the ScheduledTriggers in a {{TimeOut.waitFor(...)}} to inspect 
the state of the trigger being tests to know once it's run() and detected the 
situation/event and started tracking it
 ** but not yet executed any actions because of the {{waitFor}} property
 * update the trigger w/ {{waitFor: 0s}}
 * use the latches & event queues of the "mock" trigger actions to confirm that 
the event state information gets preserved from one trigger instance to the 
next, and ultimately process()ed



Unless there are any concerns with this approach, I'll try to update the other 
similarly problematic tests ASAP...
 * TestSimTriggerIntegration.testNodeAddedTriggerRestoreState
 * NodeLostTriggerIntegrationTest.testNodeLostTriggerRestoreState
 * NodeAddedTriggerIntegrationTest.testNodeAddedTriggerRestoreState

(I'd also like to look into re-writing 
TestSimTriggerIntegration.testEventFromRestoredState to use an effectively 
infinit {{waitFor}} and the new direct state introspection before & after 
restarting the overseer rather then the current (delicately problematic) 
precise sleep times ... but that's a lower priority at the moment that i 
haven't fully thought through)

> Redesign integration tests for nodeAdded/nodeLost trigger state restoration
> ---
>
> Key: SOLR-13118
> URL: https://issues.apache.org/jira/browse/SOLR-13118
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13118.patch
>
>
> The (integration) tests related to autoscaling nodeAdd/nodeLost trigger's and 
> restoring their state are problematic for a lot of reasons.
> Beyond some silly implementation mistakes, a fundemental timing/concurrency 
> issue is that (as designed) the tests have no way to ensure that "after" 
> creating a nodeAdded/nodeLost situation, they can wait for the (first 
> instance of) the trigger to run() and detect the situation (recording it in 
> the trigger's internal state) so that the test can subsequently "update" the 
> trigger, forcing a new instance to restore the old state and then execute the 
> trigger actions.  This can result i na lot of flaky-ness if the triggers 
> don't run when "expected"



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

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

[jira] [Created] (SOLR-13118) Redesign integration tests for nodeAdded/nodeLost trigger state restoration

[Hoss Man (JIRA)]

Hoss Man created SOLR-13118:
---

 Summary: Redesign integration tests for nodeAdded/nodeLost trigger 
state restoration
 Key: SOLR-13118
 URL: https://issues.apache.org/jira/browse/SOLR-13118
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man



The (integration) tests related to autoscaling nodeAdd/nodeLost trigger's and 
restoring their state are problematic for a lot of reasons.

Beyond some silly implementation mistakes, a fundemental timing/concurrency 
issue is that (as designed) the tests have no way to ensure that "after" 
creating a nodeAdded/nodeLost situation, they can wait for the (first instance 
of) the trigger to run() and detect the situation (recording it in the 
trigger's internal state) so that the test can subsequently "update" the 
trigger, forcing a new instance to restore the old state and then execute the 
trigger actions.  This can result i na lot of flaky-ness if the triggers don't 
run when "expected"




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

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

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

[Apache Jenkins Server]

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

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

Error Message:
acoll: 1546651816076 bcoll: 1546651816235

Stack Trace:
java.lang.AssertionError: acoll: 1546651816076 bcoll: 1546651816235
at 
__randomizedtesting.SeedInfo.seed([A03EB684EA0C8A08:286A895E44F0E7F0]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.testFillWorkQueue(MultiThreadedOCPTest.java:116)
at 
org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:71)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1070)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1042)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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)
   

[jira] [Commented] (SOLR-12858) EmbeddedSolrServer POST method has contentType issue

[Peter Williams (JIRA)]

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

Peter Williams commented on SOLR-12858:
---

I have (so far) been able to workaround this problem by switching queries to 
use GET instead of POST in my product's embedded Solr delegate.

I have also explored what a proper fix might be, but need a much greater 
understanding of the underlying code and reasons behind the SOLR-12142 change.

> EmbeddedSolrServer POST method has contentType issue
> 
>
> Key: SOLR-12858
> URL: https://issues.apache.org/jira/browse/SOLR-12858
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.4, 7.5
>Reporter: Phillip Klinefelter
>Priority: Major
>
> EmbeddedSolrServer will fail with the following exception when using a POST 
> method.
> {{org.apache.solr.common.SolrException: Bad contentType for search handler 
> :application/javabin request=\{q=*:*}}}{{    at 
> org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:73)}}
> {{     at 
> org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:167)}}
> {{     at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:196)}}
> {{     at org.apache.solr.core.SolrCore.execute(SolrCore.java:2539)}}
> {{     at 
> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:191)}}
> {{     at 
> org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)}}
> {{     at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:974)}}
> {{     at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:990)}}
> A POST method can be added to TestEmbeddedSolrServerConstructors to reproduce 
> or do the following.
> {{embeddedSolrServer.query(new SolrQuery("*:*"), SolrRequest.METHOD.POST);}}
> This worked before Solr 7.4.  The issue appears to have been caused by 
> changes made in SOLR-12142 based on debugging and a discussion I had with 
> [~dsmiley].
> CC [~noble.paul]
>  



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

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

[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 44 - Failure

[Apache Jenkins Server]

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

22 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.RestartWhileUpdatingTest

Error Message:
ObjectTracker found 30 object(s) that were not released!!! [MMapDirectory, 
MDCAwareThreadPoolExecutor, SolrCore, MMapDirectory, MMapDirectory, 
SolrIndexSearcher, MDCAwareThreadPoolExecutor, SolrIndexSearcher, 
TransactionLog, MMapDirectory, MDCAwareThreadPoolExecutor, MMapDirectory, 
MMapDirectory, MMapDirectory, TransactionLog, InternalHttpClient, 
MMapDirectory, MMapDirectory, SolrIndexSearcher, SolrCore, TransactionLog, 
MDCAwareThreadPoolExecutor, SolrIndexSearcher, MMapDirectory, MMapDirectory, 
SolrCore, MMapDirectory, SolrCore, TransactionLog, TransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:508)  
at org.apache.solr.core.SolrCore.(SolrCore.java:959)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1191)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:697)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:901)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1191)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:697)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1054)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1191)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:697)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:508)  
at org.apache.solr.core.SolrCore.(SolrCore.java:959)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1191)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:697)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 

[jira] [Created] (SOLR-13117) Present Introspect as WADL

[Richard O'Sullivan (JIRA)]

Richard O'Sullivan created SOLR-13117:
-

 Summary: Present Introspect as WADL
 Key: SOLR-13117
 URL: https://issues.apache.org/jira/browse/SOLR-13117
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: v2 API
Reporter: Richard O'Sullivan
 Attachments: apache-solr-api.wadl

Add a translator to present the Introspect V2 API as a WADL. A WADL is more 
easily consumed by tools like SoapUI. A sample of a Solr V2 API WADL is 
attached.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution

Error Message:
0.8126481483629882 0.815145265806123

Stack Trace:
java.lang.AssertionError: 0.8126481483629882 0.815145265806123
at 
__randomizedtesting.SeedInfo.seed([E0258140D72476A2:DD5FAAEEF45CDCB5]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution(MathExpressionTest.java:4440)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 16426 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest
   [junit4]   2> Creating dataDir: 

[VOTE] Release PyLucene 7.6.0 (rc1)

[Andi Vajda]

The PyLucene 7.6.0 (rc1) release tracking the recent release of
Apache Lucene 7.6.0 is ready.

A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/7.6.0-rc1/

PyLucene 7.6.0 is built with JCC 3.4 included in these release artifacts.

JCC 3.4 supports Python 3.3+ (in addition to Python 2.3+).
PyLucene may be built with Python 2 or Python 3.

Please vote to release these artifacts as PyLucene 7.6.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Resolved] (SOLR-13111) CVE-2017-1000190 Threat Level 9 Against Solr v7.6. org.simpleframework : simple-xml : 2.7.1. SimpleXML (latest version 2.7.1) is vulnerable to an XXE vulnerability res

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13111.
--
Resolution: Invalid

The vulnerability reported by the scanner is a false positive. It is not 
possible to exploit the vulnerability in this dependency in Solr.

We have created a page that includes this and several other dependencies that 
are flagged and explains how they are not true vulnerabilities for Solr: 
https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools.
 I investigated this dependency and added this .jar today since the .jar is 
only needed during compilation and not runtime.

If you had discovered a real vulnerability, the ASF has created guidelines for 
how to report it, detailed here: https://www.apache.org/security/. Ideally, a 
report is sent to secur...@apache.org first, but if a JIRA is created first 
instead, you are encouraged to mark the issue as private so attack vectors are 
not exposed to the general public before they can be mitigated by the community 
in the form of patches or new releases.

> CVE-2017-1000190  Threat Level 9 Against Solr v7.6.  org.simpleframework : 
> simple-xml : 2.7.1. SimpleXML (latest version 2.7.1) is vulnerable to an XXE 
> vulnerability resulting SSRF, information disclosure, DoS and so on. 
> -
>
> Key: SOLR-13111
> URL: https://issues.apache.org/jira/browse/SOLR-13111
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.6
> Environment: RedHat Linux.    May run from RHEL versions 5, 6 or 7 
> but this issue is from Sonatype component scan and should be independent of 
> Linux platform version.
>Reporter: RobertHathaway
>Priority: Blocker
>
> We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of 
> Solr - 7.6.0 Build,
> Using Scanner 1.56.0-01
> Threat Level 9   Against Solr v7.6.  org.simpleframework 
> SimpleXML (latest version 2.7.1) is vulnerable to an XXE vulnerability 
> resulting SSRF, information disclosure, DoS and so on. 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000190



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

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

[jira] [Resolved] (SOLR-13113) CVE-2018-1000632 Threat Level 7 Against Solr v7.6. dom4j : dom4j : 1.6.1. dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection vulnerability in Class:

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13113.
--
Resolution: Invalid

The vulnerability reported by the scanner is a false positive. It is not 
possible to exploit the vulnerability in this dependency in Solr.

We have created a page that includes this and several other dependencies that 
are flagged and explains how they are not true vulnerabilities for Solr: 
https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools.
 This .jar is listed there.

If you had discovered a real vulnerability, the ASF has created guidelines for 
how to report it, detailed here: https://www.apache.org/security/. Ideally, a 
report is sent to secur...@apache.org first, but if a JIRA is created first 
instead, you are encouraged to mark the issue as private so attack vectors are 
not exposed to the general public before they can be mitigated by the community 
in the form of patches or new releases.

> CVE-2018-1000632  Threat Level 7 Against Solr v7.6.  dom4j : dom4j : 1.6.1. 
> dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection 
> vulnerability in Class: Element. Methods: addElement, addAttribute ...
> 
>
> Key: SOLR-13113
> URL: https://issues.apache.org/jira/browse/SOLR-13113
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
> Environment: RedHat Linux.  May run from RHEL versions 5, 6 or 7 but 
> this issue is from Sonatype component scan and should be independent of Linux 
> platform version.
>Reporter: RobertHathaway
>Priority: Blocker
>
> We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of 
> Solr - 7.6.0 Build,
> Using Scanner 1.56.0-01
> Threat Level 7 Against Solr v7.6.  dom4j : dom4j : 1.6.1
> dom4j version prior to version 2.1.1 contains a CWE-91: XML Injection 
> vulnerability in Class: Element. Methods: addElement, addAttribute that can 
> result in an attacker tampering with XML documents through XML injection. 
> This attack appear to be exploitable via an attacker specifying attributes or 
> elements in the XML document. This vulnerability appears to have been fixed 
> in 2.1.1 or later. 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000632



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

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

[jira] [Resolved] (SOLR-13109) CVE-2015-1832 Threat Level 9 Against Solr v7.6. org.apache.derby : derby : 10.9.1.0. XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache Derby befo

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13109.
--
Resolution: Invalid

The vulnerability reported by the scanner is a false positive. It is not 
possible to exploit the vulnerability in this dependency in Solr.

We have created a page that includes this and several other dependencies that 
are flagged and explains how they are not true vulnerabilities for Solr: 
https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools.
 This .jar is listed there.

If you had discovered a real vulnerability, the ASF has created guidelines for 
how to report it, detailed here: https://www.apache.org/security/. Ideally, a 
report is sent to secur...@apache.org first, but if a JIRA is created first 
instead, you are encouraged to mark the issue as private so attack vectors are 
not exposed to the general public before they can be mitigated by the community 
in the form of patches or new releases.

> CVE-2015-1832 Threat Level 9 Against Solr v7.6.  org.apache.derby : derby : 
> 10.9.1.0. XML external entity (XXE) vulnerability in the SqlXmlUtil code in 
> Apache Derby before 10.12.1.1, w/o Java Security Manager, ...attackers to 
> read arbitrary files or DOS
> -
>
> Key: SOLR-13109
> URL: https://issues.apache.org/jira/browse/SOLR-13109
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.6
> Environment: RedHat Linux.    May run from RHEL versions 5, 6 or 7 
> but this issue is from Sonatype component scan and should be independent of 
> Linux platform version.
>Reporter: RobertHathaway
>Priority: Blocker
>
> Threat Level 9/Critical from Sonatype Application Composition Report run Of 
> Solr - 7.6.0, Using Scanner 1.56.0-01.  Enterprise security won't allow us to 
> move past Solr 6.5 unless this is fixed or somehow remediated. Lots of issues 
> in Solr 7.1 also, may be best to move to latest Solr.
> h2. CVE-2015-1832 Detail
> h3. Current Description
> XML external entity (XXE) vulnerability in the SqlXmlUtil code in Apache 
> Derby before 10.12.1.1, when a Java Security Manager is not in place, allows 
> context-dependent attackers to read arbitrary files or cause a denial of 
> service (resource consumption) via vectors involving XmlVTI and the XML 
> datatype.
> h3. Impact
> *CVSS v3.0 Severity and Metrics:*
>  *Base Score:* [ 9.1 CRITICAL 
> |https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2015-1832=AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H]
>  
>  *Vector:* AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H ([V3 
> legend|https://www.first.org/cvss/specification-document]) 
>  *Impact Score:* 5.2 
>  *Exploitability Score:* 3.9
> [https://nvd.nist.gov/vuln/detail/CVE-2015-1832]



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

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

[jira] [Resolved] (SOLR-13114) CVE-2018-8009 Threat Level 7 Against Solr v7.6. org.apache.hadoop : hadoop-common : 2.7.4. Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 2.9.1, 2.8.0 to 2.8.4, 2

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13114.
--
Resolution: Invalid

The vulnerability reported by the scanner is a false positive. It is not 
possible to exploit the vulnerability in this dependency in Solr.

We have created a page that includes this and several other dependencies that 
are flagged and explains how they are not true vulnerabilities for Solr: 
https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools.
 This .jar is listed there.

If you had discovered a real vulnerability, the ASF has created guidelines for 
how to report it, detailed here: https://www.apache.org/security/. Ideally, a 
report is sent to secur...@apache.org first, but if a JIRA is created first 
instead, you are encouraged to mark the issue as private so attack vectors are 
not exposed to the general public before they can be mitigated by the community 
in the form of patches or new releases.

> CVE-2018-8009  Threat Level 7 Against Solr v7.6.  org.apache.hadoop : 
> hadoop-common : 2.7.4. Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 
> 2.9.1, 2.8.0 to 2.8.4, 2.0.0-alpha to 2.7.6, 0.23.0 to 0.23.11 is exploitable 
> via the zip slip vulnerability
> -
>
> Key: SOLR-13114
> URL: https://issues.apache.org/jira/browse/SOLR-13114
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.6
> Environment: RedHat Linux.  May run from RHEL versions 5, 6 or 7 but 
> this issue is from Sonatype component scan and should be independent of Linux 
> platform version.
>Reporter: RobertHathaway
>Priority: Blocker
>
> We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of 
> Solr - 7.6.0 Build,
> Using Scanner 1.56.0-01
> Threat Level 7 Against Solr v7.6.  org.apache.hadoop : hadoop-common : 2.7.4
> Apache Hadoop 3.1.0, 3.0.0-alpha to 3.0.2, 2.9.0 to 2.9.1, 2.8.0 to 2.8.4, 
> 2.0.0-alpha to 2.7.6, 0.23.0 to 0.23.11 is exploitable via the zip slip 
> vulnerability in places that accept a zip file. 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8009



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

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

[jira] [Resolved] (SOLR-13115) CVE-2012-0881(CVE-2013-4002) Threat Level 7 Against Solr v7.6. xerces : xercesImpl : 2.9.1. Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13115.
--
Resolution: Invalid

The vulnerability reported by the scanner is a false positive. It is not 
possible to exploit the vulnerability in this dependency in Solr.

We have created a page that includes this and several other dependencies that 
are flagged and explains how they are not true vulnerabilities for Solr: 
https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools.
 This .jar is listed there.

If you had discovered a real vulnerability, the ASF has created guidelines for 
how to report it, detailed here: https://www.apache.org/security/. Ideally, a 
report is sent to secur...@apache.org first, but if a JIRA is created first 
instead, you are encouraged to mark the issue as private so attack vectors are 
not exposed to the general public before they can be mitigated by the community 
in the form of patches or new releases.

> CVE-2012-0881(CVE-2013-4002)  Threat Level 7 Against Solr v7.6.  xerces : 
> xercesImpl : 2.9.1. Apache Xerces2 Java Parser before 2.12.0 allows remote 
> attackers to cause a denial of service (CPU consumption) via a crafted 
> message to an XML service...
> 
>
> Key: SOLR-13115
> URL: https://issues.apache.org/jira/browse/SOLR-13115
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.6
> Environment: RedHat Linux.  May run from RHEL versions 5, 6 or 7 but 
> this issue is from Sonatype component scan and should be independent of Linux 
> platform version.
>Reporter: RobertHathaway
>Priority: Blocker
>
> We can't move to Solr 7 without fixing this issue flagged by Sonatype scan Of 
> Solr - 7.6.0 Build,
> Using Scanner 1.56.0-01
> Threat Level 7 Against Solr v7.6.  xerces : xercesImpl : 2.9.1
> Two Issues arising due to Apache Xerces2 Java Parser before 2.12.0.
> h2. CVE-2012-0881
> Apache Xerces2 Java Parser before 2.12.0 allows remote attackers to cause a 
> denial of service (CPU consumption) via a crafted message to an XML service, 
> which triggers hash table collisions.
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0881
> h2. CVE-2013-4002
> XMLscanner.java in Apache Xerces2 Java Parser before 2.12.0, as used in the 
> Java Runtime Environment (JRE) in IBM Java 5.0 before 5.0 SR16-FP3, 6 before 
> 6 SR14, 6.0.1 before 6.0.1 SR6, and 7 before 7 SR5 as well as Oracle Java SE 
> 7u40 and earlier, Java SE 6u60 and earlier, Java SE 5.0u51 and earlier, 
> JRockit R28.2.8 and earlier, JRockit R27.7.6 and earlier, Java SE Embedded 
> 7u40 and earlier, and possibly other products allows remote attackers to 
> cause a denial of service via vectors related to XML attribute names. 
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4002



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

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

[jira] [Commented] (LUCENE-8601) Adding attributes to IndexFieldType

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8601:


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


This message was automatically generated.



> Adding attributes to IndexFieldType
> ---
>
> Key: LUCENE-8601
> URL: https://issues.apache.org/jira/browse/LUCENE-8601
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 7.5
>Reporter: Murali Krishna P
>Priority: Major
> Fix For: master (8.0), 7.7
>
> Attachments: 7x_LUCENE-8601.06.patch, LUCENE-8601.01.patch, 
> LUCENE-8601.02.patch, LUCENE-8601.03.patch, LUCENE-8601.04.patch, 
> LUCENE-8601.05.patch, LUCENE-8601.06.patch, LUCENE-8601.patch
>
>
> Today, we can write a custom Field using custom IndexFieldType, but when the 
> DefaultIndexingChain converts [IndexFieldType to 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java#L662],
>  only few key informations such as indexing options and doc value type are 
> retained. The [Codec gets the 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/DocValuesConsumer.java#L90],
>  but not the type details.
>   
>  FieldInfo has support for ['attributes'| 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L47]
>  and it would be great if we can add 'attributes' to IndexFieldType also and 
> copy it to FieldInfo's 'attribute'.
>   
>  This would allow someone to write a custom codec (extending docvalueformat 
> for example) for only the 'special field' that he wants and delegate the rest 
> of the fields to the default codec.



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

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 5002 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 14003 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20190104_181023_31211570023544158243370.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] [thread 169067 also had an error]
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  Internal Error (sharedRuntime.cpp:931), pid=19351, tid=209139
   [junit4] #  guarantee(cm != NULL) failed: must have containing compiled 
method for implicit division-by-zero exceptions
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+181) (build 
9+181)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9+181, mixed mode, 
tiered, compressed oops, serial gc, bsd-amd64)
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0/hs_err_pid19351.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.java.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J0: EOF 

[...truncated 1553 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java 
-XX:+UseCompressedOops -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/heapdumps 
-ea -esa --illegal-access=deny -Dtests.prefix=tests 
-Dtests.seed=F7AC447B13286FB7 -Xmx512M -Dtests.iters= -Dtests.verbose=false 
-Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random 
-Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=8.0.0 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false 
-Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=1 -DtempDir=./temp 
-Djava.io.tmpdir=./temp 
-Dcommon.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build/clover/db
 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/tools/junit4/solr-tests.policy
 -Dtests.LUCENE_VERSION=8.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.src.home=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX 
-Djava.security.egd=file:/dev/./urandom 
-Djunit4.childvm.cwd=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/J0
 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/test/temp
 -Djunit4.childvm.id=0 -Djunit4.childvm.count=2 -Dfile.encoding=US-ASCII 
-Dtests.disableHdfs=true 
-Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false 
-classpath 

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

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
7s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  1m 42s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 41m 39s{color} 
| {color:red} core in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  6m  
8s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 55m 53s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.LeaderTragicEventTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11126 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12953752/SOLR-11126.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 73797f6 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/260/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/260/testReport/ |
| modules | C: solr/core solr/solrj solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/260/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

[jira] [Commented] (LUCENE-8601) Adding attributes to IndexFieldType

[ASF subversion and git services (JIRA)]

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

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

Commit e8bfa67716368ff3ad670a63d4a8935c6a989cac in lucene-solr's branch 
refs/heads/branch_7x from Michael McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e8bfa67 ]

LUCENE-8601: attributes added to IndexableFieldType during indexing will now be 
preserved in the index and accessible at search time via FieldInfo attributes


> Adding attributes to IndexFieldType
> ---
>
> Key: LUCENE-8601
> URL: https://issues.apache.org/jira/browse/LUCENE-8601
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 7.5
>Reporter: Murali Krishna P
>Priority: Major
> Attachments: 7x_LUCENE-8601.06.patch, LUCENE-8601.01.patch, 
> LUCENE-8601.02.patch, LUCENE-8601.03.patch, LUCENE-8601.04.patch, 
> LUCENE-8601.05.patch, LUCENE-8601.06.patch, LUCENE-8601.patch
>
>
> Today, we can write a custom Field using custom IndexFieldType, but when the 
> DefaultIndexingChain converts [IndexFieldType to 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java#L662],
>  only few key informations such as indexing options and doc value type are 
> retained. The [Codec gets the 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/DocValuesConsumer.java#L90],
>  but not the type details.
>   
>  FieldInfo has support for ['attributes'| 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L47]
>  and it would be great if we can add 'attributes' to IndexFieldType also and 
> copy it to FieldInfo's 'attribute'.
>   
>  This would allow someone to write a custom codec (extending docvalueformat 
> for example) for only the 'special field' that he wants and delegate the rest 
> of the fields to the default codec.



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

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

Re: Feature: Solr implicitly defined field types?

[Shawn Heisey]

I'm jumping into this conversation a little bit late.  Sorry for any 
problems that causes.


On 1/4/2019 9:52 AM, Alexandre Rafalovitch wrote:

What about if a system schema was loaded at a startup implicitly.
Then, if a new schema is loaded and type definition is missing, it is
copied - at that time - into the specific schema. So, on the first
rewrite those - and only those used - types will be written out.


Looking at what came before, my preference would have been implicitly 
defined default types -- things like int, string, etc, defined in code.  
The only problem with that comes at Solr upgrade time ... what if we 
decide for a later version (even if it's limited to a major release) 
that IntPointField shouldn't be the implicit class for "int"?  Someone 
who upgrades an index using that implicit type to the new version will 
find that Solr will no longer work.  Which makes the idea unworkable.


A file-based system schema where implicit types are explicitly defined 
is an interesting idea that I think would get around the problem 
described above.  We would need to decide exactly what can be defined in 
the system schema -- my initial bias would be to only allow types, not 
fields or other schema config, to be defined there.  Probably a good 
location for the system schema file would be the ZK chroot or the solr 
home, depending on whether the system is in cloud mode.


Thanks,
Shawn


-
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-Windows (64bit/jdk-12-ea+23) - Build # 940 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/940/
Java: 64bit/jdk-12-ea+23 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([D29E77CFDE112EF1]:0)


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

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([D29E77CFDE112EF1]:0)




Build Log:
[...truncated 15577 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest
   [junit4]   2> 1060864 INFO  
(SUITE-ChaosMonkeyNothingIsSafeWithPullReplicasTest-seed#[D29E77CFDE112EF1]-worker)
 [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest_D29E77CFDE112EF1-001\init-core-data-001
   [junit4]   2> 1060865 INFO  
(SUITE-ChaosMonkeyNothingIsSafeWithPullReplicasTest-seed#[D29E77CFDE112EF1]-worker)
 [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 1060868 INFO  
(SUITE-ChaosMonkeyNothingIsSafeWithPullReplicasTest-seed#[D29E77CFDE112EF1]-worker)
 [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl="https://issues.apache.org/jira/browse/SOLR-5776;)
   [junit4]   2> 1060868 INFO  
(SUITE-ChaosMonkeyNothingIsSafeWithPullReplicasTest-seed#[D29E77CFDE112EF1]-worker)
 [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system 
property: /
   [junit4]   2> 1060869 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ChaosMonkeyNothingIsSafeWithPullReplicasTest Starting 
ChaosMonkey test with 1 shards and 3 nodes
   [junit4]   2> 1060874 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1060874 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1060874 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 1060981 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer start zk server on port:58465
   [junit4]   2> 1060981 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:58465
   [junit4]   2> 1060981 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer connecting to 127.0.0.1 58465
   [junit4]   2> 1060986 INFO  (zkConnectionManagerCallback-7615-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1060991 INFO  (zkConnectionManagerCallback-7617-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1060992 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer put 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1060994 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer put 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1060996 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer put 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1060998 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer put 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1061000 INFO  
(TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[D29E77CFDE112EF1])
 [] o.a.s.c.ZkTestServer put 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to 

[GitHub] lucene-solr pull request #525: LUCENE-8585: Index-time jump-tables for DocVa...

[jpountz]

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

https://github.com/apache/lucene-solr/pull/525#discussion_r245364034
  
--- Diff: 
lucene/core/src/java/org/apache/lucene/codecs/lucene80/IndexedDISI.java ---
@@ -0,0 +1,601 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.codecs.lucene80;
+
+import java.io.DataInput;
+import java.io.IOException;
+
+import org.apache.lucene.search.DocIdSetIterator;
+import org.apache.lucene.store.IndexInput;
+import org.apache.lucene.store.IndexOutput;
+import org.apache.lucene.store.RandomAccessInput;
+import org.apache.lucene.util.ArrayUtil;
+import org.apache.lucene.util.BitSetIterator;
+import org.apache.lucene.util.FixedBitSet;
+import org.apache.lucene.util.RoaringDocIdSet;
+
+/**
+ * Disk-based implementation of a {@link DocIdSetIterator} which can return
+ * the index of the current document, i.e. the ordinal of the current 
document
+ * among the list of documents that this iterator can return. This is 
useful
+ * to implement sparse doc values by only having to encode values for 
documents
+ * that actually have a value.
+ * Implementation-wise, this {@link DocIdSetIterator} is inspired of
+ * {@link RoaringDocIdSet roaring bitmaps} and encodes ranges of {@code 
65536}
+ * documents independently and picks between 3 encodings depending on the
+ * density of the range:
+ *   {@code ALL} if the range contains 65536 documents exactly,
+ *   {@code DENSE} if the range contains 4096 documents or more; in 
that
+ *   case documents are stored in a bit set,
+ *   {@code SPARSE} otherwise, and the lower 16 bits of the doc IDs are
+ *   stored in a {@link DataInput#readShort() short}.
+ * 
+ * Only ranges that contain at least one value are encoded.
+ * This implementation uses 6 bytes per document in the worst-case, 
which happens
+ * in the case that all ranges contain exactly one document.
+ *
+ * 
+ * To avoid O(n) lookup time complexity, with n being the number of 
documents, two lookup
+ * tables are used: A lookup table for block offset and index, and a rank 
structure
+ * for DENSE block index lookups.
+ *
+ * The lookup table is an array of {@code int}-pairs, with a pair for each 
block. It allows for
+ * direct jumping to the block, as opposed to iteration from the current 
position and forward
+ * one block at a time.
+ *
+ * Each int-pair entry consists of 2 logical parts:
+ *
+ * The first 32 bit int holds the index (number of set bits in the blocks) 
up to just before the
+ * wanted block. The maximum number of set bits is the maximum number of 
documents, which is < 2^31.
+ *
+ * The next int holds the offset in bytes into the underlying slice. As 
there is a maximum of 2^16
+ * blocks, it follows that the maximum size of any block must not exceed 
2^15 bytes to avoid
+ * overflow (2^16 bytes if the int is treated as unsigned). This is 
currently the case, with the
+ * largest block being DENSE and using 2^13 + 36 bytes.
+ *
+ * The cache overhead is numDocs/1024 bytes.
+ *
+ * Note: There are 4 types of blocks: ALL, DENSE, SPARSE and non-existing 
(0 set bits).
+ * In the case of non-existing blocks, the entry in the lookup table has 
index equal to the
+ * previous entry and offset equal to the next non-empty block.
+ *
+ * The block lookup table is stored at the end of the total block 
structure.
+ *
+ *
+ * The rank structure for DENSE blocks is an array of byte-pairs with an 
entry for each
+ * sub-block (default 512 bits) out of the 65536 bits in the outer DENSE 
block.
+ *
+ * Each rank-entry states the number of set bits within the block up to 
the bit before the
+ * bit positioned at the start of the sub-block.
+ * Note that that the rank entry of the first sub-block is always 0 and 
that the last entry can
+ * at most be 65536-2 = 65634 and thus will always fit into an byte-pair 
of 16 bits.
+ *

Re: Feature: Solr implicitly defined field types?

[Alexandre Rafalovitch]

What about if a system schema was loaded at a startup implicitly.
Then, if a new schema is loaded and type definition is missing, it is
copied - at that time - into the specific schema. So, on the first
rewrite those - and only those used - types will be written out.

This allows to version the system types the same way as we version
normal schema. I agree with Gus that hidden configuration causes all
sorts of challenges.

And - for tooling purposes - there definitely needs to be a way to get
all used definitions, explicit and implicit, used and just available.
That also points towards something that already has self-describing
mechanism (like Schema API) available.

Regards,
   Alex.


On Fri, 4 Jan 2019 at 10:45, David Smiley  wrote:
>
> I'm thinking this feature would be used conservatively -- and thus just 
> primitive types that wouldn't have an interesting configuration to them, or 
> for something you are really not expected to change (the nest path of nested 
> docs).  So you wouldn't feel you had to go read the docs.  The schema might 
> even have a comment to mention a list of implicit field types (a one-liner 
> comma delimited list).
>
> On Fri, Jan 4, 2019 at 10:34 AM Gus Heck  wrote:
>>
>> I'm perhaps slightly conservative with respect to configuration, but I'm not 
>> fond of hidden configuration that I can't see. What I don't like is looking 
>> at a config file and not seeing the full story. That means i have to read 
>> the config and ALSO go read some part of the documentation that I've failed 
>> to memorize, and probably need to google to find to be fully aware of what's 
>> going on  (and no I didn't like it when some standard stuff disappeared 
>> from solrconfig.xml a while back either). Small changes of course seem 
>> reasonable, but the further we drift into implicit things, especially if we 
>> get a collection of several implicit things described in various disparate 
>> parts of the manual the more cryptic the system becomes. That's my opinion, 
>> YMMV.
>>
>> -Gus
>>
>> On Thu, Jan 3, 2019 at 2:57 PM David Smiley  wrote:
>>>
>>> Broadly, you refer to "locale" issues.  Solr's way of dealing with this 
>>> today is with optional & configurable use of URPs.  The schema-less / 
>>> data-driven mode has some of these enabled; you can see it in the 
>>> solrconfig.xml including many date formats.  You can look into that for 
>>> further info if you like.  The primitive field types are not locale 
>>> sensitive.
>>>
>>> Update: It's looking like 8.0 will only employ this implicit field type 
>>> mechanism for _nest_path_ which probably won't be in the default schema.  
>>> Assuming it isn't, then it'll only be documented in the context of this 
>>> particular feature.  It'd be nice to see the scope of fields expanded and 
>>> at that juncture it could/should be more broadly documented.  That can wait 
>>> to people have energy to do it.
>>>
>>> On Sun, Dec 30, 2018 at 4:54 AM Jörn Franke  wrote:

 Hi David,

 I now get the idea and yes this makes sense. It would require though some 
 tutorial or best practices, eg overriding a platform data type may make 
 not so much sense - it may confuse new developers in an existing project 
 that know Solr, but then get a platform type that has not the default 
 behavior.

 Could you deal with different languages in platform types? Eg for dates it 
 does not seem a problem, because Solr expects only one specific type of 
 date that needs to be somehow converted beforehand (maybe that conversion 
 could be also part of a platform type), but decimals are different in some 
 languages or Boolean values.

 Am 30.12.2018 um 07:01 schrieb David Smiley :

 Thanks for your thoughtful response Jörn!
 ...
 On Sat, Dec 29, 2018 at 4:14 AM Jörn Franke  wrote:
>
> I think it is a good idea, but I see some potential complexity for 
> “deployment” of collections. For instance, in environments where Solr is 
> used as a shared platform amongst several stakeholders, every time you 
> deploy/modify a collection you need to take care that the platform types 
> exist. If it exists in the Test environment then i need to make sure that 
> it exists as well in acceptance/production. The problem is that the 
> platform type could have been defined by somebody else who has not yet 
> (eg due to project/sprint delays) not updated the other environments. 
> Another issue is if I move to another Solr cluster in the same 
> environment. Then, I have to make sure that all platform types move with 
> me.


 RE "the platform type could have been defined by somebody else":  I'm not 
 imagining it'd be configurable, thus the "somebody else" is the Solr 
 project/committers.

 Otherwise, I think I get your point, but perhaps I don't.  It's the same 
 point for any use of some new feature of Solr.  If you use some new 

[jira] [Commented] (SOLR-13116) Add Admin UI login support for Kerberos

[JIRA]

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

Jan Høydahl commented on SOLR-13116:


I have not used Kerberos with Solr. How does this work today? Is it so that 
whenever user is logged in, the users Web Browser will present the ticket to 
Admin UI and thus avoid HTTP 401? If so, then we can close this right away, 
since the Login screen of the Admin UI will never be triggered. That is, unless 
some feature in the Admin UI requires more permission than the current user's 
Kerberos ticket allows, then I guess there might be some situation?

Can someone with a Kerberized Solr please test and report?

> Add Admin UI login support for Kerberos
> ---
>
> Key: SOLR-13116
> URL: https://issues.apache.org/jira/browse/SOLR-13116
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (8.0), 7.7
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-7896. Kerberos auth plugin should get Admin UI Login 
> support.



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

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

Re: Solr Size Limitation upto 32 kb limitation

[Erick Erickson]

First off, the field in question is "FileContent", why do you think
the filed "text" is the problem?
Try switching FileContent to a text-based type.

If that's not the case, depending on the tokenizer and the input you
_still_ may
have an immense term even if you have a text-based field. For example, the
data could be something like base64 encoded, which has no spaces and you
are using a tokenizer that only breaks on whitespace.

You simply have got to look at the input data to make sense of the problem

Best,
Erick

On Fri, Jan 4, 2019 at 3:32 AM Kranthi Kumar K
 wrote:
>
> Hi team,
>
>
>
> We are currently using Solr 4.2.1 version in our project and everything is 
> going well. But recently, we are facing an issue with Solr Data Import. It is 
> not importing the files with size greater than 32766 bytes (i.e, 32 kb) and 
> showing 2 exceptions:
>
>
>
> java.lang.illegalargumentexception
> org.apache.lucene.util.bytesref hash$maxbyteslengthexceededexception
>
>
>
> Please find the attached screenshot for reference.
>
>
>
> We have searched for solutions in many forums and didn’t find the exact 
> solution for this issue. Interestingly, we found in the article, by changing 
> the type of the ‘field’ from sting to  ‘text_general’ might solve the issue. 
> Please have a look in the below forum:
>
>
>
> https://stackoverflow.com/questions/29445323/adding-a-document-to-the-index-in-solr-document-contains-at-least-one-immense-t
>
>
>
> Schema.xml:
>
> Changed from:
>
> ‘ multiValued="true" />’
>
>
>
> Changed to:
>
> ‘ multiValued="true" />’
>
>
>
> We have tried it but still it is not importing the files > 32 KB or 32766 
> bytes.
>
>
>
> Could you please let us know the solution to fix this issue? We’ll be 
> awaiting your reply.
>
>
>
> -
> 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

Re: Feature: Solr implicitly defined field types?

[David Smiley]

I'm thinking this feature would be used conservatively -- and thus just
primitive types that wouldn't have an interesting configuration to them, or
for something you are really not expected to change (the nest path of
nested docs).  So you wouldn't feel you had to go read the docs.  The
schema might even have a comment to mention a list of implicit field types
(a one-liner comma delimited list).

On Fri, Jan 4, 2019 at 10:34 AM Gus Heck  wrote:

> I'm perhaps slightly conservative with respect to configuration, but I'm
> not fond of hidden configuration that I can't see. What I don't like is
> looking at a config file and not seeing the full story. That means i have
> to read the config and ALSO go read some part of the documentation that
> I've failed to memorize, and probably need to google to find to be fully
> aware of what's going on  (and no I didn't like it when some standard
> stuff disappeared from solrconfig.xml a while back either). Small changes
> of course seem reasonable, but the further we drift into implicit things,
> especially if we get a collection of several implicit things described in
> various disparate parts of the manual the more cryptic the system becomes.
> That's my opinion, YMMV.
>
> -Gus
>
> On Thu, Jan 3, 2019 at 2:57 PM David Smiley 
> wrote:
>
>> Broadly, you refer to "locale" issues.  Solr's way of dealing with this
>> today is with optional & configurable use of URPs.  The schema-less /
>> data-driven mode has some of these enabled; you can see it in the
>> solrconfig.xml including many date formats.  You can look into that for
>> further info if you like.  The primitive field types are not locale
>> sensitive.
>>
>> Update: It's looking like 8.0 will only employ this implicit field type
>> mechanism for _nest_path_ which probably won't be in the default schema.
>> Assuming it isn't, then it'll only be documented in the context of this
>> particular feature.  It'd be nice to see the scope of fields expanded and
>> at that juncture it could/should be more broadly documented.  That can wait
>> to people have energy to do it.
>>
>> On Sun, Dec 30, 2018 at 4:54 AM Jörn Franke  wrote:
>>
>>> Hi David,
>>>
>>> I now get the idea and yes this makes sense. It would require though
>>> some tutorial or best practices, eg overriding a platform data type may
>>> make not so much sense - it may confuse new developers in an existing
>>> project that know Solr, but then get a platform type that has not the
>>> default behavior.
>>>
>>> Could you deal with different languages in platform types? Eg for dates
>>> it does not seem a problem, because Solr expects only one specific type of
>>> date that needs to be somehow converted beforehand (maybe that conversion
>>> could be also part of a platform type), but decimals are different in some
>>> languages or Boolean values.
>>>
>>> Am 30.12.2018 um 07:01 schrieb David Smiley :
>>>
>>> Thanks for your thoughtful response Jörn!
>>> ...
>>> On Sat, Dec 29, 2018 at 4:14 AM Jörn Franke 
>>> wrote:
>>>
 I think it is a good idea, but I see some potential complexity for
 “deployment” of collections. For instance, in environments where Solr is
 used as a shared platform amongst several stakeholders, every time you
 deploy/modify a collection you need to take care that the platform types
 exist. If it exists in the Test environment then i need to make sure that
 it exists as well in acceptance/production. The problem is that the
 platform type could have been defined by somebody else who has not yet (eg
 due to project/sprint delays) not updated the other environments. Another
 issue is if I move to another Solr cluster in the same environment. Then, I
 have to make sure that all platform types move with me.

>>>
>>> RE "the platform type could have been defined by somebody else":  I'm
>>> not imagining it'd be configurable, thus the "somebody else" is the Solr
>>> project/committers.
>>>
>>> Otherwise, I think I get your point, but perhaps I don't.  It's the same
>>> point for *any* use of some new feature of Solr.  If you use some new
>>> feature, you have to take care that all Solr instances you deploy your
>>> configuration to can handle that new feature.  That's a fairly generic
>>> point that would apply to just about anything in Solr.
>>>
>>>
 A (minor) issue is that platform types may change (for whatever
 reasons) and that then potentially all collections have to be reindexed or
 we have different versions of the same platform type making things not
 easier.

>>>
>>> Yes it's possible.  Though I think that point is apart from the feature
>>> I propose.  You're saying that you might want to use an "int" field and
>>> then one day realize you want some newer/better definition of what an "int"
>>> is (e.g. trie -> points).  Sure.  That's true wether the field type is
>>> explicit or implicit.  There's nothing stopping you from explicitly
>>> defining the field type if you 

Re: Feature: Solr implicitly defined field types?

[Gus Heck]

I'm perhaps slightly conservative with respect to configuration, but I'm
not fond of hidden configuration that I can't see. What I don't like is
looking at a config file and not seeing the full story. That means i have
to read the config and ALSO go read some part of the documentation that
I've failed to memorize, and probably need to google to find to be fully
aware of what's going on  (and no I didn't like it when some standard
stuff disappeared from solrconfig.xml a while back either). Small changes
of course seem reasonable, but the further we drift into implicit things,
especially if we get a collection of several implicit things described in
various disparate parts of the manual the more cryptic the system becomes.
That's my opinion, YMMV.

-Gus

On Thu, Jan 3, 2019 at 2:57 PM David Smiley 
wrote:

> Broadly, you refer to "locale" issues.  Solr's way of dealing with this
> today is with optional & configurable use of URPs.  The schema-less /
> data-driven mode has some of these enabled; you can see it in the
> solrconfig.xml including many date formats.  You can look into that for
> further info if you like.  The primitive field types are not locale
> sensitive.
>
> Update: It's looking like 8.0 will only employ this implicit field type
> mechanism for _nest_path_ which probably won't be in the default schema.
> Assuming it isn't, then it'll only be documented in the context of this
> particular feature.  It'd be nice to see the scope of fields expanded and
> at that juncture it could/should be more broadly documented.  That can wait
> to people have energy to do it.
>
> On Sun, Dec 30, 2018 at 4:54 AM Jörn Franke  wrote:
>
>> Hi David,
>>
>> I now get the idea and yes this makes sense. It would require though some
>> tutorial or best practices, eg overriding a platform data type may make not
>> so much sense - it may confuse new developers in an existing project that
>> know Solr, but then get a platform type that has not the default behavior.
>>
>> Could you deal with different languages in platform types? Eg for dates
>> it does not seem a problem, because Solr expects only one specific type of
>> date that needs to be somehow converted beforehand (maybe that conversion
>> could be also part of a platform type), but decimals are different in some
>> languages or Boolean values.
>>
>> Am 30.12.2018 um 07:01 schrieb David Smiley :
>>
>> Thanks for your thoughtful response Jörn!
>> ...
>> On Sat, Dec 29, 2018 at 4:14 AM Jörn Franke  wrote:
>>
>>> I think it is a good idea, but I see some potential complexity for
>>> “deployment” of collections. For instance, in environments where Solr is
>>> used as a shared platform amongst several stakeholders, every time you
>>> deploy/modify a collection you need to take care that the platform types
>>> exist. If it exists in the Test environment then i need to make sure that
>>> it exists as well in acceptance/production. The problem is that the
>>> platform type could have been defined by somebody else who has not yet (eg
>>> due to project/sprint delays) not updated the other environments. Another
>>> issue is if I move to another Solr cluster in the same environment. Then, I
>>> have to make sure that all platform types move with me.
>>>
>>
>> RE "the platform type could have been defined by somebody else":  I'm not
>> imagining it'd be configurable, thus the "somebody else" is the Solr
>> project/committers.
>>
>> Otherwise, I think I get your point, but perhaps I don't.  It's the same
>> point for *any* use of some new feature of Solr.  If you use some new
>> feature, you have to take care that all Solr instances you deploy your
>> configuration to can handle that new feature.  That's a fairly generic
>> point that would apply to just about anything in Solr.
>>
>>
>>> A (minor) issue is that platform types may change (for whatever reasons)
>>> and that then potentially all collections have to be reindexed or we have
>>> different versions of the same platform type making things not easier.
>>>
>>
>> Yes it's possible.  Though I think that point is apart from the feature I
>> propose.  You're saying that you might want to use an "int" field and then
>> one day realize you want some newer/better definition of what an "int" is
>> (e.g. trie -> points).  Sure.  That's true wether the field type is
>> explicit or implicit.  There's nothing stopping you from explicitly
>> defining the field type if you want to; the names would not be reserved. If
>> you want to stick with your current index running the new Solr version,
>> then you would keep luceneMatchVersion what it was, which would effectively
>> retain the interpretation of the implicit field types.
>>
>>
>>> Currently we have all our Schema definitions in a version management
>>> system (we use the Schema API but the JSON requests are out there) so that
>>> projects can inspire from each other. Needless to say, that careful type
>>> engineering requires also some documentation on technical design and 

[jira] [Commented] (SOLR-13090) Make maxBooleanClauses support system-property override

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13090:


Commit 73797f60ada12aa2a09180947d4bdf556a234fea in lucene-solr's branch 
refs/heads/master from Jason Gerlowski
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=73797f6 ]

SOLR-13090: Add missing CHANGES.txt entry


> Make maxBooleanClauses support system-property override
> ---
>
> Key: SOLR-13090
> URL: https://issues.apache.org/jira/browse/SOLR-13090
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (8.0), 7.7
>Reporter: Jason Gerlowski
>Assignee: Jason Gerlowski
>Priority: Minor
> Fix For: master (8.0), 7.7
>
> Attachments: SOLR-13090.patch
>
>
> Currently, the {{maxBooleanClauses}} property is specified in most 
> solrconfig's as the hardcoded value "1024".  It'd be nice if we changed our 
> shipped configs so that they instead specified it as 
> {{${solr.max.booleanClauses:1024} This would maintain the current OOTB behavior (maxBooleanClauses would still 
> default to 1024) while adding the ability to update maxBooleanClauses values 
> across the board much more easily.  (I see users want to do this often when 
> they first run up against this limit.)



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

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

[jira] [Comment Edited] (SOLR-7896) Add a login page for Solr Administrative Interface

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-7896 at 1/4/19 2:49 PM:
-

bq. If the user opens a page or attempts an action that requires 
authentication, then the login screen is presented with a message from whatever 
Auth plugin is active. I guess this will look like a dead end, as the only menu 
option will be "Login" at this point. But opening a new browser tab will bring 
back the full UI. But opening a new browser tab will bring back the full UI.

I'm confused about the last sentence there. I don't quite understand how 
opening a new browser tab bypasses the login screen?

I know, I should try it and see for myself, but I have a long list of other 
things vying for my time.


was (Author: ctargett):
bq. If the user opens a page or attempts an action that requires 
authentication, then the login screen is presented with a message from whatever 
Auth plugin is active. I guess this will look like a dead end, as the only menu 
option will be "Login" at this point. But opening a new browser tab will bring 
back the full UI. But opening a new browser tab will bring back the full UI.

I'm confused about the last sentence there. I don't quite understand how 
opening a new browser tab bypasses the login screen?

> Add a login page for Solr Administrative Interface
> --
>
> Key: SOLR-7896
> URL: https://issues.apache.org/jira/browse/SOLR-7896
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, Authentication, security
>Affects Versions: 5.2.1
>Reporter: Aaron Greenspan
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: authentication, login, password
> Fix For: master (8.0), 7.7
>
> Attachments: dispatchfilter-code.png, login-page.png, 
> login-screen-2.png, logout.png, unknown_scheme.png
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Now that Solr supports Authentication plugins, the missing piece is to be 
> allowed access from Admin UI when authentication is enabled. For this we need
>  * Some plumbing in Admin UI that allows the UI to detect 401 responses and 
> redirect to login page
>  * Possibility to have multiple login pages depending on auth method and 
> redirect to the correct one
>  * [AngularJS HTTP 
> interceptors|https://docs.angularjs.org/api/ng/service/$http#interceptors] to 
> add correct HTTP headers on all requests when user is logged in
> This issue should aim to implement some of the plumbing mentioned above, and 
> make it work with Basic Auth.



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

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

[jira] [Commented] (SOLR-7896) Add a login page for Solr Administrative Interface

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-7896:
-

bq. If the user opens a page or attempts an action that requires 
authentication, then the login screen is presented with a message from whatever 
Auth plugin is active. I guess this will look like a dead end, as the only menu 
option will be "Login" at this point. But opening a new browser tab will bring 
back the full UI. But opening a new browser tab will bring back the full UI.

I'm confused about the last sentence there. I don't quite understand how 
opening a new browser tab bypasses the login screen?

> Add a login page for Solr Administrative Interface
> --
>
> Key: SOLR-7896
> URL: https://issues.apache.org/jira/browse/SOLR-7896
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, Authentication, security
>Affects Versions: 5.2.1
>Reporter: Aaron Greenspan
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: authentication, login, password
> Fix For: master (8.0), 7.7
>
> Attachments: dispatchfilter-code.png, login-page.png, 
> login-screen-2.png, logout.png, unknown_scheme.png
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Now that Solr supports Authentication plugins, the missing piece is to be 
> allowed access from Admin UI when authentication is enabled. For this we need
>  * Some plumbing in Admin UI that allows the UI to detect 401 responses and 
> redirect to login page
>  * Possibility to have multiple login pages depending on auth method and 
> redirect to the correct one
>  * [AngularJS HTTP 
> interceptors|https://docs.angularjs.org/api/ng/service/$http#interceptors] to 
> add correct HTTP headers on all requests when user is logged in
> This issue should aim to implement some of the plumbing mentioned above, and 
> make it work with Basic Auth.



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

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

[jira] [Commented] (SOLR-7896) Add a login page for Solr Administrative Interface

[JIRA]

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

Jan Høydahl commented on SOLR-7896:
---

{quote}I'm confused about the last sentence there. I don't quite understand how 
opening a new browser tab bypasses the login screen?
{quote}
Well, technically, the UI is fully functional until the first time an Ajax 
request to Solr results in a HTTP 401 response. Once that happens, it brings up 
the "Login" menu option and gets stuck in login mode, and there is no way to 
get back without logging in. But the 401 state is kept in a SessionStore 
variable, so once you try in a new browser tab, it won't remember the 401 state 
until you attempt some restricted operation again.

An improvement could be to always display the "Dashboard" menu option and when 
clicking it we'd automatically reset the http401 flag. That would give you an 
exit from the login screen. But of course, if your auth protects even the 
/admin/info/system call then you'd just be thrown right back to the login panel 
every time...

> Add a login page for Solr Administrative Interface
> --
>
> Key: SOLR-7896
> URL: https://issues.apache.org/jira/browse/SOLR-7896
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, Authentication, security
>Affects Versions: 5.2.1
>Reporter: Aaron Greenspan
>Assignee: Jan Høydahl
>Priority: Major
>  Labels: authentication, login, password
> Fix For: master (8.0), 7.7
>
> Attachments: dispatchfilter-code.png, login-page.png, 
> login-screen-2.png, logout.png, unknown_scheme.png
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Now that Solr supports Authentication plugins, the missing piece is to be 
> allowed access from Admin UI when authentication is enabled. For this we need
>  * Some plumbing in Admin UI that allows the UI to detect 401 responses and 
> redirect to login page
>  * Possibility to have multiple login pages depending on auth method and 
> redirect to the correct one
>  * [AngularJS HTTP 
> interceptors|https://docs.angularjs.org/api/ng/service/$http#interceptors] to 
> add correct HTTP headers on all requests when user is logged in
> This issue should aim to implement some of the plumbing mentioned above, and 
> make it work with Basic Auth.



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

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

[jira] [Commented] (SOLR-13116) Add Admin UI login support for Kerberos

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13116:
--

The description for this issue isn't exactly incorrect, but it possibly 
understates the need here.

When using Kerberos one does not "login" anywhere. One either has a valid 
ticket or one doesn't and access to the Admin UI is granted based on the 
validity of the ticket without any user input. The need is that the login page 
not be presented when a user has a valid ticket.

With the current login page implementation, it seems that a Kerberos-secured 
Solr will present a user with an error instead of properly granting access 
according to whatever authz rules have been put in place.

> Add Admin UI login support for Kerberos
> ---
>
> Key: SOLR-13116
> URL: https://issues.apache.org/jira/browse/SOLR-13116
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: master (8.0), 7.7
>Reporter: Jan Høydahl
>Priority: Major
>
> Spinoff from SOLR-7896. Kerberos auth plugin should get Admin UI Login 
> support.



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

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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10.0.1) - Build # 7676 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7676/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 2096 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J1-20190104_131101_4956603580940051438220.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 5 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J0-20190104_131101_4966050782587001716534.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 322 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J0-20190104_131851_36317828251495600986995.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J1-20190104_131851_36310248802702225795867.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 1081 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J0-20190104_132006_3301812777510369952134.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J1-20190104_132006_33013549876195576090076.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 257 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J0-20190104_132230_87917180815161153284474.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J1-20190104_132230_879827510122896441486.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 245 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\kuromoji\test\temp\junit4-J1-20190104_132242_7295690301553583352337.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 12 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\kuromoji\test\temp\junit4-J0-20190104_132242_72914322272502343248216.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 163 lines...]
   [junit4] JVM J0: stderr was not empty, see: 

[jira] [Commented] (LUCENE-8622) Add a MinimumShouldMatch interval iterator

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8622:
---

Thanks for the review [~dsmiley]! Have updated the patch accordingly.

> Add a MinimumShouldMatch interval iterator
> --
>
> Key: LUCENE-8622
> URL: https://issues.apache.org/jira/browse/LUCENE-8622
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8622.patch, LUCENE-8622.patch, LUCENE-8622.patch
>
>
> It would be useful to be able to search for intervals that span some subgroup 
> of a set of iterators, allowing us to build a 'some of ' or 'at least' 
> operator - ie, search for terms that appear near at least 3 of a list of 5 
> terms.



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

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

[jira] [Updated] (LUCENE-8622) Add a MinimumShouldMatch interval iterator

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8622:
--
Attachment: LUCENE-8622.patch

> Add a MinimumShouldMatch interval iterator
> --
>
> Key: LUCENE-8622
> URL: https://issues.apache.org/jira/browse/LUCENE-8622
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8622.patch, LUCENE-8622.patch, LUCENE-8622.patch
>
>
> It would be useful to be able to search for intervals that span some subgroup 
> of a set of iterators, allowing us to build a 'some of ' or 'at least' 
> operator - ie, search for terms that appear near at least 3 of a list of 5 
> terms.



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

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

[jira] [Commented] (LUCENE-8622) Add a MinimumShouldMatch interval iterator

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8622:
--

Cool algorithms here.
Can you please rename CacheingMatchesIterator to CachingMatchesIterator  (drop 
the first 'e')
A comment referred to "phrasequeue" but I think "proximityQueue" is more 
correct.

> Add a MinimumShouldMatch interval iterator
> --
>
> Key: LUCENE-8622
> URL: https://issues.apache.org/jira/browse/LUCENE-8622
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8622.patch, LUCENE-8622.patch
>
>
> It would be useful to be able to search for intervals that span some subgroup 
> of a set of iterators, allowing us to build a 'some of ' or 'at least' 
> operator - ie, search for terms that appear near at least 3 of a list of 5 
> terms.



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

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 1186 - Unstable

[Apache Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: Could not get expected value  
'org.apache.solr.core.BlobStoreTestRequestHandler' for path 
'overlay/requestHandler/\/test1/class' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "overlay":{
"znodeVersion":0,
"runtimeLib":{"colltest":{
"name":"colltest",
"version":1,  from server:  null
at 
__randomizedtesting.SeedInfo.seed([A6F39AE2C0D7A026:7EBEB7B5370A0586]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:590)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:80)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1063)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1035)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8601) Adding attributes to IndexFieldType

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8601:


Thanks [~muralikpbhat] – I'll review and push to 7.x!

> Adding attributes to IndexFieldType
> ---
>
> Key: LUCENE-8601
> URL: https://issues.apache.org/jira/browse/LUCENE-8601
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 7.5
>Reporter: Murali Krishna P
>Priority: Major
> Attachments: 7x_LUCENE-8601.06.patch, LUCENE-8601.01.patch, 
> LUCENE-8601.02.patch, LUCENE-8601.03.patch, LUCENE-8601.04.patch, 
> LUCENE-8601.05.patch, LUCENE-8601.06.patch, LUCENE-8601.patch
>
>
> Today, we can write a custom Field using custom IndexFieldType, but when the 
> DefaultIndexingChain converts [IndexFieldType to 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java#L662],
>  only few key informations such as indexing options and doc value type are 
> retained. The [Codec gets the 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/DocValuesConsumer.java#L90],
>  but not the type details.
>   
>  FieldInfo has support for ['attributes'| 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L47]
>  and it would be great if we can add 'attributes' to IndexFieldType also and 
> copy it to FieldInfo's 'attribute'.
>   
>  This would allow someone to write a custom codec (extending docvalueformat 
> for example) for only the 'special field' that he wants and delegate the rest 
> of the fields to the default codec.



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

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

[jira] [Commented] (LUCENE-8622) Add a MinimumShouldMatch interval iterator

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8622:
---

New patch, bringing things up to date with master

> Add a MinimumShouldMatch interval iterator
> --
>
> Key: LUCENE-8622
> URL: https://issues.apache.org/jira/browse/LUCENE-8622
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8622.patch, LUCENE-8622.patch
>
>
> It would be useful to be able to search for intervals that span some subgroup 
> of a set of iterators, allowing us to build a 'some of ' or 'at least' 
> operator - ie, search for terms that appear near at least 3 of a list of 5 
> terms.



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

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

[jira] [Updated] (LUCENE-8622) Add a MinimumShouldMatch interval iterator

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8622:
--
Attachment: LUCENE-8622.patch

> Add a MinimumShouldMatch interval iterator
> --
>
> Key: LUCENE-8622
> URL: https://issues.apache.org/jira/browse/LUCENE-8622
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8622.patch, LUCENE-8622.patch
>
>
> It would be useful to be able to search for intervals that span some subgroup 
> of a set of iterators, allowing us to build a 'some of ' or 'at least' 
> operator - ie, search for terms that appear near at least 3 of a list of 5 
> terms.



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

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

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11126:
-

Ah :( Right. Didn't fail to start for me but yes fails to create the collection 
due to the missing constructor. Patch uploaded. Added new test for checking 
collection creation. {{ant test}}, {{beasts}}, {{precommit}} pass. checked 
properly.

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11126:

Attachment: SOLR-11126.patch

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11126:

Attachment: (was: SOLR-11126.patch)

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1741 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

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([3204C11C22286DCA:BA50FEC68CD40032]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:195)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:143)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:138)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:1032)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.createAndDeleteCollection(StressHdfsTest.java:164)
at 
org.apache.solr.cloud.hdfs.StressHdfsTest.test(StressHdfsTest.java:108)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1070)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1042)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (LUCENE-8601) Adding attributes to IndexFieldType

[Murali Krishna P (JIRA)]

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

Murali Krishna P commented on LUCENE-8601:
--

Thanks [~mikemccand]. Uploaded a separate patch for 7x branch 
[^7x_LUCENE-8601.06.patch]

Regarding modifying the attribute, will open another issue as you suggested. We 
need to discuss how we should treat the scenarios if some attributes don't 
present in the subsequent update. Most of the use cases will have the 
attributes defined at the beginning itself and unlikely to change.

> Adding attributes to IndexFieldType
> ---
>
> Key: LUCENE-8601
> URL: https://issues.apache.org/jira/browse/LUCENE-8601
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 7.5
>Reporter: Murali Krishna P
>Priority: Major
> Attachments: 7x_LUCENE-8601.06.patch, LUCENE-8601.01.patch, 
> LUCENE-8601.02.patch, LUCENE-8601.03.patch, LUCENE-8601.04.patch, 
> LUCENE-8601.05.patch, LUCENE-8601.06.patch, LUCENE-8601.patch
>
>
> Today, we can write a custom Field using custom IndexFieldType, but when the 
> DefaultIndexingChain converts [IndexFieldType to 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java#L662],
>  only few key informations such as indexing options and doc value type are 
> retained. The [Codec gets the 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/DocValuesConsumer.java#L90],
>  but not the type details.
>   
>  FieldInfo has support for ['attributes'| 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L47]
>  and it would be great if we can add 'attributes' to IndexFieldType also and 
> copy it to FieldInfo's 'attribute'.
>   
>  This would allow someone to write a custom codec (extending docvalueformat 
> for example) for only the 'special field' that he wants and delegate the rest 
> of the fields to the default codec.



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

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

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11126:

Attachment: SOLR-11126.patch

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

[jira] [Updated] (LUCENE-8601) Adding attributes to IndexFieldType

[Murali Krishna P (JIRA)]

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

Murali Krishna P updated LUCENE-8601:
-
Attachment: 7x_LUCENE-8601.06.patch

> Adding attributes to IndexFieldType
> ---
>
> Key: LUCENE-8601
> URL: https://issues.apache.org/jira/browse/LUCENE-8601
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Affects Versions: 7.5
>Reporter: Murali Krishna P
>Priority: Major
> Attachments: 7x_LUCENE-8601.06.patch, LUCENE-8601.01.patch, 
> LUCENE-8601.02.patch, LUCENE-8601.03.patch, LUCENE-8601.04.patch, 
> LUCENE-8601.05.patch, LUCENE-8601.06.patch, LUCENE-8601.patch
>
>
> Today, we can write a custom Field using custom IndexFieldType, but when the 
> DefaultIndexingChain converts [IndexFieldType to 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/DefaultIndexingChain.java#L662],
>  only few key informations such as indexing options and doc value type are 
> retained. The [Codec gets the 
> FieldInfo|https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/DocValuesConsumer.java#L90],
>  but not the type details.
>   
>  FieldInfo has support for ['attributes'| 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FieldInfo.java#L47]
>  and it would be great if we can add 'attributes' to IndexFieldType also and 
> copy it to FieldInfo's 'attribute'.
>   
>  This would allow someone to write a custom codec (extending docvalueformat 
> for example) for only the 'special field' that he wants and delegate the rest 
> of the fields to the default codec.



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

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

[jira] [Updated] (LUCENE-8629) Add some more Interval functions

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8629:
--
Attachment: LUCENE-8629.patch

> Add some more Interval functions
> 
>
> Key: LUCENE-8629
> URL: https://issues.apache.org/jira/browse/LUCENE-8629
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8629.patch, LUCENE-8629.patch
>
>
> There are a few missing functions from the current group of IntervalsSource 
> definitions available:
> * a BEFORE/AFTER b - similar to an ordered near, but returning only intervals 
> from 'a' rather than an interval spanning both a and b
> * a WITHIN b - inverse of the already available NOT_WITHIN
> * a OVERLAPPING b - inverse of the already available NOT_OVERLAPPING



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

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

[jira] [Commented] (LUCENE-8629) Add some more Interval functions

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8629:
---

Actual working patch attached this time...

> Add some more Interval functions
> 
>
> Key: LUCENE-8629
> URL: https://issues.apache.org/jira/browse/LUCENE-8629
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8629.patch, LUCENE-8629.patch
>
>
> There are a few missing functions from the current group of IntervalsSource 
> definitions available:
> * a BEFORE/AFTER b - similar to an ordered near, but returning only intervals 
> from 'a' rather than an interval spanning both a and b
> * a WITHIN b - inverse of the already available NOT_WITHIN
> * a OVERLAPPING b - inverse of the already available NOT_OVERLAPPING



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

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

JDK 12 Early Access build 26 & JDK 13 Early Access builds available

[Rory O'Donnell]

Hi Uwe & Dawid,

Happy New Year!

*OpenJDK builds *- JDK 12 Early Access build 26 is available at 
http://jdk.java.net/12/


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes since last email
 o Distrust TLS server certificates anchored by Symantec Root CAs
   (JDK-8207258 )
 o Customizing the generation of a PKCS12 keystore (JDK-8076190
   )
 o Compact Number Formatting Support (JDK-8177552
   )

*OpenJDK builds *- JDK 13 - Early Access build 2 is available at 
http://jdk.java.net/13/


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Changes in this build
   


*jpackage EA builds*

 * This is an early access build of JEP 343: Packaging Tool
   , aimed at testing a prototype
   implementation of jpackage, which is a new tool for packaging
   self-contained Java applications along with a Java Runtime Environment.
 * Please send feedback via e-mail to core-libs-...@openjdk.java.net
   

*Quality Outreach report for December 2018*

 * The report for December 2018 is available here
   


Rgds,Rory

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

[jira] [Updated] (LUCENE-8629) Add some more Interval functions

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8629:
--
Attachment: LUCENE-8629.patch

> Add some more Interval functions
> 
>
> Key: LUCENE-8629
> URL: https://issues.apache.org/jira/browse/LUCENE-8629
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8629.patch
>
>
> There are a few missing functions from the current group of IntervalsSource 
> definitions available:
> * a BEFORE/AFTER b - similar to an ordered near, but returning only intervals 
> from 'a' rather than an interval spanning both a and b
> * a WITHIN b - inverse of the already available NOT_WITHIN
> * a OVERLAPPING b - inverse of the already available NOT_OVERLAPPING



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

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

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

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11126:
--

[~sarkaramr...@gmail.com] -- Solr fails to start because each implicit request 
handler must have a default constructor and HealthCheckHandler only has one 
which accepts a CoreContainer parameter.

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

[jira] [Created] (LUCENE-8629) Add some more Interval functions

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8629:
-

 Summary: Add some more Interval functions
 Key: LUCENE-8629
 URL: https://issues.apache.org/jira/browse/LUCENE-8629
 Project: Lucene - Core
  Issue Type: Task
Reporter: Alan Woodward
Assignee: Alan Woodward


There are a few missing functions from the current group of IntervalsSource 
definitions available:
* a BEFORE/AFTER b - similar to an ordered near, but returning only intervals 
from 'a' rather than an interval spanning both a and b
* a WITHIN b - inverse of the already available NOT_WITHIN
* a OVERLAPPING b - inverse of the already available NOT_OVERLAPPING



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

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

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

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-11126:
--

This is interesting. The system, thread, logging, properties and now health are 
registered with the InfoHandler at {{/info/}} path. This InfoHandler is 
registered by default in the CoreContainer and there seems to be no way to skip 
it. However, the implicit plugins json again defines each of these sub-handlers 
directly under the {{/admin/}} path. So each of these handlers are accessibly 
through two paths. Also, because the useParams defined in the Implicit plugins 
is for {{/admin/xyz}} handler, the paramset won't be applied if the same 
handler is accessed using the {{/admin/info/xyz}} path.

[~noble.paul] - do you know why it is done this way? we may need another issue 
to clean this up in 8.0

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

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

[Apache Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.lucene.search.join.TestBlockJoin.testMultiChildQueriesOfDiffParentLevels

Error Message:
CheckIndex failed

Stack Trace:
java.lang.RuntimeException: CheckIndex failed
at 
__randomizedtesting.SeedInfo.seed([C780B77D6F043E5D:1665A8B18F92C73B]:0)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:305)
at org.apache.lucene.util.TestUtil.checkIndex(TestUtil.java:285)
at 
org.apache.lucene.store.BaseDirectoryWrapper.close(BaseDirectoryWrapper.java:45)
at 
org.apache.lucene.search.join.TestBlockJoin.testMultiChildQueriesOfDiffParentLevels(TestBlockJoin.java:1475)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testBelowSearchRate

Error Message:
[Op{action=DELETEREPLICA, hints={COLL_SHARD=[{   
"first":"belowRate_collection",   "second":"shard1"}], REPLICA=[core_node10]}}, 
Op{action=DELETEREPLICA, hints={COLL_SHARD=[{   "first":"belowRate_collection", 
  "second":"shard1"}], REPLICA=[core_node8]}}, Op{action=DELETEREPLICA, 
hints={COLL_SHARD=[{   "first":"belowRate_collection",   "second":"shard1"}], 
REPLICA=[core_node6]}}, Op{action=NONE, 
hints={SRC_NODE=[127.0.0.1:45669_solr]}}, 

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11126:
-

Thanks, Shalin, apologies you had to review multiple times. I didn't think this 
point through and moved forward with changes:

bq. The CommonParams used to have /admin/health but now has /admin/info/health. 
It is okay to change the path because this API has never been released but 
there is some inconsistency because ImplicitPlugins.json still has 
"/admin/health"

The following is mentioned in the {{ImplicitPlugins}} documentation: 

{code}
System Settings 
Return server statistics and settings.

Documentation: 
https://wiki.apache.org/solr/SystemInformationRequestHandlers#SystemInfoHandler

API Endpoints   Class & JavadocsParamset
v1: solr/admin/info/system

v2: api/node/system
{solr-javadocs}/solr-core/org/apache/solr/handler/admin/SystemInfoHandler.html[SystemInfoHandler]
_ADMIN_SYSTEM
This endpoint can also take the collection or core name in the path 
(solr//admin/system or solr//admin/system) which will include 
all of the system-level information and additional information about the 
specific core that served the request.
{code}

All the InfoHandlers are available with 
{{/solr//admin/}}; which is essentially utilized by 
SolrClient. Thus, all info endpoints are mentioned in ImplicitPlugins.json.

{code}
"/admin/plugins": {
  "class": "solr.PluginInfoHandler"
},
"/admin/threads": {
  "class": "solr.ThreadDumpHandler",
  "useParams":"_ADMIN_THREADS"
},
"/admin/properties": {
  "class": "solr.PropertiesRequestHandler",
  "useParams":"_ADMIN_PROPERTIES"
},
"/admin/logging": {
  "class": "solr.LoggingHandler",
  "useParams":"_ADMIN_LOGGING"
},
{code}

Since this endpoint is available only in Solrcloud mode, I have added another 
line in the documentation. Beasts 100 rounds run successfully, precommit pass.

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

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

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated SOLR-11126:

Attachment: SOLR-11126.patch

> 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: Shalin Shekhar Mangar
>Priority: Major
> Fix For: master (8.0)
>
> Attachments: SOLR-11126-v2.patch, SOLR-11126.patch, SOLR-11126.patch, 
> SOLR-11126.patch, SOLR-11126.patch
>
>
> 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/health (v1 API)
> * solr/node/health (v2 API)



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

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 3340 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3340/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 1966 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20190104_074736_50840730527146873137.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J0-20190104_074736_5083390363055697402965.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 5 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J2-20190104_074736_50815433119143445991064.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 301 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20190104_075341_92018046983624799424515.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20190104_075341_92017531311335831661828.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20190104_075341_92015911446238857836097.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 1080 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20190104_075501_14211314520868805094070.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20190104_075501_14215202649617869831506.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20190104_075501_1429235549634041879140.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 258 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20190104_075704_10511882567039040988641.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] Java HotSpot(TM) 64-Bit Server VM warning: Option 
UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in 
a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J1: stderr was not empty, see: