[jira] [Updated] (SOLR-9417) Allow daemons to terminate

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9417:
-
Description: 
The daemon expression currently runs until it's killed. This ticket will add a 
new *terminate* parameter to the daemon expression that will allow the daemon 
to shut itself down when it's finished processing a topic queue.

There are a couple of small changes that need to be made to allow the daemon to 
terminate on it's own:

1) The daemon will need to be passed the Map of all daemons in the /stream 
handler. This will allow the DaemonStream to remove itself from the Map when it 
terminates.
2) Logic needs to be added for the daemon to exit it's run loop if the topic 
signals it had a zero Tuple run. The *sleepMillis* value in the EOF Tuple can 
be used for this purpose. If sleepMillis is greater then 0 then this signals a 
zero Tuple run.

  was:
The daemon expression currently runs until it's killed. This ticket will add a 
new *terminate* parameter to the daemon expression that will allow the daemon 
to shut itself down when it's finished processing a topic queue.

There a couple of small changes that need to be made to allow the daemon to 
terminate on it's own:

1) The daemon will need to be passed the Map of all daemons in the /stream 
handler. This will allow the DaemonStream to remove itself from the Map when it 
terminates.
2) Logic needs to be added for the daemon to exit it's run loop if the topic 
signals it had a zero Tuple run. The *sleepMillis* value in the EOF Tuple can 
be used for this purpose. If sleepMillis is greater then 0 then this signals a 
zero Tuple run.


> Allow daemons to terminate
> --
>
> Key: SOLR-9417
> URL: https://issues.apache.org/jira/browse/SOLR-9417
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.3
>
> Attachments: SOLR-9417.patch
>
>
> The daemon expression currently runs until it's killed. This ticket will add 
> a new *terminate* parameter to the daemon expression that will allow the 
> daemon to shut itself down when it's finished processing a topic queue.
> There are a couple of small changes that need to be made to allow the daemon 
> to terminate on it's own:
> 1) The daemon will need to be passed the Map of all daemons in the /stream 
> handler. This will allow the DaemonStream to remove itself from the Map when 
> it terminates.
> 2) Logic needs to be added for the daemon to exit it's run loop if the topic 
> signals it had a zero Tuple run. The *sleepMillis* value in the EOF Tuple can 
> be used for this purpose. If sleepMillis is greater then 0 then this signals 
> a zero Tuple run.



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

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

[jira] [Updated] (SOLR-9417) Allow daemons to terminate

[Joel Bernstein (JIRA)]

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

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

Initial patch without tests.

> Allow daemons to terminate
> --
>
> Key: SOLR-9417
> URL: https://issues.apache.org/jira/browse/SOLR-9417
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.3
>
> Attachments: SOLR-9417.patch
>
>
> The daemon expression currently runs until it's killed. This ticket will add 
> a new *terminate* parameter to the daemon expression that will allow the 
> daemon to shut itself down when it's finished processing a topic queue.
> There a couple of small changes that need to be made to allow the daemon to 
> terminate on it's own:
> 1) The daemon will need to be passed the Map of all daemons in the /stream 
> handler. This will allow the DaemonStream to remove itself from the Map when 
> it terminates.
> 2) Logic needs to be added for the daemon to exit it's run loop if the topic 
> signals it had a zero Tuple run. The *sleepMillis* value in the EOF Tuple can 
> be used for this purpose. If sleepMillis is greater then 0 then this signals 
> a zero Tuple run.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

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

[jira] [Commented] (SOLR-9269) Ability to create/delete/list snapshots for a solr core

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9269:
--

Github user hgadre closed the pull request at:

https://github.com/apache/lucene-solr/pull/68


> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Fix For: 6.2
>
> Attachments: SOLR-9269.patch, SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



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

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

[jira] [Commented] (SOLR-9269) Ability to create/delete/list snapshots for a solr core

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9269:
--

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/68
  
Created another PR as part of SOLR-9642. Hence closing this...


> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Fix For: 6.2
>
> Attachments: SOLR-9269.patch, SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



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

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

[GitHub] lucene-solr issue #68: [SOLR-9269] Refactor the snapshot cleanup mechanism t...

[hgadre]

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/68
  
Created another PR as part of SOLR-9642. Hence closing this...


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

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

[GitHub] lucene-solr pull request #68: [SOLR-9269] Refactor the snapshot cleanup mech...

[hgadre]

Github user hgadre closed the pull request at:

https://github.com/apache/lucene-solr/pull/68


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

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

[jira] [Commented] (SOLR-9642) Refactor the core level snapshot cleanup mechanism to rely on Lucene

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9642:
--

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/97
  
@yonik Could you please take a look?


