[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 43 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/43/

6 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomBig

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([36541951E3BFD641]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.spatial3d.TestGeo3DPoint

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

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


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

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

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([45527DBA3A5217C7:CD06426094AE7A3F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Updated] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7966:

Attachment: LUCENE-7966.patch

I updated the patch with more cleanups: nuked the older ArrayUtil methods, 
cleaned up PrefixCodedTerms, cutover CharsRef,IntsRef,LongsRef.

So this adds compare()/equal() for char[]/int[]/long[]. It also adds mismatch() 
for char[] to implement the UTF16-in-UTF8-order comparator.

Didnt find any new bugs, so seems like more than enough for now. I will think 
about how we can do some validation of MRJAR consistency in 
smoketester/build/something: that's really needed or we can't ensure stuff is 
correct. And also I will think about Uwe's idea about the bootclasspath hack so 
maybe folks don't need an actual java9 compiler.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch, 
> LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.request.SchemaTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores\core

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores\core:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores\core
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105\cores
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\tempDir-105

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




Build Log:
[...truncated 14305 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.request.SchemaTest
   [junit4]   2> 77483 INFO  (SUITE-SchemaTest-seed#[C4A63CE45CA65AD0]-worker) 
[] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-solrj\test\J1\temp\solr.client.solrj.request.SchemaTest_C4A63CE45CA65AD0-001\init-core-data-001
   [junit4]   2> 77484 WARN  (SUITE-SchemaTest-seed#[C4A63CE45CA65AD0]-worker) 
[] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=4 numCloses=4
   [junit4]   2> 77484 INFO  (SUITE-SchemaTest-seed#[C4A63CE45CA65AD0]-worker) 
[] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 77488 INFO  (SUITE-SchemaTest-seed#[C4A63CE45CA65AD0]-worker) 
[] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, 

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 27450 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/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-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (18.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.1.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1223.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.tgz...
   [smoker] 69.2 MB in 0.06 sec (1196.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.zip...
   [smoker] 79.6 MB in 0.07 sec (1206.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6203 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6203 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.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.01 sec (19.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.1.0-src.tgz...
   [smoker] 51.2 MB in 1.01 sec (51.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.tgz...
   [smoker] 143.2 MB in 1.44 sec (99.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.zip...
   [smoker] 144.2 MB in 2.31 sec (62.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.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-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.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-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.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-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.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 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]  
   [smoker] Started Solr server on port 8983 (pid=24534). Happy 

[jira] [Updated] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7966:

Attachment: LUCENE-7966.patch

Same patch, just folding in the suggester bugfix (LUCENE-7968) so that all 
tests pass. I think this is good reason to look at CharsRef/IntsRef/LongsRef 
comparators and so on, maybe we can find more bugs.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[JENKINS-EA] Lucene-Solr-7.0-Windows (64bit/jdk-9-ea+181) - Build # 153 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/153/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:49991/collection1
at 
__randomizedtesting.SeedInfo.seed([66BDEA06763B93B0:EEE9D5DCD8C7FE48]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:638)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1583)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7968:
-

>From what I can tell, since the stuff going into the FST (analyzed form, 
>costs) is still in-order in this case, nothing detected it.

The surface forms are stored in a big byte[], so by being out of order it means 
suggester's results just come back in a bizarre order when there are ties on 
both the analyzed form and costs (rather than in fact being sorted by surface 
form).

E.G. if you used a stemmer and added both {{dog (cost=2)}} and {{dogs 
(cost=2)}}, suggester might sometimes return {{dog}} first, other times 
{{dogs}}.

> AnalyzingSuggester's comparator compares incorrectly
> 
>
> Key: LUCENE-7968
> URL: https://issues.apache.org/jira/browse/LUCENE-7968
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7968.patch
>
>
> Found by LUCENE-7966, but we should fix here separate.
> Currently the tie-break case of this comparator is buggy when 
> {{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs 
> being compared. The current BytesRef.compareTo simply silently returns false 
> in this case, hiding the bug.



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

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

[jira] [Updated] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7968:

Attachment: LUCENE-7968.patch

Patch, including a test that fails even without the assert. It just adds 50 
surface forms with the same weight that all analyze to the same string, and 
asserts that lookup() returns them back in sorted order by surface form.

When payloads=false, the BytesRef's length should be the {{remaining}} bytes, 
not negative.

> AnalyzingSuggester's comparator compares incorrectly
> 
>
> Key: LUCENE-7968
> URL: https://issues.apache.org/jira/browse/LUCENE-7968
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7968.patch
>
>
> Found by LUCENE-7966, but we should fix here separate.
> Currently the tie-break case of this comparator is buggy when 
> {{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs 
> being compared. The current BytesRef.compareTo simply silently returns false 
> in this case, hiding the bug.



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

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-9-ea+181) - Build # 6887 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6887/
Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([8BE9502F41EBD687:89F0FDD9792D826]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest(TestCloudRecovery.java:184)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12933 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestCloudRecovery
   [junit4]   2> 2066985 INFO  
(SUITE-TestCloudRecovery-seed#[8BE9502F41EBD687]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null 

[jira] [Updated] (SOLR-8344) Decide default when requested fields are both column and row stored.

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-8344:
---
Attachment: SOLR-8344.patch

Updated patch based on your hint [~dsmiley]

> Decide default when requested fields are both column and row stored.
> 
>
> Key: SOLR-8344
> URL: https://issues.apache.org/jira/browse/SOLR-8344
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Attachments: SOLR-8344.patch, SOLR-8344.patch
>
>
> This issue was discussed in the comments at SOLR-8220. Splitting it out to a 
> separate issue so that we can have a focused discussion on whether/how to do 
> this.
> If a given set of requested fields are all stored and have docValues (column 
> stored), we can retrieve the values from either place.  What should the 
> default be?



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

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7966:
-

I opened LUCENE-7968 for the suggester case failing here, this looks seriously 
buggy since it has a negative array length, just hidden by the fact 
BytesRef.compareTo silently returns false today. We should fix it separately.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Commented] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7968:
-

Here's an assert that can currently make tests fail. But I want to test that 
the tie-break case really works, not just that stuff is in-bounds.

{code}
diff --git 
a/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggester.java
 
b/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggester.java
index 9c6a624..2fa3569 100644
--- 
a/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggester.java
+++ 
b/lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/AnalyzingSuggester.java
@@ -392,6 +392,8 @@ public class AnalyzingSuggester extends Lookup implements 
Accountable {
 scratchB.offset = readerB.getPosition();
 scratchA.length = a.length - scratchA.offset;
 scratchB.length = b.length - scratchB.offset;
+assert scratchA.isValid();
+assert scratchB.isValid();
   }

   return scratchA.compareTo(scratchB);
{code}

{noformat}
   [junit4] ERROR   0.31s J2 | AnalyzingSuggesterTest.testRandom <<<
   [junit4]> Throwable #1: java.lang.IllegalStateException: length is 
negative: -1507
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([D27F69F0C3A46E64:A0334CFF72C4D817]:0)
   [junit4]>at 
org.apache.lucene.util.BytesRef.isValid(BytesRef.java:222)
   [junit4]>at 
org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester$AnalyzingComparator.compare(AnalyzingSuggester.java:395)
   [junit4]>at 
org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester$AnalyzingComparator.compare(AnalyzingSuggester.java:339)
   [junit4]>at 
org.apache.lucene.util.BytesRefArray$1.comparePivot(BytesRefArray.java:157)
   [junit4]>at 
org.apache.lucene.util.IntroSorter.quicksort(IntroSorter.java:66)
   [junit4]>at 
org.apache.lucene.util.IntroSorter.quicksort(IntroSorter.java:82)
   [junit4]>at 
org.apache.lucene.util.IntroSorter.sort(IntroSorter.java:36)
   [junit4]>at 
org.apache.lucene.util.BytesRefArray.sort(BytesRefArray.java:166)
   [junit4]>at 
org.apache.lucene.util.BytesRefArray.iterator(BytesRefArray.java:196)
   [junit4]>at 
org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:606)
   [junit4]>at 
org.apache.lucene.util.OfflineSorter$SortPartitionTask.call(OfflineSorter.java:588)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.lucene.util.SameThreadExecutorService.execute(SameThreadExecutorService.java:34)
   [junit4]>at 
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
   [junit4]>at 
org.apache.lucene.util.OfflineSorter.sort(OfflineSorter.java:285)
   [junit4]>at 
org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:491)
   [junit4]>at 
org.apache.lucene.search.suggest.analyzing.AnalyzingSuggesterTest.testRandom(AnalyzingSuggesterTest.java:787)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}

> AnalyzingSuggester's comparator compares incorrectly
> 
>
> Key: LUCENE-7968
> URL: https://issues.apache.org/jira/browse/LUCENE-7968
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Found by LUCENE-7966, but we should fix here separate.
> Currently the tie-break case of this comparator is buggy when 
> {{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs 
> being compared. The current BytesRef.compareTo simply silently returns false 
> in this case, hiding the bug.



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

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

[jira] [Created] (LUCENE-7968) AnalyzingSuggester's comparator compares incorrectly

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7968:
---

 Summary: AnalyzingSuggester's comparator compares incorrectly
 Key: LUCENE-7968
 URL: https://issues.apache.org/jira/browse/LUCENE-7968
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


Found by LUCENE-7966, but we should fix here separate.

Currently the tie-break case of this comparator is buggy when 
{{hasPayloads=false}}, as it assigns *negative* lengths to the BytesRefs being 
compared. The current BytesRef.compareTo simply silently returns false in this 
case, hiding the bug.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
inplace_updatable_float didn't match for replica at client: 
http://127.0.0.1:42357/collection1 expected:<111.0> but was:<1.0>

Stack Trace:
java.lang.AssertionError: inplace_updatable_float didn't match for replica at 
client: http://127.0.0.1:42357/collection1 expected:<111.0> but was:<1.0>
at 
__randomizedtesting.SeedInfo.seed([32ACE6FA7DBECC89:BAF8D920D342A171]: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.apache.solr.update.TestInPlaceUpdatesDistrib.assertReplicaValue(TestInPlaceUpdatesDistrib.java:980)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.outOfOrderUpdatesIndividualReplicaTest(TestInPlaceUpdatesDistrib.java:643)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:144)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution

Error Message:
expected:<100.1277> but was:<96.83387609760834>

Stack Trace:
java.lang.AssertionError: expected:<100.1277> but was:<96.83387609760834>
at 
__randomizedtesting.SeedInfo.seed([F844E3D2DEC14670:60541C737C783E0C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:443)
at org.junit.Assert.assertEquals(Assert.java:512)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution(StreamExpressionTest.java:6318)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:


Stack Trace:
java.lang.AssertionError
at 

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestLazyCores.testCachingLimit

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([29196813FF046BA8]:0)


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

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

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




Build Log:
[...truncated 13718 lines...]
   [junit4] Suite: org.apache.solr.core.TestLazyCores
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build/solr-core/test/J0/temp/solr.core.TestLazyCores_29196813FF046BA8-001/init-core-data-001
   [junit4]   2> 2397775 WARN  
(SUITE-TestLazyCores-seed#[29196813FF046BA8]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=39 numCloses=39
   [junit4]   2> 2397775 INFO  
(SUITE-TestLazyCores-seed#[29196813FF046BA8]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 239 INFO  
(SUITE-TestLazyCores-seed#[29196813FF046BA8]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 239 INFO  
(SUITE-TestLazyCores-seed#[29196813FF046BA8]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 2397779 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.SolrTestCaseJ4 ###Starting testBadConfigsGenerateErrors
   [junit4]   2> 2397791 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.c.SolrXmlConfig MBean server found: 
com.sun.jmx.mbeanserver.JmxMBeanServer@46fd6cf6, but no JMX reporters were 
configured - adding default JMX reporter.
   [junit4]   2> 2397834 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.node' (registry 
'solr.node') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@46fd6cf6
   [junit4]   2> 2397843 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jvm' (registry 'solr.jvm') 
enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@46fd6cf6
   [junit4]   2> 2397843 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jetty' (registry 
'solr.jetty') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@46fd6cf6
   [junit4]   2> 2397847 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.c.CorePropertiesLocator Found 6 core definitions underneath 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/solr/build/solr-core/test/J0/temp/solr.core.TestLazyCores_29196813FF046BA8-001/tempDir-001
   [junit4]   2> 2397847 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.c.CorePropertiesLocator Cores are: [badConfig2, badSchema1, core2, 
badConfig1, badSchema2, core1]
   [junit4]   2> 2397847 INFO  
(TEST-TestLazyCores.testBadConfigsGenerateErrors-seed#[29196813FF046BA8]) [
] o.a.s.c.TransientSolrCoreCacheDefault Allocating transient cache for 
2147483647 transient cores
   [junit4]   2> 2397870 INFO  (coreLoadExecutor-7936-thread-2) [
x:badSchema1] o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.1.0
   [junit4]   2> 2397870 INFO  (coreLoadExecutor-7936-thread-3) [x:core2] 
o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.1.0
   [junit4]   2> 2397872 INFO  (coreLoadExecutor-7936-thread-1) [
x:badConfig2] o.a.s.c.Config Ignoring exception matching \QSAXParseException\E
   [junit4]   2> 2397876 INFO  (coreLoadExecutor-7936-thread-2) [
x:badSchema1] o.a.s.c.Config Ignoring exception matching \QSAXParseException\E
   [junit4]   2> 2397877 INFO  (coreLoadExecutor-7936-thread-1) [
x:badConfig1] o.a.s.c.Config Ignoring exception matching \QSAXParseException\E
   [junit4]   2> 2397877 INFO  (coreLoadExecutor-7936-thread-3) [x:core2] 
o.a.s.s.IndexSchema [core2] Schema name=tiny
   [junit4]   2> 2397879 INFO  (coreLoadExecutor-7936-thread-3) [x:core2] 
o.a.s.s.IndexSchema Loaded schema tiny/1.1 with uniqueid field id
   [junit4]   2> 2397879 INFO  (coreLoadExecutor-7936-thread-3) [x:core2] 
o.a.s.c.CoreContainer Creating SolrCore 'core2' using configuration from 
instancedir 

Re: JIRA Status - Finding Patch Submissions

[Mano Kovacs]

Thank you Allen for the info!

I made some progress with the integration for Solr and had several
test-runs on SOLR-10912 and SOLR-10783.

I have a WIP script [1] that can executed on a single issue id so it could
be used for Precommit jenkins jobs. It...
- runs test4tests, notification if no tests were added or updated (comes
with Yetus)
- runs "@author" tag check (comes with Yetus)
- runs the subtasks of "validate" ant action (check lucene version, rat,
license check, forbidden apis) for solr and lucene folder, depending on the
changed files
- runs tests in the modules that were affected. It is still an open
discussion what should be tested.

1. I am looking forward to getting feedback, input, ideas!
2. If this is something that we want to pursuit, is there someone who could
help me with Jenkins and Jira setup?

Thanks,
Mano

[1]
https://github.com/apache/lucene-solr/compare/master...manokovacs:feature/SOLR-10912

On Tue, Jun 20, 2017 at 8:25 AM, Allen Wittenauer  wrote:

> On 2017-05-17 19:10 (-0700), David Smiley 
> wrote:
> > > How else other than a comment could the system communicate results
> back to
> > > the user? Or do you mean that whatever runs should post a comment, but
> > > suppress email notification somehow.
> > >
> >
> > Yes; that.  The rationale being that if someone posts a patch, it'll
> become
> > inevitable that there will be a follow-up bot comment.  It's not a big
> deal
> > though.
>
> Hi.  I hope you don't mind if I chime in here. :)
>
> When the original JIRA support for Apache Yetus was written, we
> actually looked at a way to prevent comments from getting emailed out.  At
> that point in time, the REST interface lacked the functionality. Much
> sadness. But good news: JIRA 7.2.0 does include the necessary magic:
> https://jira.atlassian.com/browse/JRASERVER-34423  .  Now we just have to
> wait until the ASF instance gets upgraded.
>
> > > If the state is set automatically, how do we know when to set it?
> > >
> > > Maybe this could be an extra (optional?) step for the committer
> looking at
> > > the issue? Change to "Patch Available" triggers a run on the most
> recent
> > > attached patch?
> > >
> >
> > +1 nice idea; seems straight-forward compared to other ideas.  I don't
> > think we need to limit this transition to only committers though; even
> the
> > submitter might do it to demonstrate their patch is ready.
>
> Just to fill in some blanks as to how the current projects are
> using it
>
> Submitter sets JIRA issue to Patch Available. There is a job on
> ASF Jenkins called "Precommit-Admin" that uses a JIRA filter to look for
> (group of projects)+"Patch Available"+(updated time frame).  It then
> submits any found issues to Precommit-(project)-build with the issue id.
> For Solr, Lucene, or any other project, it's just a matter of adding your
> project to the JIRA filter and creating the precommit job.  Manually
> running a job is simple, because you just use that project's dedicated
> precommit job and a supplied id.
>
> [I'm in the process of "rescuing" the precommit-admin codebase
> from within the (old) Hadoop svn tree into the much more public Yetus
> source tree, writing documentation, etc.  Right now, this is all tribal
> knowledge. :( ]
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest

Error Message:
Captured an uncaught exception in thread: Thread[id=20282, name=WRITER2, 
state=RUNNABLE, group=TGRP-TestStressInPlaceUpdates]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=20282, name=WRITER2, state=RUNNABLE, 
group=TGRP-TestStressInPlaceUpdates]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:49112/collection1: Cannot talk to ZooKeeper - 
Updates are disabled.
at __randomizedtesting.SeedInfo.seed([EF2A1348D287BB44]:0)
at 
org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:306)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:49112/collection1: Cannot talk to ZooKeeper - 
Updates are disabled.
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:524)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:544)
at 
org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:169)




Build Log:
[...truncated 12652 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestStressInPlaceUpdates
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/build/solr-core/test/J1/temp/solr.cloud.TestStressInPlaceUpdates_EF2A1348D287BB44-001/init-core-data-001
   [junit4]   2> 3577486 WARN  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=1 numCloses=1
   [junit4]   2> 3577486 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 3577487 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 3577487 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 3577490 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 3577490 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/core/src/test-files/solr/collection1/lib,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/core/src/test-files/solr/collection1/lib/classes]
   [junit4]   2> 3577595 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.c.SolrConfig Using Lucene MatchVersion: 7.0.0
   [junit4]   2> 3577716 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.s.IndexSchema [null] Schema name=inplace-updates
   [junit4]   2> 3577966 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.s.IndexSchema Loaded schema inplace-updates/1.6 with uniqueid field id
   [junit4]   2> 3578162 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.node' (registry 'solr.node') 
enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@6533d3d3
   [junit4]   2> 3578191 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jvm' (registry 'solr.jvm') 
enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@6533d3d3
   [junit4]   2> 3578191 INFO  
(SUITE-TestStressInPlaceUpdates-seed#[EF2A1348D287BB44]-worker) [] 
o.a.s.m.r.SolrJmxReporter JMX monitoring for 'solr.jetty' (registry 
'solr.jetty') enabled at server: com.sun.jmx.mbeanserver.JmxMBeanServer@6533d3d3
   [junit4]   2> 3578197 INFO  (coreLoadExecutor-7214-thread-1) [
x:collection1] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, 
from paths: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/solr/core/src/test-files/solr/collection1/lib,
 

[JENKINS-EA] Lucene-Solr-7.0-Linux (32bit/jdk-9-ea+181) - Build # 346 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/346/
Java: 32bit/jdk-9-ea+181 -server -XX:+UseSerialGC --illegal-access=deny

All tests passed

Build Log:
[...truncated 13311 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.0-Linux/solr/build/solr-core/test/temp/junit4-J0-20170912_181026_1019926783947873507492.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-7.0-Linux/heapdumps/java_pid15076.hprof ...
   [junit4] Heap dump file created [541518028 bytes in 0.715 secs]
   [junit4] <<< JVM J0: EOF 

[...truncated 7512 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-7.0-Linux/build.xml:810: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.0-Linux/build.xml:762: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid15076.hprof

Total time: 66 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7966:
-

I thought it's an intrinsic reaching all the way down to an inlined assembly 
(macro), not just ideal graph transformation/ optimization. Apologies for not 
verifying this.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:65196/collection1
at 
__randomizedtesting.SeedInfo.seed([564AA108AAC859B3:DE1E9ED20434344B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:638)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1583)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-11346) throw if solrconfig.xml is invalid

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-11346:


bq. ... What is the use case behind supporting a lib regex to an empty folder? 
...

Fair point, yes, warnings can easily go unnoticed. And when it comes to 
retiring libs, the {{}} clause could always be removed ahead of the jar 
files being removed from the folder. So on that basis finding no matching jars 
should be an error too.

> throw if solrconfig.xml  is invalid
> 
>
> Key: SOLR-11346
> URL: https://issues.apache.org/jira/browse/SOLR-11346
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11346.patch
>
>
> This ticket proposes to throw an exception if a configured {{}} element 
> is invalid. As [~janhoy] mentioned on the dev mailing list today the DIH 
> example currently only warns in this scenario e.g.
> {code}
> WARN ... org.apache.solr.core.SolrConfig; Couldn't add files from 
> /Users/cpoerschke/git/solr/contrib/dataimporthandler/lib filtered by .*\.jar 
> to classpath: /Users/cpoerschke/git/solr/contrib/dataimporthandler/lib
> {code}
> Instead the new behaviour would be e.g.
> {code}
> ...
> Caused by: java.nio.file.NoSuchFileException: 
> /Users/cpoerschke/git/solr/contrib/dataimporthandler/lib
> at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at 
> sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at 
> sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(UnixFileSystemProvider.java:407)
> at java.nio.file.Files.newDirectoryStream(Files.java:589)
> at 
> org.apache.solr.core.SolrResourceLoader.getURLs(SolrResourceLoader.java:273)
> at 
> org.apache.solr.core.SolrResourceLoader.getFilteredURLs(SolrResourceLoader.java:305)
> at org.apache.solr.core.SolrConfig.initLibs(SolrConfig.java:748)
> at org.apache.solr.core.SolrConfig.(SolrConfig.java:207)
> at 
> org.apache.solr.core.SolrConfig.readFromResourceLoader(SolrConfig.java:181)
> ...
> ...
> {code}
> if the directory does not exist but still just a warning if the directory 
> exists but there are no matching files.



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

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

[jira] [Assigned] (SOLR-11250) Add new LTR model which loads the model definition from the external resource

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-11250:
--

Assignee: Christine Poerschke

> Add new LTR model which loads the model definition from the external resource
> -
>
> Key: SOLR-11250
> URL: https://issues.apache.org/jira/browse/SOLR-11250
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11250_master.patch, SOLR-11250_master_v2.patch, 
> SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch, SOLR-11250.patch, 
> SOLR-11250.patch
>
>
> We add new model which contains only the location of the external model and 
> loads it during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper 
> can be available.
> The new model works as the wrapper of existing models, and deligates APIs to 
> them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads 
> the external model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk 
> "file:///var/models/myModel.json", the definition of {{URIExternalModel}} 
> will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
> "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of 
> {{myModel.json}} will be used for scoring documents.



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

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

[jira] [Updated] (SOLR-11250) Add new LTR model which loads the model definition from the external resource

[Christine Poerschke (JIRA)]

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

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

bq. ... Use SolrResourceLoader for loading external models. ...

The abstract {{WrapperModel.fetchModelMap}} method taking a 
{{SolrResourceLoader}} argument but then there also being a concrete 
{{SolrResourceWrapperModel}} class somehow seemed odd to me. So attached 
revised patch goes back to the no-args {{fetchModelMap()}} signature and 
instead adds a {{SolrResourceLoader}} member and setter to the {{WrapperModel}} 
class. What do you think, does that kind of make sense?

The patch also tentatively renames {{SolrResourceWrapperModel}} to 
{{DefaultWrapperModel}} and removes the format parameter in favour of a 
protected {{parseInputStream}} method called by {{fetchModelMap}}. In future a 
(say) YamlWrapperModel class could extend the DefaultWrapperModel and override 
its parseInputStream method. I've also factored out a protected 
{{openInputStream}} method called by {{fetchModelMap}} i.e. custom classes 
wishing to use something other than the SolrResourceLoader could do so by 
overriding that method. How does that sound?

> Add new LTR model which loads the model definition from the external resource
> -
>
> Key: SOLR-11250
> URL: https://issues.apache.org/jira/browse/SOLR-11250
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Priority: Minor
> Attachments: SOLR-11250_master.patch, SOLR-11250_master_v2.patch, 
> SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch, SOLR-11250.patch, 
> SOLR-11250.patch
>
>
> We add new model which contains only the location of the external model and 
> loads it during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper 
> can be available.
> The new model works as the wrapper of existing models, and deligates APIs to 
> them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads 
> the external model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk 
> "file:///var/models/myModel.json", the definition of {{URIExternalModel}} 
> will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
> "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of 
> {{myModel.json}} will be used for scoring documents.



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

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

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

[Apache Jenkins Server]

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

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


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

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space


FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

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

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


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([AFCF369E02C3839B:921798B23A2DDDEB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[jira] [Resolved] (SOLR-11348) DIH 'db' example broken in 7.0.0

[James Dyer (JIRA)]

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

James Dyer resolved SOLR-11348.
---
Resolution: Fixed

> DIH 'db' example broken in 7.0.0
> 
>
> Key: SOLR-11348
> URL: https://issues.apache.org/jira/browse/SOLR-11348
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, examples
>Affects Versions: 7.0.0
>Reporter: Jan Høydahl
>Assignee: James Dyer
>Priority: Critical
> Fix For: 7.1
>
> Attachments: SOLR-11348.patch
>
>
> The DIH 'db' example is broken in 7.0.0, also in RC3.
> h2. Steps to reproduce
> # bin/solr -e dih
> # open http://localhost:8983/solr/#/db/dataimport//dataimport
> # Click "execute" button
> # See that "Fetched: 0", should be 16
> # Open {{/solr/example/example-DIH/logs/solr.log}} and see exception
> {noformat}
> INFO  - 2017-09-11 08:16:59.663; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Data Configuration loaded 
> successfully
> INFO  - 2017-09-11 08:16:59.671; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={core=db=false=on=true=dataimport=true=json=full-import&_=1505117815960=false}
>  status=0 QTime=24
> INFO  - 2017-09-11 08:16:59.671; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Starting Full Import
> INFO  - 2017-09-11 08:16:59.676; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={indent=on=json=status&_=1505117815960} status=0 QTime=0
> WARN  - 2017-09-11 08:16:59.687; [   x:db] 
> org.apache.solr.handler.dataimport.SimplePropertiesWriter; Unable to read: 
> dataimport.properties
> INFO  - 2017-09-11 08:16:59.764; [   x:db] 
> org.apache.solr.handler.dataimport.JdbcDataSource$1; Creating a connection 
> for entity item with URL: 
> jdbc:hsqldb:/Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex
> ERROR - 2017-09-11 08:17:00.417; [   x:db] 
> org.apache.solr.common.SolrException; Exception while processing: item 
> document : SolrInputDocument(fields: 
> []):org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to 
> execute query: select * from item Processing Document # 1
>   at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:69)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:327)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.createResultSetIterator(JdbcDataSource.java:288)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:283)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:52)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
>   at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:267)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:415)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:474)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.lambda$runAsync$0(DataImporter.java:457)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: error in script file line: 2 
> /Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex system 
> object cannot be modified in statement [CREATE CACHED TABLE ITEM(ID 
> CHAR(8),NAME VARCHAR(100),MANU VARCHAR(50),WEIGHT REAL,PRICE REAL,POPULARITY 
> INTEGER,INCLUDES VARCHAR(200),LAST_MODIFIED TIMESTAMP DEFAULT NOW)]
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCConnection.(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:192)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:172)
>   at 
> 

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 27437 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/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:/home/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.03 sec (8.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 29.0 MB in 0.08 sec (352.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 69.1 MB in 0.23 sec (304.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.4 MB in 0.28 sec (280.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6166 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6166 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.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 (252.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-8.0.0-src.tgz...
   [smoker] 50.7 MB in 0.04 sec (1195.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.tgz...
   [smoker] 143.1 MB in 0.12 sec (1211.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-8.0.0.zip...
   [smoker] 144.1 MB in 0.12 sec (1208.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-8.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.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=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.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 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.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 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=3554). Happy 

[jira] [Updated] (SOLR-11354) Add factorial Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-11354:
--
Fix Version/s: master (8.0)
   7.0

> Add factorial Stream Evaluator
> --
>
> Key: SOLR-11354
> URL: https://issues.apache.org/jira/browse/SOLR-11354
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.0, master (8.0)
>
>
> This ticket will add the factorial Stream Evaluator:
> Syntax:
> {code}
> factorial(N)
> {code}



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

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

[jira] [Assigned] (SOLR-11354) Add factorial Stream Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-11354:
-

Assignee: Joel Bernstein

> Add factorial Stream Evaluator
> --
>
> Key: SOLR-11354
> URL: https://issues.apache.org/jira/browse/SOLR-11354
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> This ticket will add the factorial Stream Evaluator:
> Syntax:
> {code}
> factorial(N)
> {code}



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

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

[jira] [Created] (SOLR-11354) Add factorial Stream Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-11354:
-

 Summary: Add factorial Stream Evaluator
 Key: SOLR-11354
 URL: https://issues.apache.org/jira/browse/SOLR-11354
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Joel Bernstein


This ticket will add the factorial Stream Evaluator:

Syntax:
{code}
factorial(N)
{code}



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

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

[jira] [Commented] (SOLR-11348) DIH 'db' example broken in 7.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11348:


Commit 70b8a38c81a56e271d0e795667039eb12ab5421b in lucene-solr's branch 
refs/heads/branch_7x from jdyer1
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=70b8a38 ]

SOLR-11348: fix the DIH database example


> DIH 'db' example broken in 7.0.0
> 
>
> Key: SOLR-11348
> URL: https://issues.apache.org/jira/browse/SOLR-11348
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, examples
>Affects Versions: 7.0.0
>Reporter: Jan Høydahl
>Assignee: James Dyer
>Priority: Critical
> Fix For: 7.1
>
> Attachments: SOLR-11348.patch
>
>
> The DIH 'db' example is broken in 7.0.0, also in RC3.
> h2. Steps to reproduce
> # bin/solr -e dih
> # open http://localhost:8983/solr/#/db/dataimport//dataimport
> # Click "execute" button
> # See that "Fetched: 0", should be 16
> # Open {{/solr/example/example-DIH/logs/solr.log}} and see exception
> {noformat}
> INFO  - 2017-09-11 08:16:59.663; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Data Configuration loaded 
> successfully
> INFO  - 2017-09-11 08:16:59.671; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={core=db=false=on=true=dataimport=true=json=full-import&_=1505117815960=false}
>  status=0 QTime=24
> INFO  - 2017-09-11 08:16:59.671; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Starting Full Import
> INFO  - 2017-09-11 08:16:59.676; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={indent=on=json=status&_=1505117815960} status=0 QTime=0
> WARN  - 2017-09-11 08:16:59.687; [   x:db] 
> org.apache.solr.handler.dataimport.SimplePropertiesWriter; Unable to read: 
> dataimport.properties
> INFO  - 2017-09-11 08:16:59.764; [   x:db] 
> org.apache.solr.handler.dataimport.JdbcDataSource$1; Creating a connection 
> for entity item with URL: 
> jdbc:hsqldb:/Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex
> ERROR - 2017-09-11 08:17:00.417; [   x:db] 
> org.apache.solr.common.SolrException; Exception while processing: item 
> document : SolrInputDocument(fields: 
> []):org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to 
> execute query: select * from item Processing Document # 1
>   at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:69)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:327)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.createResultSetIterator(JdbcDataSource.java:288)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:283)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:52)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
>   at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:267)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:415)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:474)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.lambda$runAsync$0(DataImporter.java:457)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: error in script file line: 2 
> /Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex system 
> object cannot be modified in statement [CREATE CACHED TABLE ITEM(ID 
> CHAR(8),NAME VARCHAR(100),MANU VARCHAR(50),WEIGHT REAL,PRICE REAL,POPULARITY 
> INTEGER,INCLUDES VARCHAR(200),LAST_MODIFIED TIMESTAMP DEFAULT NOW)]
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCConnection.(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source)
>   at 

[jira] [Commented] (SOLR-11348) DIH 'db' example broken in 7.0.0

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11348:


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

SOLR-11348: fix the DIH database example


> DIH 'db' example broken in 7.0.0
> 
>
> Key: SOLR-11348
> URL: https://issues.apache.org/jira/browse/SOLR-11348
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, examples
>Affects Versions: 7.0.0
>Reporter: Jan Høydahl
>Assignee: James Dyer
>Priority: Critical
> Fix For: 7.1
>
> Attachments: SOLR-11348.patch
>
>
> The DIH 'db' example is broken in 7.0.0, also in RC3.
> h2. Steps to reproduce
> # bin/solr -e dih
> # open http://localhost:8983/solr/#/db/dataimport//dataimport
> # Click "execute" button
> # See that "Fetched: 0", should be 16
> # Open {{/solr/example/example-DIH/logs/solr.log}} and see exception
> {noformat}
> INFO  - 2017-09-11 08:16:59.663; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Data Configuration loaded 
> successfully
> INFO  - 2017-09-11 08:16:59.671; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={core=db=false=on=true=dataimport=true=json=full-import&_=1505117815960=false}
>  status=0 QTime=24
> INFO  - 2017-09-11 08:16:59.671; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Starting Full Import
> INFO  - 2017-09-11 08:16:59.676; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={indent=on=json=status&_=1505117815960} status=0 QTime=0
> WARN  - 2017-09-11 08:16:59.687; [   x:db] 
> org.apache.solr.handler.dataimport.SimplePropertiesWriter; Unable to read: 
> dataimport.properties
> INFO  - 2017-09-11 08:16:59.764; [   x:db] 
> org.apache.solr.handler.dataimport.JdbcDataSource$1; Creating a connection 
> for entity item with URL: 
> jdbc:hsqldb:/Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex
> ERROR - 2017-09-11 08:17:00.417; [   x:db] 
> org.apache.solr.common.SolrException; Exception while processing: item 
> document : SolrInputDocument(fields: 
> []):org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to 
> execute query: select * from item Processing Document # 1
>   at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:69)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:327)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.createResultSetIterator(JdbcDataSource.java:288)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:283)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:52)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
>   at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:267)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:415)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:474)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.lambda$runAsync$0(DataImporter.java:457)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: error in script file line: 2 
> /Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex system 
> object cannot be modified in statement [CREATE CACHED TABLE ITEM(ID 
> CHAR(8),NAME VARCHAR(100),MANU VARCHAR(50),WEIGHT REAL,PRICE REAL,POPULARITY 
> INTEGER,INCLUDES VARCHAR(200),LAST_MODIFIED TIMESTAMP DEFAULT NOW)]
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCConnection.(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source)
>   at 
> 

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

[Policeman Jenkins Server]

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

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

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

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

[jira] [Assigned] (SOLR-11348) DIH 'db' example broken in 7.0.0

[James Dyer (JIRA)]

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

James Dyer reassigned SOLR-11348:
-

Assignee: James Dyer

> DIH 'db' example broken in 7.0.0
> 
>
> Key: SOLR-11348
> URL: https://issues.apache.org/jira/browse/SOLR-11348
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, examples
>Affects Versions: 7.0.0
>Reporter: Jan Høydahl
>Assignee: James Dyer
>Priority: Critical
> Fix For: 7.1
>
> Attachments: SOLR-11348.patch
>
>
> The DIH 'db' example is broken in 7.0.0, also in RC3.
> h2. Steps to reproduce
> # bin/solr -e dih
> # open http://localhost:8983/solr/#/db/dataimport//dataimport
> # Click "execute" button
> # See that "Fetched: 0", should be 16
> # Open {{/solr/example/example-DIH/logs/solr.log}} and see exception
> {noformat}
> INFO  - 2017-09-11 08:16:59.663; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Data Configuration loaded 
> successfully
> INFO  - 2017-09-11 08:16:59.671; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={core=db=false=on=true=dataimport=true=json=full-import&_=1505117815960=false}
>  status=0 QTime=24
> INFO  - 2017-09-11 08:16:59.671; [   x:db] 
> org.apache.solr.handler.dataimport.DataImporter; Starting Full Import
> INFO  - 2017-09-11 08:16:59.676; [   x:db] org.apache.solr.core.SolrCore; 
> [db]  webapp=/solr path=/dataimport 
> params={indent=on=json=status&_=1505117815960} status=0 QTime=0
> WARN  - 2017-09-11 08:16:59.687; [   x:db] 
> org.apache.solr.handler.dataimport.SimplePropertiesWriter; Unable to read: 
> dataimport.properties
> INFO  - 2017-09-11 08:16:59.764; [   x:db] 
> org.apache.solr.handler.dataimport.JdbcDataSource$1; Creating a connection 
> for entity item with URL: 
> jdbc:hsqldb:/Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex
> ERROR - 2017-09-11 08:17:00.417; [   x:db] 
> org.apache.solr.common.SolrException; Exception while processing: item 
> document : SolrInputDocument(fields: 
> []):org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to 
> execute query: select * from item Processing Document # 1
>   at 
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:69)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:327)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.createResultSetIterator(JdbcDataSource.java:288)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:283)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:52)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
>   at 
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
>   at 
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:267)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:476)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:415)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:330)
>   at 
> org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:233)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:415)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:474)
>   at 
> org.apache.solr.handler.dataimport.DataImporter.lambda$runAsync$0(DataImporter.java:457)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: error in script file line: 2 
> /Users/janhoy/git/lucene-solr-2/solr/example/example-DIH/hsqldb/ex system 
> object cannot be modified in statement [CREATE CACHED TABLE ITEM(ID 
> CHAR(8),NAME VARCHAR(100),MANU VARCHAR(50),WEIGHT REAL,PRICE REAL,POPULARITY 
> INTEGER,INCLUDES VARCHAR(200),LAST_MODIFIED TIMESTAMP DEFAULT NOW)]
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>   at org.hsqldb.jdbc.JDBCConnection.(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.getConnection(Unknown Source)
>   at org.hsqldb.jdbc.JDBCDriver.connect(Unknown Source)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:192)
>   at 
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:172)
>   at 
> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20458/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

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

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

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