> Refactor the core level snapshot cleanup mechanism to rely on Lucene
> 
>
> Key: SOLR-9642
> URL: https://issues.apache.org/jira/browse/SOLR-9642
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> SOLR-9269 introduced a mechanism to create/delete snapshots for a Solr core 
> (using Lucene IndexDeletionPolicy). The current snapshot cleanup mechanism is 
> based on reference counting the index files shared between multiple segments. 
> Since this mechanism completely skips the Lucene APIs, it is not portable 
> (e.g. it doesn't work on 4.10.3 version).
> I propose an alternative implementation which relies exclusively on Lucene 
> IndexWriter (+ IndexDeletionPolicy) for cleanup.



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

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

[GitHub] lucene-solr issue #97: [SOLR-9642] Refactor the snapshot cleanup mechanism t...

[hgadre]

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/97
  
@yonik Could you please take a look?


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

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

[jira] [Commented] (SOLR-9642) Refactor the core level snapshot cleanup mechanism to rely on Lucene

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9642:
--

GitHub user hgadre opened a pull request:

https://github.com/apache/lucene-solr/pull/97

[SOLR-9642] Refactor the snapshot cleanup mechanism to rely on Lucene

The current snapshot cleanup mechanism is based on reference counting
the index files shared between multiple segments. Since this mechanism
completely skips the Lucene APIs, it is not portable (e.g. it doesn't
work on 4.10.x version).

This patch provides an alternate implementation which relies exclusively
on Lucene IndexWriter (+ IndexDeletionPolicy) for cleanup.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgadre/lucene-solr SOLR-9642_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/97.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #97


commit 9f2eee48b9171eddcbb63aa716e8943cafeeddaf
Author: Hrishikesh Gadre 
Date:   2016-08-10T23:59:31Z

[SOLR-9642] Refactor the snapshot cleanup mechanism to rely on Lucene

The current snapshot cleanup mechanism is based on reference counting
the index files shared between multiple segments. Since this mechanism
completely skips the Lucene APIs, it is not portable (e.g. it doesn't
work on 4.10.x version).

This patch provides an alternate implementation which relies exclusively
on Lucene IndexWriter (+ IndexDeletionPolicy) for cleanup.




> Refactor the core level snapshot cleanup mechanism to rely on Lucene
> 
>
> Key: SOLR-9642
> URL: https://issues.apache.org/jira/browse/SOLR-9642
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hrishikesh Gadre
>
> SOLR-9269 introduced a mechanism to create/delete snapshots for a Solr core 
> (using Lucene IndexDeletionPolicy). The current snapshot cleanup mechanism is 
> based on reference counting the index files shared between multiple segments. 
> Since this mechanism completely skips the Lucene APIs, it is not portable 
> (e.g. it doesn't work on 4.10.3 version).
> I propose an alternative implementation which relies exclusively on Lucene 
> IndexWriter (+ IndexDeletionPolicy) for cleanup.



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

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

[GitHub] lucene-solr pull request #97: [SOLR-9642] Refactor the snapshot cleanup mech...

[hgadre]

GitHub user hgadre opened a pull request:

https://github.com/apache/lucene-solr/pull/97

[SOLR-9642] Refactor the snapshot cleanup mechanism to rely on Lucene

The current snapshot cleanup mechanism is based on reference counting
the index files shared between multiple segments. Since this mechanism
completely skips the Lucene APIs, it is not portable (e.g. it doesn't
work on 4.10.x version).

This patch provides an alternate implementation which relies exclusively
on Lucene IndexWriter (+ IndexDeletionPolicy) for cleanup.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hgadre/lucene-solr SOLR-9642_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/97.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #97


commit 9f2eee48b9171eddcbb63aa716e8943cafeeddaf
Author: Hrishikesh Gadre 
Date:   2016-08-10T23:59:31Z

[SOLR-9642] Refactor the snapshot cleanup mechanism to rely on Lucene

The current snapshot cleanup mechanism is based on reference counting
the index files shared between multiple segments. Since this mechanism
completely skips the Lucene APIs, it is not portable (e.g. it doesn't
work on 4.10.x version).

This patch provides an alternate implementation which relies exclusively
on Lucene IndexWriter (+ IndexDeletionPolicy) for cleanup.




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

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

[JENKINS-MAVEN] Lucene-Solr-Maven-6.x #162: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-6.x/162/

No tests ran.

Build Log:
[...truncated 8367 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:783: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/build.xml:316: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:533:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:528:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/build.xml:479: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/common-build.xml:2512:
 Can't get https://issues.apache.org/jira/rest/api/2/project/LUCENE to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-6.x/lucene/build/docs/changes/jiraVersionList.json

Total time: 3 minutes 28 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

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

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.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([14DADA6311EDEE97]:0)


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

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

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


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

Error Message:
Timeout occured while waiting response from server at: https://127.0.0.1:49922

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:49922
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:604)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:251)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:399)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:457)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 120 
seconds
at 
__randomizedtesting.SeedInfo.seed([C89DB9AD6B76BE31:40C98677C58AD3C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:181)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:862)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1418)
at org.apache.solr.cloud.RecoveryZkTest.test(RecoveryZkTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

RE: Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!)

[Uwe Schindler]

Hi again,

with jdk.io.permissionsUseCanonicalPath=true it also works, so it is related to 
the new FilePermission code, so my first guess was true, the issue is 
JDK-8164705.

Uwe

> (I cc'ed jdk-dev@openjdk, reader there please read the previous mails
> below, too).
> 
> I analyzed the problem, although I don't know exactly why it happens:
> - On Windows it does not happen on my machine (no idea why!)
> - On Linux it happens when tests are running with security manager (this is
> the default for Lucene and Jenkins does this)
> - On Linux it does not happen if I run Lucene tests with "-
> Dtests.useSecurityManager=false"
> 
> This makes me think it is related to this: "Remove pathname canonicalization
> from FilePermission" (https://bugs.openjdk.java.net/browse/JDK-8164705)
> 
> What seems to happen: The code calls Class.getResource to get back an URL.
> As the JAR file is somehow outside of the FilePermissions given to the test
> suite, it seems to fail. Maybe because some of the checks failed,
> Class.getResource then returns a null reference, because it was not able to
> access the JAR file.
> 
> Were there some changes related to this: URLClassLoader and FilePermission
> checks?
> 
> How should we proceed?
> 
> Uwe
> 
> -
> Uwe Schindler
> uschind...@apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Sunday, October 16, 2016 10:10 PM
> > To: dev@lucene.apache.org
> > Cc: dalibor.to...@oracle.com; balchandra.vai...@oracle.com; 'Muneer
> > Kolarkunnu' ; 'Dawid Weiss'
> > 
> > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> > Build # 18064 - Unstable!
> >
> > Hi,
> >
> > I reverted the Lucene builds to build Java 9 138 for now. I will later 
> > check if
> > this also happens with build 139, which I have to download first. I will 
> > also
> > debug locally.
> >
> > The code fails because this code hits "null" on getResource() at
> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34)
> >
> > https://github.com/morfologik/morfologik-
> > stemming/blob/master/morfologik-
> >
> polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32
> >
> > This is impossible to happen, because the dict file is in same package. I
> have
> > no idea why this only fails here and not at other places in Lucene. The main
> > difference looks like the use of URL instead of getResourceAsStream() like
> > other places in Lucene.
> >
> > So this seems to be a major regression in Java 9 build 140.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > > Sent: Sunday, October 16, 2016 8:38 PM
> > > To: dev@lucene.apache.org
> > > Cc: dalibor.to...@oracle.com; balchandra.vai...@oracle.com; 'Muneer
> > > Kolarkunnu' ; 'Dawid Weiss'
> > > ; dev@lucene.apache.org
> > > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> > > Build # 18064 - Unstable!
> > >
> > > Hi,
> > >
> > > this seems to be a new regression in Java 9 ea build 140. Interestingly 
> > > this
> > > only affects 2 libraries (morphologic and commons-codec phonetic). We
> > use
> > > loading of resources from classloaders at many places; it is unclear to 
> > > me,
> > > why it only fails here. I will look into the code, but this is outside of
> Lucene.
> > I
> > > think it might be some crazyness like using context class loader in non-
> > proper
> > > ways or similar.
> > >
> > > Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working 
> > > one
> > > was build 138).
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > H.-H.-Meier-Allee 63, D-28213 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> > > > Sent: Sunday, October 16, 2016 8:20 PM
> > > > To: dev@lucene.apache.org
> > > > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> > Build
> > > #
> > > > 18064 - Unstable!
> > > > Importance: Low
> > > >
> > > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/
> > > > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC
> > > >
> > > > 24 tests failed.
> > > > FAILED:
> > > >
> > >
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> > > > ens
> > > >
> > > > Error Message:
> > > > Could not read dictionary data.
> > > >
> > > > Stack Trace:
> > > > java.lang.RuntimeException: Could not read dictionary data.
> > > > at
> > > >
> > >
> >
> __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9
> > > > A]:0)
> > > > 

Class#getResource returns null in JDK9 b140 if security manager is enabled (was: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!)

[Uwe Schindler]

Hi,

(I cc'ed jdk-dev@openjdk, reader there please read the previous mails below, 
too).

I analyzed the problem, although I don't know exactly why it happens:
- On Windows it does not happen on my machine (no idea why!)
- On Linux it happens when tests are running with security manager (this is the 
default for Lucene and Jenkins does this)
- On Linux it does not happen if I run Lucene tests with 
"-Dtests.useSecurityManager=false"

This makes me think it is related to this: "Remove pathname canonicalization 
from FilePermission" (https://bugs.openjdk.java.net/browse/JDK-8164705)

What seems to happen: The code calls Class.getResource to get back an URL. As 
the JAR file is somehow outside of the FilePermissions given to the test suite, 
it seems to fail. Maybe because some of the checks failed, Class.getResource 
then returns a null reference, because it was not able to access the JAR file.

Were there some changes related to this: URLClassLoader and FilePermission 
checks?

How should we proceed?

Uwe

-
Uwe Schindler
uschind...@apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, October 16, 2016 10:10 PM
> To: dev@lucene.apache.org
> Cc: dalibor.to...@oracle.com; balchandra.vai...@oracle.com; 'Muneer
> Kolarkunnu' ; 'Dawid Weiss'
> 
> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> Build # 18064 - Unstable!
> 
> Hi,
> 
> I reverted the Lucene builds to build Java 9 138 for now. I will later check 
> if
> this also happens with build 139, which I have to download first. I will also
> debug locally.
> 
> The code fails because this code hits "null" on getResource() at
> morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34)
> 
> https://github.com/morfologik/morfologik-
> stemming/blob/master/morfologik-
> polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32
> 
> This is impossible to happen, because the dict file is in same package. I have
> no idea why this only fails here and not at other places in Lucene. The main
> difference looks like the use of URL instead of getResourceAsStream() like
> other places in Lucene.
> 
> So this seems to be a major regression in Java 9 build 140.
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Sunday, October 16, 2016 8:38 PM
> > To: dev@lucene.apache.org
> > Cc: dalibor.to...@oracle.com; balchandra.vai...@oracle.com; 'Muneer
> > Kolarkunnu' ; 'Dawid Weiss'
> > ; dev@lucene.apache.org
> > Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> > Build # 18064 - Unstable!
> >
> > Hi,
> >
> > this seems to be a new regression in Java 9 ea build 140. Interestingly this
> > only affects 2 libraries (morphologic and commons-codec phonetic). We
> use
> > loading of resources from classloaders at many places; it is unclear to me,
> > why it only fails here. I will look into the code, but this is outside of 
> > Lucene.
> I
> > think it might be some crazyness like using context class loader in non-
> proper
> > ways or similar.
> >
> > Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one
> > was build 138).
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> > > Sent: Sunday, October 16, 2016 8:20 PM
> > > To: dev@lucene.apache.org
> > > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> Build
> > #
> > > 18064 - Unstable!
> > > Importance: Low
> > >
> > > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/
> > > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC
> > >
> > > 24 tests failed.
> > > FAILED:
> > >
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> > > ens
> > >
> > > Error Message:
> > > Could not read dictionary data.
> > >
> > > Stack Trace:
> > > java.lang.RuntimeException: Could not read dictionary data.
> > >   at
> > >
> >
> __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9
> > > A]:0)
> > >   at
> > >
> morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38)
> > >   at
> > >
> >
> org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik
> > > Analyzer.java:52)
> > >   at
> > >
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly
> > > zer(TestMorfologikAnalyzer.java:39)
> > >   at
> > >
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> > > ens(TestMorfologikAnalyzer.java:44)

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.index.TestBagOfPositions.test