Error 404 


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



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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7966:
-

{quote}
There's another dimension to your list: the CPU architecture hotspot generates 
code for... I didn't look at the code, but those intrinsics will vary depending 
on what the CPU has to offer.
{quote}

No there isn't actually, the transformation is platform independent: 

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/b756e7a2ec33/src/share/vm/opto/library_call.cpp#l1160

Please in the future, lets actually look at the code first, before getting too 
paranoid about such things. Otherwise we make decisions based on FUD instead of 
facts and end out with the sloppy array code like we have today :(


> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Resolved] (LUCENE-7967) GeoDegeneratePoint in Pole

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7967.
-
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)
   6.7

> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7967: Within check for GeoDegeneratePoint did not allow precision 
allowance.


> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7967: Within check for GeoDegeneratePoint did not allow precision 
allowance.


> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7967: Within check for GeoDegeneratePoint did not allow precision 
allowance.


> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.HealthCheckHandlerTest.testHealthCheckHandlerSolrJ

Error Message:
Error from server at https://127.0.0.1:40798/solr: Host Unavailable: Not 
connected to zk

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:40798/solr: Host Unavailable: Not connected to 
zk
at 
__randomizedtesting.SeedInfo.seed([1CB943819D355D9C:B64A9C95E6D3159D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.HealthCheckHandlerTest.testHealthCheckHandlerSolrJ(HealthCheckHandlerTest.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138329027
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dRectangleShape.java
 ---
@@ -30,32 +30,49 @@
 import org.locationtech.spatial4j.shape.SpatialRelation;
 
 /**
- * Specialization of a {@link Geo3dAreaShape} which represents a {@link 
Rectangle}. This
+ * Specialization of a {@link Geo3dShape} which represents a {@link 
Rectangle}. This
  * class is used for geohashing.
  *
  * @lucene.experimental
  */
-public class Geo3dRectangleShape extends Geo3dAreaShape 
implements Rectangle {
-
-  //bounds object to return the max and min latitude and longitude
-  private volatile  LatLonBounds bounds; // lazy initialized
+public class Geo3dRectangleShape extends Geo3dShape implements 
Rectangle {
+
+  private double minX;
+  private double maxX;
+  private double minY;
+  private double maxY;
+
+  public Geo3dRectangleShape(final GeoBBox shape,
+ final SpatialContext spatialcontext,
+ double minX,
+ double maxX,
+ double minY,
+ double maxY) {
+super(shape, spatialcontext);
+this.minX = minX;
+this.maxX = maxX;
+this.minY = minY;
+this.maxY = maxY;
+  }
 
   public Geo3dRectangleShape(final GeoBBox shape, final SpatialContext 
spatialcontext) {
 super(shape, spatialcontext);
+setBounds();
   }
 
+
+
   /**
-   * Get the bounds from the wrapped GeoBBox.
+   * Set the bounds from the wrapped GeoBBox.
* @return The bounds
*/
-  private LatLonBounds getBounds() {
-LatLonBounds bounds  = this.bounds;//volatile read once
-if (bounds == null) {
-  bounds = new LatLonBounds();
-  shape.getBounds(bounds);
-  this.bounds = bounds;
-}
-return bounds;
+  private void setBounds() {
--- End diff --

minor: if this method accepted the shape field as a parameter, it would be 
more clear from where the boundaries are coming from.  Or give it a longer name 
perhaps like setBoundsFromShape.


---

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

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138328560
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dRectangleShape.java
 ---
@@ -30,32 +30,49 @@
 import org.locationtech.spatial4j.shape.SpatialRelation;
 
 /**
- * Specialization of a {@link Geo3dAreaShape} which represents a {@link 
Rectangle}. This
+ * Specialization of a {@link Geo3dShape} which represents a {@link 
Rectangle}. This
  * class is used for geohashing.
--- End diff --

minor: not need to say "this class is used for geohashing".  It could be 
used for a variety of purposes, notably a query for a rectangular map area.


---

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

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138329683
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java
 ---
@@ -14,70 +14,69 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
+
 package org.apache.lucene.spatial.spatial4j;
 
+import org.apache.lucene.spatial3d.geom.GeoArea;
+import org.apache.lucene.spatial3d.geom.GeoAreaFactory;
+import org.apache.lucene.spatial3d.geom.GeoAreaShape;
+import org.apache.lucene.spatial3d.geom.GeoBBox;
+import org.apache.lucene.spatial3d.geom.GeoBBoxFactory;
+import org.apache.lucene.spatial3d.geom.GeoPoint;
+import org.apache.lucene.spatial3d.geom.LatLonBounds;
 import org.locationtech.spatial4j.context.SpatialContext;
 import org.locationtech.spatial4j.distance.DistanceUtils;
 import org.locationtech.spatial4j.shape.Point;
 import org.locationtech.spatial4j.shape.Rectangle;
 import org.locationtech.spatial4j.shape.Shape;
 import org.locationtech.spatial4j.shape.SpatialRelation;
-import org.locationtech.spatial4j.shape.impl.RectangleImpl;
-import org.apache.lucene.spatial3d.geom.LatLonBounds;
-import org.apache.lucene.spatial3d.geom.GeoArea;
-import org.apache.lucene.spatial3d.geom.GeoAreaFactory;
-import org.apache.lucene.spatial3d.geom.GeoPoint;
-import org.apache.lucene.spatial3d.geom.GeoShape;
-import org.apache.lucene.spatial3d.geom.PlanetModel;
 
 /**
- * A Spatial4j Shape wrapping a {@link GeoShape} ("Geo3D") -- a 3D planar 
geometry based Spatial4j Shape implementation.
+ * A Spatial4j Shape wrapping a {@link GeoAreaShape} ("Geo3D") -- a 3D 
planar geometry
+ * based Spatial4j Shape implementation.
  * Geo3D implements shapes on the surface of a sphere or ellipsoid.
  *
+ * @param  is the type of {@link GeoAreaShape}
+ *
  * @lucene.experimental
  */
-public class Geo3dShape implements Shape {
-  /** The required size of this adjustment depends on the actual planetary 
model chosen.
-   * This value is big enough to account for WGS84. */
-  protected static final double ROUNDOFF_ADJUSTMENT = 0.05;
 
-  public final SpatialContext ctx;
-  public final GeoShape shape;
-  public final PlanetModel planetModel;
+public class Geo3dShape implements Shape {
 
-  private volatile Rectangle boundingBox = null; // lazy initialized
+  protected final SpatialContext spatialcontext;
 
-  public Geo3dShape(final GeoShape shape, final SpatialContext ctx) {
-this(PlanetModel.SPHERE, shape, ctx);
-  }
+  protected T shape;
+  protected volatile Rectangle boundingBox = null; // lazy initialized
+  protected volatile Point center = null; // lazy initialized
 
-  public Geo3dShape(final PlanetModel planetModel, final GeoShape shape, 
final SpatialContext ctx) {
-if (!ctx.isGeo()) {
-  throw new IllegalArgumentException("SpatialContext.isGeo() must be 
true");
-}
-this.ctx = ctx;
-this.planetModel = planetModel;
+  public Geo3dShape(final T shape, final SpatialContext spatialcontext){
+this.spatialcontext = spatialcontext;
 this.shape = shape;
   }
 
   @Override
-  public SpatialContext getContext() {
-return ctx;
-  }
-
-  @Override
   public SpatialRelation relate(Shape other) {
-if (other instanceof Rectangle)
-  return relate((Rectangle)other);
-else if (other instanceof Point)
-  return relate((Point)other);
-else
-  throw new RuntimeException("Unimplemented shape relationship 
determination: " + other.getClass());
+if (other instanceof Geo3dShape){
+  int relationship = 
shape.getRelationship(((Geo3dShape)other).shape);
--- End diff --

in the keeping of the style of other Shape classes, I suggest extracting a 
public overloaded method accepting Geo3dShape type


---

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

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138331367
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java
 ---
@@ -96,45 +95,25 @@ else if (relationship == GeoArea.DISJOINT)
   }
 
   protected SpatialRelation relate(Point p) {
-// Create a GeoPoint
-GeoPoint point = new GeoPoint(planetModel, p.getY()* 
DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS);
+GeoPoint point = new GeoPoint(shape.getPlanetModel(), p.getY()* 
DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS);
 if (shape.isWithin(point)) {
-  // Point within shape
   return SpatialRelation.CONTAINS;
 }
 return SpatialRelation.DISJOINT;
   }
 
-
-
   @Override
   public Rectangle getBoundingBox() {
 Rectangle bbox = this.boundingBox;//volatile read once
 if (bbox == null) {
   LatLonBounds bounds = new LatLonBounds();
   shape.getBounds(bounds);
-  double leftLon;
-  double rightLon;
-  if (bounds.checkNoLongitudeBound()) {
-leftLon = -180.0;
-rightLon = 180.0;
-  } else {
-leftLon = bounds.getLeftLongitude().doubleValue() * 
DistanceUtils.RADIANS_TO_DEGREES;
-rightLon = bounds.getRightLongitude().doubleValue() * 
DistanceUtils.RADIANS_TO_DEGREES;
-  }
-  double minLat;
-  if (bounds.checkNoBottomLatitudeBound()) {
-minLat = -90.0;
-  } else {
-minLat = bounds.getMinLatitude().doubleValue() * 
DistanceUtils.RADIANS_TO_DEGREES;
-  }
-  double maxLat;
-  if (bounds.checkNoTopLatitudeBound()) {
-maxLat = 90.0;
-  } else {
-maxLat = bounds.getMaxLatitude().doubleValue() * 
DistanceUtils.RADIANS_TO_DEGREES;
-  }
-  bbox = new RectangleImpl(leftLon, rightLon, minLat, maxLat, 
ctx).getBuffered(ROUNDOFF_ADJUSTMENT, ctx);
--- End diff --

I presume you have found this ROUNDOFF_ADJUSTMENT to be no longer necessary 
for tests to pass?


---

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

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138331920
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShapeFactory.java
 ---
@@ -125,7 +125,12 @@ public Point pointXY(double x, double y) {
 
   @Override
   public Point pointXYZ(double x, double y, double z) {
--- End diff --

x,y,z here is horizontal (longitude), vertical (latitude), and some 
user-defined value.  It's not geo-centric coordinates as is found commonly in 
Geo3d.  This method is called by the WKT parser (and perhaps GeoJSON?) if the 
input format has a 3rd dimension to it.


---

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

[GitHub] lucene-solr pull request #246: LUCENE-7951: New wrapper classes for Geo3d

[dsmiley]

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

https://github.com/apache/lucene-solr/pull/246#discussion_r138328277
  
--- Diff: 
lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dDistanceCalculator.java
 ---
@@ -70,7 +71,22 @@ public boolean within(Point from, double toX, double 
toY, double distance) {
 
   @Override
   public Point pointOnBearing(Point from, double distDEG, double 
bearingDEG, SpatialContext ctx, Point reuse) {
-throw new UnsupportedOperationException();
+double dist = DistanceUtils.DEGREES_TO_RADIANS * distDEG;
+double bearing = DistanceUtils.DEGREES_TO_RADIANS * bearingDEG;
+Geo3dPointShape geoFrom = (Geo3dPointShape) from;
+GeoPoint point = (GeoPoint)geoFrom.shape;
+
--- End diff --

Can you please add the name of this formula (if there is one) and/or a URL 
for further info?


---

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7966:
-

Dawid: i didn't really add new checks in the patch: I converted a bunch of 
existing checks to the new Objects.checkXXX methods. I think any difference in 
exception messages is not a big deal, actually i like the consistency and like 
the newer exception messages (see the unit tests for those: i emulated what 
java 9 returns in the java 8 methods).

The only place where there are new "checks" is where we use 
Arrays.compare/equals/mismatch. Those methods are defined in the jdk as safe, 
of course, and as I mentioned here, the existing comparator/etc methods we have 
are not very safe. See especially the prefix-coding corner cases I ran into 
here :) 
For those methods, the hope is that its still net/net drowned out: and 
hopefully definitely compensated by the fact that these methods no longer go 
one-byte-at-a-time.

In all cases none of this stuff should really be a hotspot for lucene. IMO we 
should be encouraging more safety/checks/reliability, and thats the goal here.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testCursorMarkNoSort

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_5B04FF806F88DC0-001\tempDir-001

at 
__randomizedtesting.SeedInfo.seed([5B04FF806F88DC0:28BB05A06D19DDF9]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parent which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.

If i change it to something like:

={!parent which="parent:images"}(database:"images_child" AND 
geo:[38.671875,-101.25 TO 41.30859375,-95.2734375])

It does seem to work but obviously it shouldn't behave like this.


  was:
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parent which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> =id,priref,[child parentFilter=parent:images]=database:"images"
> Everything works ok the correct children are returned.
> Now if I add a fq parent which filters on children:
> ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }
> This child document belongs to a different parent record.
> If i change it to something like:
> ={!parent which="parent:images"}(database:"images_child" AND 
> geo:[38.671875,-101.25 TO 41.30859375,-95.2734375])
> It does seem to work but obviously it shouldn't behave like this.



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

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

[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7967:
--

There is no hurry so please just have a look whenever you have time. 

Thanks!

 

> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parent which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.


  was:
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> =id,priref,[child parentFilter=parent:images]=database:"images"
> Everything works ok the correct children are returned.
> Now if I add a fq parent which filters on children:
> ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }
> This child document belongs to a different parent record.



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

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

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.


  was:
When I query for child documents like

*=id,priref,[child parentFilter=parent:images]=database:"images"*

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

*={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]*

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> =id,priref,[child parentFilter=parent:images]=database:"images"
> Everything works ok the correct children are returned.
> Now if I add a fq parem which filters on children:
> ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }
> This child document belongs to a different parent record.



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

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

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

{{=id,priref,[child parentFilter=parent:images]=database:"images"}}

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

{{ ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375] }}

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.


  was:
When I query for child documents like

{{=id,priref,[child parentFilter=parent:images]=database:"images"}}

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

{{={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]}}

Suddenly I see incorrect children being returned.
{{
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}}}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> {{=id,priref,[child parentFilter=parent:images]=database:"images"}}
> Everything works ok the correct children are returned.
> Now if I add a fq parem which filters on children:
> {{ ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375] }}
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }
> This child document belongs to a different parent record.



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

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

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

*=id,priref,[child parentFilter=parent:images]=database:"images"*

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

*={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]*

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.


  was:
When I query for child documents like

{{=id,priref,[child parentFilter=parent:images]=database:"images"}}

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

{{ ={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375] }}

Suddenly I see incorrect children being returned.
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> *=id,priref,[child parentFilter=parent:images]=database:"images"*
> Everything works ok the correct children are returned.
> Now if I add a fq parem which filters on children:
> *={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]*
> Suddenly I see incorrect children being returned.
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }
> This child document belongs to a different parent record.



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

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

[jira] [Updated] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

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

Chris de Kok updated SOLR-11353:

Description: 
When I query for child documents like

{{=id,priref,[child parentFilter=parent:images]=database:"images"}}

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

{{={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]}}

Suddenly I see incorrect children being returned.
{{
{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}}}

This child document belongs to a different parent record.


  was:
When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.

{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.



> Incorrect children returned on facet query
> --
>
> Key: SOLR-11353
> URL: https://issues.apache.org/jira/browse/SOLR-11353
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Chris de Kok
>  Labels: parent, parentchild
>
> When I query for child documents like
> {{=id,priref,[child parentFilter=parent:images]=database:"images"}}
> Everything works ok the correct children are returned.
> Now if I add a fq parem which filters on children:
> {{={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
> 41.30859375,-95.2734375]}}
> Suddenly I see incorrect children being returned.
> {{
> {
> "id":"images_397",
> "database":"images",
> "_childDocuments_":[
> {
> "database":"artists_child"
> }}}
> This child document belongs to a different parent record.



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

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

[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7967:
-

[~ivera] There is zero chance I can look at this today or tomorrow.


> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Created] (SOLR-11353) Incorrect children returned on facet query

[Chris de Kok (JIRA)]

Chris de Kok created SOLR-11353:
---

 Summary: Incorrect children returned on facet query
 Key: SOLR-11353
 URL: https://issues.apache.org/jira/browse/SOLR-11353
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Chris de Kok


When I query for child documents like

=id,priref,[child parentFilter=parent:images]=database:"images"

Everything works ok the correct children are returned.
Now if I add a fq parem which filters on children:

={!parent which="parent:images"}geo:[38.671875,-101.25 TO 
41.30859375,-95.2734375]

Suddenly I see incorrect children being returned.

{
"id":"images_397",
"database":"images",
"_childDocuments_":[
{
"database":"artists_child"
}

This child document belongs to a different parent record.




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

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

[jira] [Assigned] (LUCENE-7967) GeoDegeneratePoint in Pole

[Karl Wright (JIRA)]

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

Karl Wright reassigned LUCENE-7967:
---

Assignee: Karl Wright

> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Updated] (LUCENE-7967) GeoDegeneratePoint in Pole

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7967:
-
Attachment: LUCENE-7967.patch

Test attached

> GeoDegeneratePoint in Pole
> --
>
> Key: LUCENE-7967
> URL: https://issues.apache.org/jira/browse/LUCENE-7967
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-7967.patch
>
>
> Hi [~daddywri],
> This a small thing that shows up during the effort of integrating the library 
> with Spatial4J. if we have a degenerated point in the pole and you create a 
> point in the pole, it can happen that the new point is not within the 
> degenerated point.
> I attach a test case.
> Thanks,
> I.



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

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

[jira] [Created] (LUCENE-7967) GeoDegeneratePoint in Pole

[Ignacio Vera (JIRA)]

Ignacio Vera created LUCENE-7967:


 Summary: GeoDegeneratePoint in Pole
 Key: LUCENE-7967
 URL: https://issues.apache.org/jira/browse/LUCENE-7967
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ignacio Vera
Priority: Minor


Hi [~daddywri],

This a small thing that shows up during the effort of integrating the library 
with Spatial4J. if we have a degenerated point in the pole and you create a 
point in the pole, it can happen that the new point is not within the 
degenerated point.

I attach a test case.

Thanks,

I.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20457/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestPullReplicaErrorHandling

Error Message:
file handle leaks: 
[FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestPullReplicaErrorHandling_B4ABD2DDB31285C7-001/index-MMapDirectory-007/write.lock)]

Stack Trace:
java.lang.RuntimeException: file handle leaks: 
[FileChannel(/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestPullReplicaErrorHandling_B4ABD2DDB31285C7-001/index-MMapDirectory-007/write.lock)]
at __randomizedtesting.SeedInfo.seed([B4ABD2DDB31285C7]:0)
at org.apache.lucene.mockfile.LeakFS.onClose(LeakFS.java:63)
at 
org.apache.lucene.mockfile.FilterFileSystem.close(FilterFileSystem.java:77)
at 
org.apache.lucene.mockfile.FilterFileSystem.close(FilterFileSystem.java:78)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:228)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.Exception
at org.apache.lucene.mockfile.LeakFS.onOpen(LeakFS.java:46)
at 
org.apache.lucene.mockfile.HandleTrackingFS.callOpenHook(HandleTrackingFS.java:81)
at 
org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:197)
at 
org.apache.lucene.mockfile.HandleTrackingFS.newFileChannel(HandleTrackingFS.java:166)
at java.nio.channels.FileChannel.open(FileChannel.java:287)
at java.nio.channels.FileChannel.open(FileChannel.java:335)
at 
org.apache.lucene.store.NativeFSLockFactory.obtainFSLock(NativeFSLockFactory.java:125)
at 
org.apache.lucene.store.FSLockFactory.obtainLock(FSLockFactory.java:41)
at 
org.apache.lucene.store.BaseDirectory.obtainLock(BaseDirectory.java:45)
at 
org.apache.lucene.store.FilterDirectory.obtainLock(FilterDirectory.java:104)
at org.apache.lucene.index.IndexWriter.(IndexWriter.java:947)
at 
org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:119)
at 
org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:94)
at 
org.apache.solr.update.DefaultSolrCoreState.createMainIndexWriter(DefaultSolrCoreState.java:257)
at 
org.apache.solr.update.DefaultSolrCoreState.changeWriter(DefaultSolrCoreState.java:220)
at 
org.apache.solr.update.DefaultSolrCoreState.openIndexWriter(DefaultSolrCoreState.java:245)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:608)
at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:332)
at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419)
at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$12(ReplicationHandler.java:1183)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
... 1 more


FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testPoissonDistribution

Error Message:
expected:<100.078201> but was:<96.73735849584953>

Stack Trace:
java.lang.AssertionError: expected:<100.078201> but 
was:<96.73735849584953>
at 
__randomizedtesting.SeedInfo.seed([43A82462DE2BC60B:DBB8DBC37C92BE77]:0)
at org.junit.Assert.fail(Assert.java:93)
at 

[JENKINS] Lucene-Solr-7.0-Windows (64bit/jdk1.8.0_144) - Build # 151 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/151/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testReloadDuringBuild

Error Message:
junit.framework.AssertionFailedError: Expected outer exception RuntimeException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Expected outer exception RuntimeException
at 
__randomizedtesting.SeedInfo.seed([4B5FDB626D3E9910:A2E7F31478171411]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testReloadDuringBuild(InfixSuggestersTest.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: junit.framework.AssertionFailedError: Expected outer exception 
RuntimeException
at 

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7966:
-


I wholeheartedly agree -- it's fascinating stuff and thanks to Robert and you 
for starting this. 

bq. We should compare:

Those bound checks will cost something -- the fact they're intrinsic methods 
doesn't mean they're free. There's another dimension to your list: the CPU 
architecture hotspot generates code for... I didn't look at the code, but those 
intrinsics will vary depending on what the CPU has to offer. So regardless of 
easier ideal graph optimizations (which is great!) there will be some assembly 
injected to make those bound checks work, especially on CPUs with less complex 
instruction set.

Like I said: very interesting stuff to work on and benchmark!

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7966:
---

bq. As for performance I wonder what the actual gain will be - I bet you a beer 
the performance will be within the noise levels on larger tasks.

Of course, we have to test this how much it gains! We should compare:
- Java 8 without and with patch
- Java 9 without and with patch

But the main reason is to make our code "safer". We omitted bounds checks at 
many places, because the overhead was immense (e.g. BytesRef, 
ByteBufferIndexInput,...) and sometimes not even added asserts. If we make that 
code safer, it will not be slower in Java 9. So we can say: We still work with 
Java 8, but you should really use Java 9 for optimal performance.

Robert just started with the important stuff, but there is room for 
improvements.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 44 - Still Unstable

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomBig

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([C52642C81A5F622D]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.spatial3d.TestGeo3DPoint

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

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


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

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

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([CEDA8C94DD855290:468EB34E73793F68]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:174)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)

[jira] [Closed] (LUCENE-7931) SpanNotQuery has bug？

[jin jing (JIRA)]

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

jin jing closed LUCENE-7931.

Resolution: Not A Problem

> SpanNotQuery  has bug？
> --
>
> Key: LUCENE-7931
> URL: https://issues.apache.org/jira/browse/LUCENE-7931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3.1
>Reporter: jin jing
>
> i find when use SpanNotQuery and the exclud key word like  "not"  "or"  will 
> give a error result
> example：
> doc1：the quick brown fox jumps over the lazy dog
> doc2：the quick red fox jumps over the sleepy cat
> doc3：the quick brown fox jumps over the lazy NOT dog
> String queryStringStart = "dog";  
> String queryStringEnd = "quick";  
> String excludeString = "NOT";  
> SpanQuery queryStart = new SpanTermQuery(new Term("text",queryStringStart));  
> SpanQuery queryEnd = new SpanTermQuery(new Term("text",queryStringEnd));  
> SpanQuery excludeQuery = new SpanTermQuery(new Term("text",excludeString));  
> SpanQuery spanNearQuery = new SpanNearQuery(  
> new SpanQuery[] {queryStart,queryEnd}, 7, false, false);  
>   
>  SpanNotQuery spanNotQuery = new SpanNotQuery(spanNearQuery, excludeQuery, 
> 4,3); 
> then  this will return doc1 and doc3.  so i think it is a bug. 



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

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

[jira] [Commented] (LUCENE-7931) SpanNotQuery has bug？

[jin jing (JIRA)]

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

jin jing commented on LUCENE-7931:
--

yes it is.thank you

> SpanNotQuery  has bug？
> --
>
> Key: LUCENE-7931
> URL: https://issues.apache.org/jira/browse/LUCENE-7931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3.1
>Reporter: jin jing
>
> i find when use SpanNotQuery and the exclud key word like  "not"  "or"  will 
> give a error result
> example：
> doc1：the quick brown fox jumps over the lazy dog
> doc2：the quick red fox jumps over the sleepy cat
> doc3：the quick brown fox jumps over the lazy NOT dog
> String queryStringStart = "dog";  
> String queryStringEnd = "quick";  
> String excludeString = "NOT";  
> SpanQuery queryStart = new SpanTermQuery(new Term("text",queryStringStart));  
> SpanQuery queryEnd = new SpanTermQuery(new Term("text",queryStringEnd));  
> SpanQuery excludeQuery = new SpanTermQuery(new Term("text",excludeString));  
> SpanQuery spanNearQuery = new SpanNearQuery(  
> new SpanQuery[] {queryStart,queryEnd}, 7, false, false);  
>   
>  SpanNotQuery spanNotQuery = new SpanNotQuery(spanNearQuery, excludeQuery, 
> 4,3); 
> then  this will return doc1 and doc3.  so i think it is a bug. 



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

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

[jira] [Commented] (SOLR-11352) Automatic testing of all Solr examples

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-11352:


Smoke tests or nightly, pretty please... :)

> Automatic testing of all Solr examples
> --
>
> Key: SOLR-11352
> URL: https://issues.apache.org/jira/browse/SOLR-11352
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples, Tests
>Reporter: Jan Høydahl
>
> We have seen in SOLR-11313, SOLR-11315 and SOLR-11348, bugs keep creeping 
> into the Solr examples and are not caught until after a release or if we're 
> lucky by chance in some release candidate.
> We should add unit tests or smoke tests that
> * spins up Solr with all examples in turn, check for success
> * for example requiring manual steps such as feeding data, also test that
> * fail fast on missing libraries
> * should ideally also fail if any WARN in logs during normal use cases



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

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7966:
-

Uwe: I understand the reason for this patch. My point was just that you do lose 
some verbosity in the exception message, that's all. 

As for performance I wonder what the actual gain will be - I bet you a beer the 
performance will be within the noise levels on larger tasks. :)

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+181) - Build # 399 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/399/
Java: 32bit/jdk-9-ea+181 -server -XX:+UseParallelGC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([BF555CF4DFCBEE40:3C23030609B2E0E1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestCloudRecovery.corruptedLogTest(TestCloudRecovery.java:184)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12955 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestCloudRecovery
   [junit4]   2> 1755238 INFO  
(SUITE-TestCloudRecovery-seed#[BF555CF4DFCBEE40]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7966:
---

bq. One thing that we lose here is the verbosity of exception message (field 
names, doc ids)

Yes, but there is a reason to change to the new methods! Robert did not add 
that to the issue description. I directed him on the weekend during a private 
chat to the new methods (which was caused by my comment in a former issue with 
the missing check).

To make it short: Those methods are highly optimized by Hotspot. In fact they 
replaced the bounds checks in ByteBuffers and other places throughout the JDK 
to call those methods instead of hardcoded if/then/else statements. I also 
talked with Rémi Forax about it this summer to get more information. He 
strongly recommends to use the new methods from Objects and Arrays instead of 
manually crafted if/then/else checks. The reason is: Those methods are 
intrinsics and are more or less replaced by highly optimized bounds check code. 
In addition, if you add several levels of bounds checks more magic is 
happening: a high level method checks bounds and call lower level method, which 
does bounds checks again (e.g., a ByteBuffer in the JDK), and this lower level 
method again accesses a Java array (that implcitely does bounds checks, too), - 
then Hotspot adds all calls of those Objects' index check methods to the 
internal AST and it can then safely eliminate all of them except one. And if it 
sees that a variable is unsigned it will also remove negative checks ... and so 
on. This was done, because they had very hard problems in eliminating those 
checks everywhere when somebody creates an if statement (there are tons of ways 
to do the same check with if statements!), the OpenJDK developers argued to use 
a intrinsic replacement method instead of hardcoded bounds checks with hundreds 
of variants. By that they only have to optimize a single "if statement" and can 
replace it by assembly code and remove duplicates.

Even shorter: If you use the Objects methods instead of if statements, you can 
add more safety to your code, as duplicate checks are eliminated. So we can 
even start to add checks into BytesRef. Or we can remove the stupid try/catch 
blocks in ByteBufferIndexInput.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7966:
-

Overall, pretty neat and an uncharted territory (I didn't see anybody using 
this JEP yet!). One thing that we lose here is the verbosity of exception 
message (field names, doc ids); for example:
{code}
-if (dimension < 0 || dimension >= type.pointDimensionCount()/2) {
-  throw new IllegalArgumentException("dimension request (" + dimension +
-  ") out of bounds for field (name=" + name + " dimensions=" + 
type.pointDimensionCount()/2 + "). ");
-}
+FutureObjects.checkIndex(dimension, type.pointDimensionCount()/2);
{code}

Bit since these are exceptional cases I don't think they'd be particularly 
useful for diagnostics unless you can repeat the problem (and then you can 
add/debug what you like).

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7966:
-

bq. +  

Not if you {{fork=true}} because then the task is executed via cmd which 
resolves file extensions automatically.


> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Commented] (LUCENE-7931) SpanNotQuery has bug？

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-7931:
---

"not" is a stopword, and is removed by the StandardAnalyzer by default.

> SpanNotQuery  has bug？
> --
>
> Key: LUCENE-7931
> URL: https://issues.apache.org/jira/browse/LUCENE-7931
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3.1
>Reporter: jin jing
>
> i find when use SpanNotQuery and the exclud key word like  "not"  "or"  will 
> give a error result
> example：
> doc1：the quick brown fox jumps over the lazy dog
> doc2：the quick red fox jumps over the sleepy cat
> doc3：the quick brown fox jumps over the lazy NOT dog
> String queryStringStart = "dog";  
> String queryStringEnd = "quick";  
> String excludeString = "NOT";  
> SpanQuery queryStart = new SpanTermQuery(new Term("text",queryStringStart));  
> SpanQuery queryEnd = new SpanTermQuery(new Term("text",queryStringEnd));  
> SpanQuery excludeQuery = new SpanTermQuery(new Term("text",excludeString));  
> SpanQuery spanNearQuery = new SpanNearQuery(  
> new SpanQuery[] {queryStart,queryEnd}, 7, false, false);  
>   
>  SpanNotQuery spanNotQuery = new SpanNotQuery(spanNearQuery, excludeQuery, 
> 4,3); 
> then  this will return doc1 and doc3.  so i think it is a bug. 



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

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

Solr trainer needed - Taiwan

[Bernard Szlachta]

We need a trainer to deliver Solr course in Taiwan.
If you interested please ping me.

 *Bernard Szlachta **（**安博） *
*NobleProg**®*  | *The World's Local Training Provider*
*Mobile *(+86) 152-0139-4024  *Skype  *"nobleprog"
*Office*（+86）01084549609   *Web: *www.nobleprog.cn
Switchboard : (+86) 400-6116-540, Mob (*UK*)： (+44) 7929-173-122
相关促销活动请点击: 促销活动 
关于加盟商信息请点击: 加盟商信息

[jira] [Commented] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7966:
---

Hi Robert,
this is wonderful. I am happy that our discussion about this helped. Nice that 
you used the example on the ANT webpage: 
https://ant.apache.org/manual/Tasks/jar.html#jep238-example

The problem is that you currently need Java 9 to compile, too. I'd make it 
optional. My alternative idea would be: Make a stub clone of the Objects/Arrays 
classes without code from the JDK and use them as bootclasspath. I can try to 
work with that.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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

[jira] [Updated] (LUCENE-7966) build mr-jar and use some java 9 methods if available

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7966:

Attachment: LUCENE-7966.patch

Updated patch. I fixed the fallout better (don't encode wasteful bytes for the 
first term, no bytes need to be written) from detecting out-of-order 
comparisons in prefix-coding methods, this annoyingly was always related to the 
empty string: happened with bytesDifference([], [])/sortKeyLength([], []). 

To me it makes sense to detect the malfunction (-1 return from mismatch) rather 
than just leniently doing something strange for duplicate terms, it may detect 
bugs.

> build mr-jar and use some java 9 methods if available
> -
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Robert Muir
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking 
> methods in java 9 for example, without waiting for lucene 10 or something. If 
> we build an MR-jar, we can start migrating our code to use java 9 methods 
> right now, it will use optimized methods from java 9 when thats available, 
> otherwise fall back to java 8 code.  
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java 
> methods. This way, we can simply directly replace call sites with java 9 
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only 
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and 
> very lenient for example, passing invalid offsets at times and relying on 
> compare methods not throwing exceptions, etc. I fixed all the instances in 
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also 
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have 
> not removed that one yet.



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

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