Error Message:
Captured an uncaught exception in thread: Thread[id=1143, name=Thread-908, 
state=RUNNABLE, group=TGRP-TestBagOfPositions]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1143, name=Thread-908, state=RUNNABLE, 
group=TGRP-TestBagOfPositions]
at 
__randomizedtesting.SeedInfo.seed([837308AA28604EDB:B273770869C2323]:0)
Caused by: java.lang.AssertionError
at __randomizedtesting.SeedInfo.seed([837308AA28604EDB]:0)
at 
org.apache.lucene.index.TieredMergePolicy.findMerges(TieredMergePolicy.java:409)
at 
org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:2087)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2051)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4910)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4948)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4939)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1565)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1307)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:171)
at 
org.apache.lucene.index.TestBagOfPositions$1.run(TestBagOfPositions.java:119)




Build Log:
[...truncated 1041 lines...]
   [junit4] Suite: org.apache.lucene.index.TestBagOfPositions
   [junit4]   2> okt. 17, 2016 6:07:26 AM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-908,5,TGRP-TestBagOfPositions]
   [junit4]   2> java.lang.AssertionError
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([837308AA28604EDB]:0)
   [junit4]   2>at 
org.apache.lucene.index.TieredMergePolicy.findMerges(TieredMergePolicy.java:409)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:2087)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2051)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4910)
   [junit4]   2>at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4948)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4939)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1565)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1307)
   [junit4]   2>at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:171)
   [junit4]   2>at 
org.apache.lucene.index.TestBagOfPositions$1.run(TestBagOfPositions.java:119)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestBagOfPositions 
-Dtests.method=test -Dtests.seed=837308AA28604EDB -Dtests.multiplier=3 
-Dtests.slow=true -Dtests.locale=sl-SI 
-Dtests.timezone=Antarctica/DumontDUrville -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   15.8s J1 | TestBagOfPositions.test <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=1143, name=Thread-908, state=RUNNABLE, 
group=TGRP-TestBagOfPositions]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([837308AA28604EDB:B273770869C2323]:0)
   [junit4]> Caused by: java.lang.AssertionError
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([837308AA28604EDB]:0)
   [junit4]>at 
org.apache.lucene.index.TieredMergePolicy.findMerges(TieredMergePolicy.java:409)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.updatePendingMerges(IndexWriter.java:2087)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2051)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4910)
   [junit4]>at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4948)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4939)
   [junit4]>at 

RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!

[Uwe Schindler]

Hi,

I reverted the Lucene builds to build Java 9 138 for now. I will later check if 
this also happens with build 139, which I have to download first. I will also 
debug locally.

The code fails because this code hits "null" on getResource() at 
morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34)

https://github.com/morfologik/morfologik-stemming/blob/master/morfologik-polish/src/main/java/morfologik/stemming/polish/PolishStemmer.java#L32

This is impossible to happen, because the dict file is in same package. I have 
no idea why this only fails here and not at other places in Lucene. The main 
difference looks like the use of URL instead of getResourceAsStream() like 
other places in Lucene.

So this seems to be a major regression in Java 9 build 140.

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, October 16, 2016 8:38 PM
> To: dev@lucene.apache.org
> Cc: dalibor.to...@oracle.com; balchandra.vai...@oracle.com; 'Muneer
> Kolarkunnu' ; 'Dawid Weiss'
> ; dev@lucene.apache.org
> Subject: RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) -
> Build # 18064 - Unstable!
> 
> Hi,
> 
> this seems to be a new regression in Java 9 ea build 140. Interestingly this
> only affects 2 libraries (morphologic and commons-codec phonetic). We use
> loading of resources from classloaders at many places; it is unclear to me,
> why it only fails here. I will look into the code, but this is outside of 
> Lucene. I
> think it might be some crazyness like using context class loader in non-proper
> ways or similar.
> 
> Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one
> was build 138).
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> > Sent: Sunday, October 16, 2016 8:20 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build
> #
> > 18064 - Unstable!
> > Importance: Low
> >
> > Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/
> > Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC
> >
> > 24 tests failed.
> > FAILED:
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> > ens
> >
> > Error Message:
> > Could not read dictionary data.
> >
> > Stack Trace:
> > java.lang.RuntimeException: Could not read dictionary data.
> > at
> >
> __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9
> > A]:0)
> > at
> > morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38)
> > at
> >
> org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik
> > Analyzer.java:52)
> > at
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly
> > zer(TestMorfologikAnalyzer.java:39)
> > at
> >
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> > ens(TestMorfologikAnalyzer.java:44)
> > at
> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-
> > ea/Native Method)
> > at
> > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-
> > ea/NativeMethodAccessorImpl.java:62)
> > at
> > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-
> > ea/DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(java.base@9-
> > ea/Method.java:535)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> > dRunner.java:1764)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> > mizedRunner.java:871)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
> > mizedRunner.java:907)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
> > omizedRunner.java:921)
> > at
> >
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> > SetupTeardownChained.java:49)
> > at
> >
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf
> > terRule.java:45)
> > at
> >
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr
> > eadAndTestName.java:48)
> > at
> >
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI
> > gnoreAfterMaxFailures.java:64)
> > at
> >
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.
> > java:47)
> > at
> >
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
> > mentAdapter.java:36)
> > at
> >
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r
> > un(ThreadLeakControl.java:367)
> > at
> >
> 

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

[Policeman Jenkins Server]

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

24 tests failed.
FAILED:  
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTokens

Error Message:
Could not read dictionary data.

Stack Trace:
java.lang.RuntimeException: Could not read dictionary data.
at 
__randomizedtesting.SeedInfo.seed([E76119C033906F97:6103B05835AE44E5]:0)
at 
morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38)
at 
org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(MorfologikAnalyzer.java:52)
at 
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnalyzer(TestMorfologikAnalyzer.java:39)
at 
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTokens(TestMorfologikAnalyzer.java:44)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Caused by: java.io.IOException: Polish dictionary resource not found.
at 
morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34)
... 39 more


FAILED:  
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testMultipleTokens

Error Message:
Could not read dictionary data.

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr

[JIRA]

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

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

bq. i.e. if I went from LongTrieField -> LongPointField (or whatever the naming 
is) as proposed in this issue and I hypothetically had index=false but 
docValues=true, then is there any real change?
For single value the DV implementation is the same. For MultiValue not. As I 
said, the plan now is to change the implementation to SortedNumeric, but if we 
decided to keep SortedSet we would probably change the encoding from prefix (in 
{{LegacyNumericUtils}}) to the sortable bytes encoding Points use (in 
{{NumericUtils}}). 
bq. The first time we went through this transition, "int" was renamed to "pint" 
in the example schema, and then a new "int" was created to use trie 
(numeric)
Yes, with this patch I would add the "pTYPE" with PointField to the basic 
schemas. Once we are comfortable with them we can switch the "TYPE" fields to 
use PointFields too, that would be changing the default for Solr (although 
there may be more tasks involved there)

> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

RE: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build # 18064 - Unstable!

[Uwe Schindler]

Hi,

this seems to be a new regression in Java 9 ea build 140. Interestingly this 
only affects 2 libraries (morphologic and commons-codec phonetic). We use 
loading of resources from classloaders at many places; it is unclear to me, why 
it only fails here. I will look into the code, but this is outside of Lucene. I 
think it might be some crazyness like using context class loader in non-proper 
ways or similar.

Maybe it is a new bug in JDK 9 build 139 or build 140 (the last working one was 
build 138).

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Sunday, October 16, 2016 8:20 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+140) - Build #
> 18064 - Unstable!
> Importance: Low
> 
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/
> Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC
> 
> 24 tests failed.
> FAILED:
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> ens
> 
> Error Message:
> Could not read dictionary data.
> 
> Stack Trace:
> java.lang.RuntimeException: Could not read dictionary data.
>   at
> __randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9
> A]:0)
>   at
> morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38)
>   at
> org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(Morfologik
> Analyzer.java:52)
>   at
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnaly
> zer(TestMorfologikAnalyzer.java:39)
>   at
> org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTok
> ens(TestMorfologikAnalyzer.java:44)
>   at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-
> ea/Native Method)
>   at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-
> ea/NativeMethodAccessorImpl.java:62)
>   at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-
> ea/DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(java.base@9-
> ea/Method.java:535)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> dRunner.java:1764)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> mizedRunner.java:871)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(Rando
> mizedRunner.java:907)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(Rand
> omizedRunner.java:921)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> SetupTeardownChained.java:49)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf
> terRule.java:45)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThr
> eadAndTestName.java:48)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleI
> gnoreAfterMaxFailures.java:64)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.
> java:47)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
> mentAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.r
> un(ThreadLeakControl.java:367)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
> (ThreadLeakControl.java:809)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
> eakControl.java:460)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
> domizedRunner.java:880)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
> mizedRunner.java:781)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
> mizedRunner.java:816)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
> mizedRunner.java:827)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAf
> terRule.java:45)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
> mentAdapter.java:36)
>   at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCla
> ssName.java:41)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
> mentAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State
> mentAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(State

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-8396:


Phased approach makes sense... I think the first release exposing this feature 
should be opt-in.  For this release, we could declare them with 'p'.  Since 
it's been ages since that was a prefix in our schemas (for plain numeric), I 
think it's fine.  "bkd" is an alternative.

Yes I did read the SortedNumericDocValues vs SortedSetDocValues for 
multi-valued... I meant otherwise/in addition to that.  I think it should be a 
separate issue... and perhaps we should wait on backporting this issue until 
both together can be landed on the 6x line to ensure they happen on the same 
release -- I get your concern there.

> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18064/
Java: 32bit/jdk-9-ea+140 -server -XX:+UseParallelGC

24 tests failed.
FAILED:  
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTokens

Error Message:
Could not read dictionary data.

Stack Trace:
java.lang.RuntimeException: Could not read dictionary data.
at 
__randomizedtesting.SeedInfo.seed([27A360EA9CD9A4E8:A1C1C9729AE78F9A]:0)
at 
morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:38)
at 
org.apache.lucene.analysis.morfologik.MorfologikAnalyzer.(MorfologikAnalyzer.java:52)
at 
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.getTestAnalyzer(TestMorfologikAnalyzer.java:39)
at 
org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testSingleTokens(TestMorfologikAnalyzer.java:44)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:843)
Caused by: java.io.IOException: Polish dictionary resource not found.
at 
morfologik.stemming.polish.PolishStemmer.(PolishStemmer.java:34)
... 39 more


FAILED:  org.apache.lucene.analysis.morfologik.TestMorfologikAnalyzer.testRandom

Error Message:
Could not read dictionary data.

Stack Trace:

[jira] [Created] (LUCENE-7498) More Like This to Use BM25

[Alessandro Benedetti (JIRA)]

Alessandro Benedetti created LUCENE-7498:


 Summary: More Like This to Use BM25
 Key: LUCENE-7498
 URL: https://issues.apache.org/jira/browse/LUCENE-7498
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/other
Reporter: Alessandro Benedetti


BM25 is now the default similarity, but the more like this is still using the 
old TF/IDF .
 
This issue is to move to BM25 and refactor the MLT to be more organised, 
extensible and maintainable.

Few extensions will follow later, but the focus of this issue will be :
 - BM25
- code refactor + tests



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

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

[jira] [Commented] (SOLR-9077) Streaming expression in solr doesnot support collection alias

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9077:


[~dpgove] - Looks like there is some related code to getting info about aliases 
here:

https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java#L1299

In CloudSolrStream, all that looks like it needs to be done is get all the 
collections (from aliases too) and then add all the replicas from those 
collections. I can put a patch together for that.

Are there other places where aliases would be used that I need to check?

> Streaming expression in solr doesnot support collection alias
> -
>
> Key: SOLR-9077
> URL: https://issues.apache.org/jira/browse/SOLR-9077
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5.1
>Reporter: Suds
>Priority: Minor
>
> Streaming expression in solr does not support collection alias
> when I tried to access collection alias I get null pointer exception 
> issue seems to be related to following code , clusterState.getActiveSlices 
> returns null 
>  Collection slices = clusterState.getActiveSlices(this.collection);
>  for(Slice slice : slices) {
> }
> fix seems to fairly simple , clusterState.getActiveSlices can be made aware 
> of collection alias. I am not sure what will happen when we have large alias 
> which has hundred of slices.



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

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

[jira] [Commented] (LUCENE-7493) Support of TotalHitCountCollector for FacetCollector.search api if numdocs passed as zero.

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7493:


OK that failure is confusing ... you need to use this line instead to get the 
facets:

{noformat}
Facets facets = getTaxonomyFacetCounts(taxo, config, facetCollector, 
config.getDimConfig("b").indexFieldName);
{noformat}

Try that and see if the test always passes?

This is needed because this test's {{BeforeClass}} randomly assigns the {{b}} 
field to a different index field name ...

> Support of TotalHitCountCollector for FacetCollector.search api if numdocs 
> passed as zero.
> --
>
> Key: LUCENE-7493
> URL: https://issues.apache.org/jira/browse/LUCENE-7493
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mahesh
> Attachments: LUCENE-7493-Fail-TestCase.patch, 
> LUCENE-7493-Fail-V.20.patch, LUCENE-7493-Pass-TestCase.patch, 
> LUCENE-7493-Pass-V.20.patch
>
>
> Hi, 
> I want to do drill down search using FacetCollection below is the code 
> FacetsCollector facetCollector = new FacetsCollector();
> TopDocs topDocs = FacetsCollector.search(st.searcher, filterQuery, limit, 
> facetCollector);
> I just want facet information so I pass limit as zero but I get error 
> "numHits must be > 0; please use TotalHitCountCollector if you just need the 
> total hit count".
> For FacetCollector there is no way to initialize 'TotalHitCountCollector'. 
> Internally it always create either 'TopFieldCollector' or 
> 'TopScoreDocCollector' which does not allow limit as 0. 
> So if limit should be zero then there should be a way that 
> 'TotalHitCountCollector' should be initialized. 
> Better way would be to provide an api which takes query and collector as 
> inputs just like 'drillSideways.search(filterQuery, totalHitCountCollector)'.



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

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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([AE565DC1827060AE:571BCE6EBE052D24]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:279)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-9650) CloneFieldUpdateProcessorFactory doesn't preserve source fields order from configuration

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9650:


This probably should have been brought up on the mailing list or IRC channel 
before going to Jira.  I can understand why you would think it's a bug without 
discussion, though.

Looking at the code for CloneFieldUpdateProcessorFactory, the order of the 
fields in the configuration makes no difference.

For the Clone processor, the order of the fields in the SolrInputDocument 
(AFTER it is received by Solr) is what matters.  That class stores them in a 
LinkedHashMap, which guarantees insertion order, but I do not know if there is 
any guarantee that the SolrInputDocument built in SolrJ will be 100% identical 
to the SolrInputDocument used by the update processor as far as field order.  
That would depend on two things -- exactly how SolrJ packages the document for 
transmission, and exactly how Solr treats the request when it receives it and 
turns it back into a SolrInputDocument for update processing.  I'm not very 
familiar with that code.  If a different map implementation (like HashMap) is 
used at any point in that process, then field order might not be preserved.

You did say "fields are composed in order from SolrInputDocument" above ... but 
that's vague.  Can you share your SolrJ code, with \{code:java\} before it in 
the comment, and \{code\} after it in the comment?


> CloneFieldUpdateProcessorFactory doesn't preserve source fields order from 
> configuration
> 
>
> Key: SOLR-9650
> URL: https://issues.apache.org/jira/browse/SOLR-9650
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Libor Ondrusek
>
> We are using configuration like this:
> {code:xml}
>   
>   
> 
>   _id
>   _validFrom
>   _solrId
> 
> 
>   _solrId
>   -
> 
> 
> 
>   
> {code}
> Expected {{_solrId}} field value for document
> {code:javascript}
> {
>   "name": "Name",
>   "_validFrom": 34223040,
>   "_validTo": null,
>   "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
> }
> {code}
> is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-34223040}}*
> When HTTP REST is used, everything work fine.
> When programmatics interface using {{SolrInputDocument}} in {{SolrClient}} is 
> used value of {{_solrId}} will 
> *{{34223040-a518fad5-5421-4253-b501-0ebea0d32cd2}}* because fields are 
> composed in order from {{SolrInputDocument}}



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

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

[jira] [Updated] (SOLR-9650) CloneFieldUpdateProcessorFactory doesn't preserve source fields order from configuration

[Libor Ondrusek (JIRA)]

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

Libor Ondrusek updated SOLR-9650:
-
Description: 
We are using configuration like this:
{code:xml}
  
  

  _id
  _validFrom
  _solrId


  _solrId
  -



  
{code}

Expected {{_solrId}} field value for document
{code:javascript}
{
  "name": "Name",
  "_validFrom": 34223040,
  "_validTo": null,
  "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
}
{code}

is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-34223040}}*
When HTTP REST is used, everything work fine.
When programmatics interface using {{SolrInputDocument}} in {{SolrClient}} is 
used value of {{_solrId}} will 
*{{34223040-a518fad5-5421-4253-b501-0ebea0d32cd2}}* because fields are 
composed in order from {{SolrInputDocument}}

  was:
We are using configuration like this:
{code:xml}
  
  

  _id
  _validFrom
  _solrId


  _solrId
  -



  
{code}

Expected {{_solrId}} field value for document
{code:javascript}
{
  "name": "Name",
  "_validFrom": 34223040,
  "_validTo": null,
  "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
}
{code}

is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-34223040}}*
When HTTP REST is used, everything work fine.
When programmatics interface using {{InputSolrDocument}} in {{SolrClient}} is 
used value of {{_solrId}} will 
*{{34223040-a518fad5-5421-4253-b501-0ebea0d32cd2}}*


> CloneFieldUpdateProcessorFactory doesn't preserve source fields order from 
> configuration
> 
>
> Key: SOLR-9650
> URL: https://issues.apache.org/jira/browse/SOLR-9650
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 6.1
>Reporter: Libor Ondrusek
>
> We are using configuration like this:
> {code:xml}
>   
>   
> 
>   _id
>   _validFrom
>   _solrId
> 
> 
>   _solrId
>   -
> 
> 
> 
>   
> {code}
> Expected {{_solrId}} field value for document
> {code:javascript}
> {
>   "name": "Name",
>   "_validFrom": 34223040,
>   "_validTo": null,
>   "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
> }
> {code}
> is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-34223040}}*
> When HTTP REST is used, everything work fine.
> When programmatics interface using {{SolrInputDocument}} in {{SolrClient}} is 
> used value of {{_solrId}} will 
> *{{34223040-a518fad5-5421-4253-b501-0ebea0d32cd2}}* because fields are 
> composed in order from {{SolrInputDocument}}



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

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

[jira] [Created] (SOLR-9650) CloneFieldUpdateProcessorFactory doesn't preserve source fields order from configuration

[Libor Ondrusek (JIRA)]

Libor Ondrusek created SOLR-9650:


 Summary: CloneFieldUpdateProcessorFactory doesn't preserve source 
fields order from configuration
 Key: SOLR-9650
 URL: https://issues.apache.org/jira/browse/SOLR-9650
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Schema and Analysis
Affects Versions: 6.1
Reporter: Libor Ondrusek


We are using configuration like this:
{code:xml}
  
  

  _id
  _validFrom
  _solrId


  _solrId
  -



  
{code}

Expected {{_solrId}} field value for document
{code:javascript}
{
  "name": "Name",
  "_validFrom": 34223040,
  "_validTo": null,
  "_id": "a518fad5-5421-4253-b501-0ebea0d32cd2"
}
{code}

is *{{a518fad5-5421-4253-b501-0ebea0d32cd2-34223040}}*
When HTTP REST is used, everything work fine.
When programmatics interface using {{InputSolrDocument}} in {{SolrClient}} is 
used value of {{_solrId}} will 
*{{34223040-a518fad5-5421-4253-b501-0ebea0d32cd2}}*



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

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

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8396:


bq. Steve Rowe had some concerns about naming, since Solr already has a 
PointType and in the schemas I'm using "pTYPE", which could be confused with 
the old "Plain numeric fields" (Solr 1.4-ish?).

The first time we went through this transition, "int" was renamed to "pint" in 
the example schema, and then a new "int" was created to use trie (numeric).
If we expect the old numerics to go away at some point, we could do the same 
thing.  In the longer run, keeping simple names like "int" for our primary 
types is nice.
If we're taking a more phased approach though, we might want to wait until 
point fields work with more stuff before rename.


> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8396:


bq. Steve Rowe had some concerns about naming, since Solr already has a 
PointType and in the schemas I'm using "pTYPE", which could be confused with 
the old "Plain numeric fields" (Solr 1.4-ish?).

The first time we went through this transition, "int" was renamed to "pint" in 
the example schema, and then a new "int" was created to use trie (numeric).
If we expect the old numerics to go away at some point, we could do the same 
thing.  In the longer run, keeping simple names like "int" for our primary 
types is nice.
If we're taking a more phased approach though, we might want to wait until 
point fields work with more stuff before rename.


> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1130 - Failure

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard1

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard1
at 
__randomizedtesting.SeedInfo.seed([D2B5EB0D7870FD:D222F90853D7D6CF]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:795)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testReplicationAfterLeaderChange(CdcrReplicationDistributedZkTest.java:305)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-8396:


bq. Is anything changing with DocValues in this issue?

Yes, see Tomas's previous comment:
bq. the plan is that PointFields will use SortedNumericDocValues

It doesn't matter so much if all of this gets done in 2 commits/issues or 10, 
but we should know where we're going and how we want to get there.

Actually, I just saw the comment from Tomas that addresses the most important 
part: "I throw an exception if the user tries to create a PointField with 
MultiValued DV".  So this nicely handles the concern about mixed DV types with 
point fields (sometimes SortedSetDocValues, sometimes SortedNumericDocValues).


> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



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

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

[jira] [Updated] (LUCENE-7497) Cannot use boolean SHOULD queries with block join?

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7497:
---
Attachment: LUCENE-7497.patch

Patch w/ new failing test case.

> Cannot use boolean SHOULD queries with block join?
> --
>
> Key: LUCENE-7497
> URL: https://issues.apache.org/jira/browse/LUCENE-7497
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Attachments: LUCENE-7497.patch
>
>
> I'm in the process of upgrading http://jirasearch.mikemccandless.com (based 
> on 4.10.x in production today!) to Lucene 6.x, but hit this tricky bug.
> When I run the new test case, I hit this:
> {noformat}
> 1) testBQShouldJoinedChild(org.apache.lucene.search.join.TestBlockJoin)
> java.lang.UnsupportedOperationException
>   at 
> __randomizedtesting.SeedInfo.seed([4D5C76211B3E41E1:48F4B8C556F02AB0]:0)
>   at org.apache.lucene.search.FakeScorer.getChildren(FakeScorer.java:60)
>   at 
> org.apache.lucene.search.join.ToParentBlockJoinCollector$1.setScorer(ToParentBlockJoinCollector.java:190)
>   at 
> org.apache.lucene.search.FilterLeafCollector.setScorer(FilterLeafCollector.java:38)
>   at 
> org.apache.lucene.search.AssertingLeafCollector.setScorer(AssertingLeafCollector.java:43)
>   at 
> org.apache.lucene.search.FilterLeafCollector.setScorer(FilterLeafCollector.java:38)
>   at 
> org.apache.lucene.search.AssertingLeafCollector.setScorer(AssertingLeafCollector.java:43)
>   at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:319)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>   at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
>   at 
> org.apache.lucene.search.join.TestBlockJoin.testBQShouldJoinedChild(TestBlockJoin.java:233)
> {noformat}
> Not sure how to fix it ... it happens because jirasearch runs SHOULD queries 
> against the child docs (one child doc per jira comment) and parent docs text 
> fields (one child doc per jira issue).



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

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

[jira] [Created] (LUCENE-7497) Cannot use boolean SHOULD queries with block join?

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7497:
--

 Summary: Cannot use boolean SHOULD queries with block join?
 Key: LUCENE-7497
 URL: https://issues.apache.org/jira/browse/LUCENE-7497
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless


I'm in the process of upgrading http://jirasearch.mikemccandless.com (based on 
4.10.x in production today!) to Lucene 6.x, but hit this tricky bug.

When I run the new test case, I hit this:

{noformat}
1) testBQShouldJoinedChild(org.apache.lucene.search.join.TestBlockJoin)
java.lang.UnsupportedOperationException
at 
__randomizedtesting.SeedInfo.seed([4D5C76211B3E41E1:48F4B8C556F02AB0]:0)
at org.apache.lucene.search.FakeScorer.getChildren(FakeScorer.java:60)
at 
org.apache.lucene.search.join.ToParentBlockJoinCollector$1.setScorer(ToParentBlockJoinCollector.java:190)
at 
org.apache.lucene.search.FilterLeafCollector.setScorer(FilterLeafCollector.java:38)
at 
org.apache.lucene.search.AssertingLeafCollector.setScorer(AssertingLeafCollector.java:43)
at 
org.apache.lucene.search.FilterLeafCollector.setScorer(FilterLeafCollector.java:38)
at 
org.apache.lucene.search.AssertingLeafCollector.setScorer(AssertingLeafCollector.java:43)
at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:319)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
at 
org.apache.lucene.search.join.TestBlockJoin.testBQShouldJoinedChild(TestBlockJoin.java:233)
{noformat}

Not sure how to fix it ... it happens because jirasearch runs SHOULD queries 
against the child docs (one child doc per jira comment) and parent docs text 
fields (one child doc per jira issue).



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18060/
Java: 32bit/jdk-9-ea+138 -client -XX:+UseConcMarkSweepGC

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

Error Message:
expected:<152> but was:<138>

Stack Trace:
java.lang.AssertionError: expected:<152> but was:<138>
at 
__randomizedtesting.SeedInfo.seed([8200804FAF1571AB:A54BF9501E91C53]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:280)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:244)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:130)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:535)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)