[JENKINS-EA] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13686 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13686/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([3AE66A8385F46872]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:746)




Build Log:
[...truncated 10908 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_3AE66A8385F46872-001/init-core-data-001
   [junit4]   2> 989227 INFO  
(SUITE-HttpPartitionTest-seed#[3AE66A8385F46872]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 989230 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 989231 INFO  (Thread-3606) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 989231 INFO  (Thread-3606) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 989331 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.ZkTestServer start zk server on port:49168
   [junit4]   2> 989331 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 989331 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 989333 INFO  (zkCallback-808-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@6db59228 
name:ZooKeeperConnection Watcher:127.0.0.1:49168 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 989333 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 989333 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 989333 INFO  
(TEST-HttpPartitionTest.test-seed#[3AE66A8385F46872]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2

[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 299 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/299/

No tests ran.

Build Log:
[...truncated 12586 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/build.xml:520: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build.xml:394:
 java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at java.net.Socket.connect(Socket.java:528)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932)
at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850)
at 
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)

Total time: 6 minutes 46 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure
Setting 
LATEST1_8_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
Setting 
LATEST1_8_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8



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

[jira] [Commented] (SOLR-6683) Need a configurable parameter to control the doc number between peersync and the snapshot pull recovery

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-6683:


I've been staring at this for an hour, and cannot translate this from the words 
to something my mind can grasp.  Can you explain it with a detailed scenario 
where it doesn't work as expected?


> Need a configurable parameter to control the doc number between peersync and 
> the snapshot pull recovery
> ---
>
> Key: SOLR-6683
> URL: https://issues.apache.org/jira/browse/SOLR-6683
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 4.7
> Environment: Redhat Linux 64bit
>Reporter: Forest Soup
>Priority: Critical
>  Labels: performance
>
> If there are >100 docs gap between the recovering node and the good node, the 
> solr will do snap pull recovery instead of peersync.
> Can the 100 docs be configurable? For example, there can be 1, 1000, or 
> 10 docs gap between the good node and the node to recover.
> For 100 doc, a regular restart of a solr node will trigger a full recovery, 
> which is a huge impact to the performance of the running systems
> Thanks!



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

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 935 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/935/

2 tests failed.
REGRESSION:  org.apache.lucene.index.Test4GBStoredFields.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([86DC7899EA2DC74D]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.Test4GBStoredFields

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

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




Build Log:
[...truncated 1792 lines...]
   [junit4] Suite: org.apache.lucene.index.Test4GBStoredFields
   [junit4]   2> ago 22, 2015 11:14:50 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.index.Test4GBStoredFields
   [junit4]   2>1) Thread[id=2825, 
name=SUITE-Test4GBStoredFields-seed#[86DC7899EA2DC74D], state=RUNNABLE, 
group=TGRP-Test4GBStoredFields]
   [junit4]   2> at java.lang.Thread.getStackTrace(Thread.java:1589)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getThreadsWithTraces(ThreadLeakControl.java:690)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.formatThreadStacksFull(ThreadLeakControl.java:679)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.access$900(ThreadLeakControl.java:62)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2.evaluate(ThreadLeakControl.java:412)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:651)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$200(RandomizedRunner.java:138)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$1.run(RandomizedRunner.java:568)
   [junit4]   2>2) Thread[id=2826, 
name=TEST-Test4GBStoredFields.test-seed#[86DC7899EA2DC74D], state=RUNNABLE, 
group=TGRP-Test4GBStoredFields]
   [junit4]   2> at java.lang.Thread.yield(Native Method)
   [junit4]   2> at 
org.apache.lucene.store.MockIndexOutputWrapper.writeBytes(MockIndexOutputWrapper.java:139)
   [junit4]   2> at 
org.apache.lucene.store.MockIndexOutputWrapper.writeByte(MockIndexOutputWrapper.java:127)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.LZ4.encodeLiterals(LZ4.java:149)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.LZ4.encodeLastLiterals(LZ4.java:162)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.LZ4.compressHC(LZ4.java:544)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.CompressionMode$LZ4HighCompressor.compress(CompressionMode.java:180)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.flush(CompressingStoredFieldsWriter.java:235)
   [junit4]   2> at 
org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.finishDocument(CompressingStoredFieldsWriter.java:165)
   [junit4]   2> at 
org.apache.lucene.index.DefaultIndexingChain.finishStoredFields(DefaultIndexingChain.java:270)
   [junit4]   2> at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:311)
   [junit4]   2> at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:234)
   [junit4]   2> at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:450)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1475)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1254)
   [junit4]   2> at 
org.apache.lucene.index.Test4GBStoredFields.test(Test4GBStoredFields.java:75)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:606)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.jav

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.7.0_80) - Build # 5057 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/5057/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.lucene.store.TestNativeFSLockFactory.testStressLocks

Error Message:
Captured an uncaught exception in thread: Thread[id=685, name=Thread-470, 
state=RUNNABLE, group=TGRP-TestNativeFSLockFactory]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=685, name=Thread-470, state=RUNNABLE, 
group=TGRP-TestNativeFSLockFactory]
at 
__randomizedtesting.SeedInfo.seed([ADED0EFB1B3DFADE:F3DC4006079132B8]:0)
Caused by: java.lang.AssertionError: hit unexpected NoSuchFileException: 
file=_h.cfs
at __randomizedtesting.SeedInfo.seed([ADED0EFB1B3DFADE]:0)
at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:752)
at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:530)
at 
org.apache.lucene.index.IndexFileDeleter.deleteNewFiles(IndexFileDeleter.java:733)
at 
org.apache.lucene.index.IndexWriter.deleteNewFiles(IndexWriter.java:4700)
at 
org.apache.lucene.index.DocumentsWriter$DeleteNewFilesEvent.process(DocumentsWriter.java:735)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4757)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4748)
at org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3129)
at org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3096)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1078)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1123)
at 
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)




Build Log:
[...truncated 1104 lines...]
   [junit4] Suite: org.apache.lucene.store.TestNativeFSLockFactory
   [junit4] IGNOR/A 0.02s J1 | TestNativeFSLockFactory.testDeleteLockFile
   [junit4]> Assumption #1: test requires the ability to delete a locked 
file(throwable: java.io.IOException: cannot delete file: test.lock, a virus 
scanner has it open)
   [junit4]   2> avg 22, 2015 4:49:09 PM 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-470,5,TGRP-TestNativeFSLockFactory]
   [junit4]   2> java.lang.AssertionError: hit unexpected NoSuchFileException: 
file=_h.cfs
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([ADED0EFB1B3DFADE]:0)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:752)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:530)
   [junit4]   2>at 
org.apache.lucene.index.IndexFileDeleter.deleteNewFiles(IndexFileDeleter.java:733)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.deleteNewFiles(IndexWriter.java:4700)
   [junit4]   2>at 
org.apache.lucene.index.DocumentsWriter$DeleteNewFilesEvent.process(DocumentsWriter.java:735)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4757)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4748)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.doFlush(IndexWriter.java:3129)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.flush(IndexWriter.java:3096)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1078)
   [junit4]   2>at 
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1123)
   [junit4]   2>at 
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestNativeFSLockFactory -Dtests.method=testStressLocks 
-Dtests.seed=ADED0EFB1B3DFADE -Dtests.slow=true -Dtests.locale=sr_ME_#Latn 
-Dtests.timezone=AST -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   4.89s J1 | TestNativeFSLockFactory.testStressLocks <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=685, name=Thread-470, state=RUNNABLE, 
group=TGRP-TestNativeFSLockFactory]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([ADED0EFB1B3DFADE:F3DC4006079132B8]:0)
   [junit4]> Caused by: java.lang.AssertionError: hit unexpected 
NoSuchFileException: file=_h.cfs
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([ADED0EFB1B3DFADE]:0)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:752)
   [junit4]>at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFile

[jira] [Commented] (SOLR-7948) MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7948:
---

Sadly, it doesn't seem that mapreduce.job.user.classpath.first or 
mapreduce.job.classloader can handle this conflict. I'm still experimenting, 
but jar harmonization might be the only solution. That would be a real bummer - 
sometimes it is not so easy to do.

> MapReduceIndexerTool of solr 5.2.1 doesn't work with hadoop 2.7.1
> -
>
> Key: SOLR-7948
> URL: https://issues.apache.org/jira/browse/SOLR-7948
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - MapReduce
>Affects Versions: 5.2.1
> Environment: OS:suse 11
> JDK:java version "1.7.0_65" 
> Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> HADOOP:hadoop 2.7.1 
> SOLR:5.2.1
>Reporter: davidchiu
>Assignee: Mark Miller
>
> When I used MapReduceIndexerTool of 5.2.1 to index files, I got follwoing 
> errors,but I used 4.9.0's MapReduceIndexerTool, it did work with hadoop 2.7.1.
> Exception ERROR as following:
> INFO  - 2015-08-20 11:44:45.155; [   ] org.apache.solr.hadoop.HeartBeater; 
> Heart beat reporting class is 
> org.apache.hadoop.mapreduce.task.TaskAttemptContextImpl
> INFO  - 2015-08-20 11:44:45.161; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Using this unpacked directory as 
> solr home: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.162; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Creating embedded Solr server with 
> solrHomeDir: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip,
>  fs: 
> DFS[DFSClient[clientName=DFSClient_attempt_1440040092614_0004_r_01_0_1678264055_1,
>  ugi=root (auth:SIMPLE)]], outputShardDir: 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.194; [   ] 
> org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for 
> directory: 
> '/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/'
> INFO  - 2015-08-20 11:44:45.206; [   ] org.apache.solr.hadoop.HeartBeater; 
> HeartBeat thread running
> INFO  - 2015-08-20 11:44:45.207; [   ] org.apache.solr.hadoop.HeartBeater; 
> Issuing heart beat for 1 threads
> INFO  - 2015-08-20 11:44:45.418; [   ] 
> org.apache.solr.hadoop.SolrRecordWriter; Constructed instance information 
> solr.home 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
>  
> (/usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip),
>  instance dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/,
>  conf dir 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/conf/,
>  writing index to solr.data.dir 
> hdfs://127.0.0.1:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1/data,
>  with permdir 
> hdfs://127.0.0.10:9000/tmp/outdir/reducers/_temporary/1/_temporary/attempt_1440040092614_0004_r_01_0/part-r-1
> INFO  - 2015-08-20 11:44:45.426; [   ] org.apache.solr.core.SolrXmlConfig; 
> Loading container configuration from 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip/solr.xml
> INFO  - 2015-08-20 11:44:45.474; [   ] 
> org.apache.solr.core.CorePropertiesLocator; Config-defined core root 
> directory: 
> /usr/local/hadoop/tmp/nm-local-dir/usercache/root/appcache/application_1440040092614_0004/container_1440040092614_0004_01_04/82f2eca9-d6eb-483b-960f-0d3b3b93788c.solr.zip
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> New CoreContainer 1656436773
> INFO  - 2015-08-20 11:44:45.503; [   ] org.apache.solr.core.CoreContainer; 
> Loading cores into CoreContainer 
> [instanceDir=/usr/local/hadoop/tmp/nm-loc

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_60) - Build # 5187 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5187/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.schema.TestCloudSchemaless: 
1) Thread[id=19362, name=SessionTracker, state=TIMED_WAITING, 
group=TGRP-TestCloudSchemaless] at java.lang.Object.wait(Native Method) 
at 
org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:146)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.schema.TestCloudSchemaless: 
   1) Thread[id=19362, name=SessionTracker, state=TIMED_WAITING, 
group=TGRP-TestCloudSchemaless]
at java.lang.Object.wait(Native Method)
at 
org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:146)
at __randomizedtesting.SeedInfo.seed([F6EDC9CBD3870CEA]:0)




Build Log:
[...truncated 10896 lines...]
   [junit4] Suite: org.apache.solr.schema.TestCloudSchemaless
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestCloudSchemaless_F6EDC9CBD3870CEA-001\init-core-data-001
   [junit4]   2> 2799299 INFO  
(SUITE-TestCloudSchemaless-seed#[F6EDC9CBD3870CEA]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 2799302 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2799302 INFO  (Thread-7166) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2799302 INFO  (Thread-7166) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2799402 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.ZkTestServer start zk server on port:65165
   [junit4]   2> 2799402 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2799403 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2799407 INFO  (zkCallback-3103-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@a484fdc name:ZooKeeperConnection 
Watcher:127.0.0.1:65165 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 2799407 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2799408 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2799408 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 2799410 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2799412 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2799413 INFO  (zkCallback-3104-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@2a75c32e 
name:ZooKeeperConnection Watcher:127.0.0.1:65165/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2799413 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2799413 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2799414 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 2799416 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 2799417 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 2799419 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 2799420 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-schemaless.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 2799421 INFO  
(TEST-TestCloudSchemaless.test-seed#[F6EDC9CBD3870CEA]) [] 
o.a.s

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13963 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13963/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
ERROR: SolrIndexSearcher opens=27 closes=26

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=27 closes=26
at __randomizedtesting.SeedInfo.seed([4758337A9E221C3B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233)
at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:746)


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

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=7719, name=searcherExecutor-3874-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=7719, name=searcherExecutor-3874-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:746)
at __randomizedtesting.SeedInfo.seed([4758337A9E221C3B]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1

[jira] [Commented] (SOLR-6915) SaslZkACLProvider and Kerberos Test Using MiniKdc

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-6915:
-

It can fail because it uses {{Calendar.getDefault()}}, hwich is the main issue 
with this code.

> SaslZkACLProvider and Kerberos Test Using MiniKdc
> -
>
> Key: SOLR-6915
> URL: https://issues.apache.org/jira/browse/SOLR-6915
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6915.patch, SOLR-6915.patch, fail.log, fail.log, 
> tests-failures.txt
>
>
> We should provide a ZkACLProvider that requires SASL authentication.  This 
> provider will be useful for administration in a kerberos environment.   In 
> such an environment, the administrator wants solr to authenticate to 
> zookeeper using SASL, since this is only way to authenticate with zookeeper 
> via kerberos.
> The authorization model in such a setup can vary, e.g. you can imagine a 
> scenario where solr owns (is the only writer of) the non-config znodes, but 
> some set of trusted users are allowed to modify the configs.  It's hard to 
> predict all the possibilities here, but one model that seems generally useful 
> is to have a model where solr itself owns all the znodes and all actions that 
> require changing the znodes are routed to Solr APIs.  That seems simple and 
> reasonable as a first version.
> As for testing, I noticed while working on SOLR-6625 that we don't really 
> have any infrastructure for testing kerberos integration in unit tests.  
> Internally, I've been testing using kerberos-enabled VM clusters, but this 
> isn't great since we won't notice any breakages until someone actually spins 
> up a VM.  So part of this JIRA is to provide some infrastructure for testing 
> kerberos at the unit test level (using Hadoop's MiniKdc, HADOOP-9848).



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

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

[jira] [Updated] (SOLR-7956) There are interrupts on shutdown in places that can cause ChannelAlreadyClosed exceptions which prevents proper closing of transaction logs.

[Mark Miller (JIRA)]

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

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

> There are interrupts on shutdown in places that can cause 
> ChannelAlreadyClosed exceptions which prevents proper closing of transaction 
> logs.
> 
>
> Key: SOLR-7956
> URL: https://issues.apache.org/jira/browse/SOLR-7956
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7956.patch
>
>
> Found this while beast testing HttpPartitionTest.



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

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

[jira] [Updated] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-6759:

Attachment: LUCENE-6699.patch

[~mikemccand] This patch reverts MINIMUM_RESOLUTION to 1e-12, and fixes the 
requirement for a high MINIMUM_RESOLUTION value another way.

All tests pass when this is done.  Since I've been adding tests every time your 
beasting finds something, that's meaningful.

> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
> Attachments: LUCENE-6699.patch
>
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[jira] [Commented] (SOLR-6915) SaslZkACLProvider and Kerberos Test Using MiniKdc

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-6915:
-

This happened again last night with locale {{uz_UZ_#Cyrl}}

We should maybe fix the test's locale

> SaslZkACLProvider and Kerberos Test Using MiniKdc
> -
>
> Key: SOLR-6915
> URL: https://issues.apache.org/jira/browse/SOLR-6915
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6915.patch, SOLR-6915.patch, fail.log, fail.log, 
> tests-failures.txt
>
>
> We should provide a ZkACLProvider that requires SASL authentication.  This 
> provider will be useful for administration in a kerberos environment.   In 
> such an environment, the administrator wants solr to authenticate to 
> zookeeper using SASL, since this is only way to authenticate with zookeeper 
> via kerberos.
> The authorization model in such a setup can vary, e.g. you can imagine a 
> scenario where solr owns (is the only writer of) the non-config znodes, but 
> some set of trusted users are allowed to modify the configs.  It's hard to 
> predict all the possibilities here, but one model that seems generally useful 
> is to have a model where solr itself owns all the znodes and all actions that 
> require changing the znodes are routed to Solr APIs.  That seems simple and 
> reasonable as a first version.
> As for testing, I noticed while working on SOLR-6625 that we don't really 
> have any infrastructure for testing kerberos integration in unit tests.  
> Internally, I've been testing using kerberos-enabled VM clusters, but this 
> isn't great since we won't notice any breakages until someone actually spins 
> up a VM.  So part of this JIRA is to provide some infrastructure for testing 
> kerberos at the unit test level (using Hadoop's MiniKdc, HADOOP-9848).



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13962 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13962/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseParallelGC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.SaslZkACLProviderTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=8467, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)2) Thread[id=8466, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)3) Thread[id=8464, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:516) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)4) Thread[id=8468, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)5) Thread[id=8465, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:746)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE 
scope at org.apache.solr.cloud.SaslZkACLProviderTest: 
   1) Thread[id=8467, name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Sched

RE: Ant/JUnit/Bash bug with RTL languages?

[Uwe Schindler]

It's a console issue. E.g. if you look on the logs with your internet browser 
on Jenkins' console log, at least my browser (Google Chrome) selects the RTL 
parts correctly, just try it.

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


> -Original Message-
> From: Robert Muir [mailto:rcm...@gmail.com]
> Sent: Friday, August 21, 2015 4:22 PM
> To: dev@lucene.apache.org
> Subject: Re: Ant/JUnit/Bash bug with RTL languages?
> 
> Yes exactly, Benson is correct. Look at an arabic text file with "cat"
> on your same console and see if its correct: usually its not.
> 
> On Fri, Aug 21, 2015 at 10:13 AM, Benson Margulies
>  wrote:
> > Isn't this all about how your console does the Unicode bidi algo, and
> > not about anything in the code?
> >
> >
> > On Fri, Aug 21, 2015 at 10:12 AM, Mike Drob 
> wrote:
> >> Hello,
> >>
> >> I noticed that when running tests, if the language selected is RTL
> >> then the "JUnit says hello" output is backwards. However, if I copy
> >> the output and try to paste it into firefox or gedit then the text is
> >> properly right-to-left.
> >>
> >> For example, when selecting hebrew, on my system it prints "
> >> says [shin-lamed-vav-mem]" instead of starting with [shin] on the
> >> right.
> >>
> >> This shouldn't be a high priority, since the tests themselves still
> >> pass, but I was wondering if that's something that we can fix or if
> >> the error is in a lower level - like the junit libs, or maybe even
> >> bash. Anybody have any ideas?
> >>
> >> Mike
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional commands, e-mail: dev-h...@lucene.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 301 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/301/

4 tests failed.
REGRESSION:  org.apache.solr.cloud.TestReplicaProperties.test

Error Message:
No live SolrServers available to handle this request:[http://127.0.0.1:50891, 
http://127.0.0.1:51270, http://127.0.0.1:44583, http://127.0.0.1:59831, 
http://127.0.0.1:56847]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:50891, http://127.0.0.1:51270, 
http://127.0.0.1:44583, http://127.0.0.1:59831, http://127.0.0.1:56847]
at 
__randomizedtesting.SeedInfo.seed([76ABD9EA6034B598:FEFFE630CEC8D860]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.ReplicaPropertiesBase.doPropertyAction(ReplicaPropertiesBase.java:51)
at 
org.apache.solr.cloud.TestReplicaProperties.clusterAssignPropertyTest(TestReplicaProperties.java:183)
at 
org.apache.solr.cloud.TestReplicaProperties.test(TestReplicaProperties.java:70)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapt

[jira] [Updated] (SOLR-7958) Move TestUtil#randomWhitespace to the test that is sole user

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-7958:

Attachment: SOLR-7958.patch

Patch moving the method (and removing unused static field member in the test)

> Move TestUtil#randomWhitespace to the test that is sole user
> 
>
> Key: SOLR-7958
> URL: https://issues.apache.org/jira/browse/SOLR-7958
> Project: Solr
>  Issue Type: Test
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Attachments: SOLR-7958.patch
>
>
> Followup issue to: LUCENE-6760
> {{TestUtil#randomWhitespace}} is only used by 
> {{org.apache.solr.search.ReturnFieldsTest#testWhitespace()}}
> After talking with Robert, this method is not useful for Lucene, so we should 
> move it to just this test.



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

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

[jira] [Commented] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6760:
---

Followup issue is SOLR-7958

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Created] (SOLR-7958) Move TestUtil#randomWhitespace to the test that is sole user

[Uwe Schindler (JIRA)]

Uwe Schindler created SOLR-7958:
---

 Summary: Move TestUtil#randomWhitespace to the test that is sole 
user
 Key: SOLR-7958
 URL: https://issues.apache.org/jira/browse/SOLR-7958
 Project: Solr
  Issue Type: Test
Reporter: Uwe Schindler
Assignee: Uwe Schindler


Followup issue to: LUCENE-6760

{{TestUtil#randomWhitespace}} is only used by 
{{org.apache.solr.search.ReturnFieldsTest#testWhitespace()}}

After talking with Robert, this method is not useful for Lucene, so we should 
move it to just this test.



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

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

[jira] [Resolved] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-6760.
---
   Resolution: Fixed
Fix Version/s: 5.4
   Trunk

I will open followup issue to move the method to the test

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Commented] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[ASF subversion and git services (JIRA)]

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

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

Commit 1697132 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1697132 ]

Merged revision(s) 1697131 from lucene/dev/trunk:
LUCENE-6760: Prevent test failure in Java 9 b76+

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Assigned] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler reassigned LUCENE-6760:
-

Assignee: Uwe Schindler

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Commented] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[ASF subversion and git services (JIRA)]

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

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

Commit 1697131 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1697131 ]

LUCENE-6760: Prevent test failure in Java 9 b76+

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Created] (SOLR-7957) simplify ResultContext / TransformContext

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-7957:
--

 Summary: simplify ResultContext / TransformContext
 Key: SOLR-7957
 URL: https://issues.apache.org/jira/browse/SOLR-7957
 Project: Solr
  Issue Type: Bug
  Components: rch, search
Reporter: Yonik Seeley
 Fix For: Trunk


Today we have a ResultContext which simply has two public variables query and 
docList.  For writing a response, those fields are used to create a 
DocsStreamer which creates a TransformContext for transformers (which just 
copies the values like searcher, req, q, etc again).

It seems the all the methods on TransformContext could be simply moved to 
ResultContext.

Only exception is "iterator" needed by ScoreAugmenter, but we could simply pass 
down the score in the transform() method as well.

This would result in a ResultContext that could do things like support multiple 
queries with different return fields, and things like returning a list of docs 
from another core (think cross-core join).



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

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

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: LUCENE-6760.patch

Turn sanity check into assert statement.

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch, 
> LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: LUCENE-6760.patch

First patch, with improved error message (was unreadable in the failures 
recently seen). I will commit this in a moment to prevent more test failures.

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Commented] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6760:
---

OK Robert, thanks for the opinion. I will go for the first patch and simply 
remove the non-whitespace character.

FYI, I checked with Eclipse call trace: The method is only used by this single 
test, so it's not really a useful utility method in TestUtil. We should move it 
to the test. But I will for now only fix the problem, so the recent Java 9 
builds pass!

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Commented] (SOLR-7789) Introduce a ConfigSet management API

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-7789:
--

Thanks for the comments, Shalin.

{quote}Why should there be a separate queue for such operations? i.e. Why 
should ZkController have method called getOverseerConfigSetQueue() at all? It 
should just use the collection queue. Similarily why does this API need a new 
ConfigSetsHandler and not use CollectionsHandler?{quote}

Let's start with the second question.  There is a ConfigSetsHandler because it 
operates on a separate end point -- it doesn't make sense to send 
ConfigSet-related commands to /admin/collections, it makes more sense from the 
end user perspective to send ConfigSet-related commands to /admin/configs.  
Given separate end points, separate handlers also make sense.

On the second question, the concern is a little more subtle.  The point I am 
trying to make is that how the Overseer processes ConfigSet operations is an 
implementation detail of the Overseer.  The ConfigSetHandler (which is not part 
of the Overseer) just needs an interface in order to tell the Overseer that it 
wants a ConfigSet operation processed, it shouldn't be concerned with the 
implementation details.  Right now we happen to use the same queue under the 
covers, but maybe we find in the future that's a bad idea (e.g. users have 
different QoS expectations between ConfigSet and Collection operations and we 
add ConfigSet operations that are long lived and block important Collection 
operations).  If the interface between the Overseer and the ConfigSet handler 
doesn't refer to collections, we don't need to change anything outside of the 
Overseer if we change the processing in the future.

bq. The only reason why it is called a OverseerCollectionQueue is to indicate 
that it is the queue for OverseerCollectionProcessor.

That can be indicated with a variable/method name, not the type name.

{quote}TBH, all this refactoring of OverseerCollectionProcessor confuses me 
very much. It looks like you want the APIs and tasks run in the overseer to be 
pluggable but I haven't noticed you saying that anywhere. In the absence of 
them being truly pluggable, the current API has become more complicated than it 
was before. We do not need complex dispatch mechanisms in the collection 
processor.{quote}

I don't wish to make the API/tasks pluggable so I understand your concern.  
That being said, there is a middle ground between API/tasks being pluggable and 
putting everything in the collection processor.  All I'm arguing for is clean 
interfaces.  Take SOLR-7855 as an example; because we had Overseer/role related 
commands in the collection processor it made refactoring much more difficult.  
Doing what you suggest in my opinion would have the same effect.

{quote}We do not need complex dispatch mechanisms in the collection processor. 
If you think that it is wrong to perform tasks that do not involve a Collection 
then it could simply be renamed to OverseerTaskProcessor and we can be 
done.{quote}

I don't think the dispatching here is complex and it is completely contained in 
the Overseer.  I'm not sure what you mean by OverseerTaskProcessor, this seems 
like a separate issue.  After SOLR-7855 we have an 
OverseerCollectionMessageHandler to handle overseer collection messages.  If 
you are suggesting throwing the ConfigSet related commands in there (from 
OverseerConfigSetMessageHandler), you've just moved the dispatch code somewhere 
else.

bq. Btw we have had APIs such as clusterprops and request_status in the 
overseer collection processor and I don't think it is confusing anyone.

I gave the example above the overseer/role related commands making code hard to 
refactor.  I agree with you that clusterprops and request_status aren't 
particularly confusing -- that doesn't mean we can't do better.



> Introduce a ConfigSet management API
> 
>
> Key: SOLR-7789
> URL: https://issues.apache.org/jira/browse/SOLR-7789
> Project: Solr
>  Issue Type: New Feature
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-7789.patch, SOLR-7789.patch, SOLR-7789.patch, 
> SOLR-7789.patch
>
>
> SOLR-5955 describes a feature to automatically create a ConfigSet, based on 
> another one, from a collection API call (i.e. one step collection creation).  
> Discussion there yielded SOLR-7742, Immutable ConfigSet support.  To close 
> the loop, we need support for a ConfigSet management API.
> The simplest ConfigSet API could have one operation:
> create a new config set, based on an existing one, possible modifying the 
> ConfigSet properties.  Note you need to be able to modify the ConfigSet 
> properties at creation time because otherwise Immutable could not be 

[jira] [Commented] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6760:
-

Sorry I am against the change, unless lucene supports one and only one JDK 
version.

This patch will stop random seeds from reproducing.

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13961 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13961/
Java: 64bit/jdk1.9.0-ea-b78 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.ReturnFieldsTest.testWhitespace

Error Message:
Not really whitespace? (@11): ᠎

Stack Trace:
java.lang.AssertionError: Not really whitespace? (@11): ᠎
at 
__randomizedtesting.SeedInfo.seed([E07A096758CA3B01:260CBD29E4E85CF7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1191)
at 
org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTest.java:351)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:746)




Build Log:
[...truncated 10335 lines...]
   [junit4] Suite: org.apache.solr.search.ReturnFieldsTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J2/temp/so

[JENKINS-EA] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b78) - Build # 13681 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13681/
Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseConcMarkSweepGC

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([48B1D5B525EEBEC8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:746)


FAILED:  org.apache.solr.search.ReturnFieldsTest.testWhitespace

Error Message:
Not really whitespace? (@11): ᠎

Stack Trace:
java.lang.AssertionError: Not really whitespace? (@11): ᠎
at 
__randomizedtesting.SeedInfo.seed([48B1D5B525EEBEC8:8EC761FB99CCD93E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1217)
at 
org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTest.java:348)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.Statem

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: LUCENE-6760.patch

Better patch using constants.

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: (was: LUCENE-6760.patch)

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: LUCENE-6760.patch

This patch makes the list of whitespace chars dynamic. I would prefer this 
approach, because it is future proof. Currently all our previous Lucene/Solr 
releases will not pass the tests in Java 9 because of that!

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch, LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Commented] (SOLR-7955) Auto create .system collection on first start if it does not exist

[Ramkumar Aiyengar (JIRA)]

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

Ramkumar Aiyengar commented on SOLR-7955:
-

I agree, there's a footprint to adding a collection, and people who don't need 
this feature shouldn't have to bear it. If we want to make the feature easier, 
may be lazily on first use (if possible) is a better alternative than on first 
start..

> Auto create .system collection on first start if it does not exist
> --
>
> Key: SOLR-7955
> URL: https://issues.apache.org/jira/browse/SOLR-7955
> Project: Solr
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>
> Why should a user need to create the {{.system}} collection manually? It 
> would simplify instructions related to BLOB store if user could assume it is 
> always there.



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

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

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 255 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/255/

No tests ran.

Build Log:
[...truncated 52285 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (13.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.1 MB in 0.03 sec (816.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 64.9 MB in 0.08 sec (839.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 75.2 MB in 0.09 sec (820.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5835 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5835 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.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] Releases that don't seem to be tested:
   [smoker]   5.3.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1416, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1361, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1399, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 583, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 728, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1354, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsCompatibility?

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:527:
 exec returned: 1

Total time: 37 minutes 2 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-6760:
--
Attachment: LUCENE-6760.patch

Patch removing the char.

What do other think, should we make the static array initialized on static init 
 of TestUtil?

> TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
> -
>
> Key: LUCENE-6760
> URL: https://issues.apache.org/jira/browse/LUCENE-6760
> Project: Lucene - Core
>  Issue Type: Test
> Environment: Java 9 build 76+
>Reporter: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-6760.patch
>
>
> Java 9 changed its character tables to unicode version 7.0. The table updates 
> are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d
> Because of this, character {{\u180E}} is no longer treated as whitespace, so 
> TestUtil#randomWhitespace() fails.
> I will remove this character from the list and update the documentation 
> JRE_VERSION_MIGRATION.txt.
> We should maybe make this character list dynamic (e.g. TestUtil initializes 
> it on static class init one time by iterating over all 16 bit characters). 
> Maybe somebody else has an idea (there is already a TODO in the code about 
> that).



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

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

[jira] [Created] (LUCENE-6760) TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-6760:
-

 Summary: TestUtil#randomWhitespace() broken for Java 9 (Unicode 7)
 Key: LUCENE-6760
 URL: https://issues.apache.org/jira/browse/LUCENE-6760
 Project: Lucene - Core
  Issue Type: Test
 Environment: Java 9 build 76+
Reporter: Uwe Schindler


Java 9 changed its character tables to unicode version 7.0. The table updates 
are listed here: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d

Because of this, character {{\u180E}} is no longer treated as whitespace, so 
TestUtil#randomWhitespace() fails.

I will remove this character from the list and update the documentation 
JRE_VERSION_MIGRATION.txt.

We should maybe make this character list dynamic (e.g. TestUtil initializes it 
on static class init one time by iterating over all 16 bit characters). Maybe 
somebody else has an idea (there is already a TODO in the code about that).



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

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

RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13959 - Failure!

[Uwe Schindler]

OK,

I found out: Was changed in: 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/86206517258d#l3.19

This was the update of Java 9 to Unicode 7.0. So I will remove that character 
from the "whitespace list" in TestUtil.

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


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Saturday, August 22, 2015 8:18 PM
> To: dev@lucene.apache.org
> Cc: rory.odonn...@oracle.com; Balchandra Vaidya
> Subject: RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) -
> Build # 13959 - Failure!
> 
> Hi,
> 
> This was the same with build 76. It looks like this special character is no 
> longer
> treated as whitespace, although all previous Java versions were treating it as
> whitespace. I will remove this character from the whitespace list for now and
> maybe open issue @ Rory.
> 
> Character.isWhitespace('\u180E') returns false. According to Unicode tables it
> could be whitespace, but also inside JDK it's not 100% sure, they opened bug
> at some point but closed as won't fix:
> https://bugs.openjdk.java.net/browse/JDK-4915940; maybe Robert has an
> idea, if this a bug or not!
> 
> I checked with this program, it should return true for all the array elements:
> 
> ==
> import java.util.Locale;
> 
> public final class Test {
> 
>   /** List of characters that match {@link Character#isWhitespace} */
>   public static final char[] WHITESPACE_CHARACTERS = new char[] {
> '\u0009',
> '\n',
> '\u000B',
> '\u000C',
> '\r',
> '\u001C',
> '\u001D',
> '\u001E',
> '\u001F',
> '\u0020',
> '\u1680',
> '\u180E', // critical char!
> '\u2000',
> '\u2001',
> '\u2002',
> '\u2003',
> '\u2004',
> '\u2005',
> '\u2006',
> '\u2008',
> '\u2009',
> '\u200A',
> '\u2028',
> '\u2029',
> '\u205F',
> '\u3000',
>   };
> 
>   public static void main(String[] args) throws ParseException {
> for (char ch : WHITESPACE_CHARACTERS) {
>   System.out.println(String.format(Locale.ROOT, "\\u%04x: %b", (int) ch,
> Character.isWhitespace(ch)));
> }
>   }
> 
> }
> 
> 
> It prints false for the problematic character:
> 
> \u0009: true
> \u000a: true
> \u000b: true
> \u000c: true
> \u000d: true
> \u001c: true
> \u001d: true
> \u001e: true
> \u001f: true
> \u0020: true
> \u1680: true
> \u180e: false
> \u2000: true
> \u2001: true
> \u2002: true
> \u2003: true
> \u2004: true
> \u2005: true
> \u2006: true
> \u2008: true
> \u2009: true
> \u200a: true
> \u2028: true
> \u2029: true
> \u205f: true
> \u3000: true
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> > -Original Message-
> > From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> > Sent: Saturday, August 22, 2015 7:24 PM
> > To: dev@lucene.apache.org
> > Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78)
> > - Build # 13959 - Failure!
> > Importance: Low
> >
> > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13959/
> > Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseG1GC
> >
> > 1 tests failed.
> > FAILED:  org.apache.solr.search.ReturnFieldsTest.testWhitespace
> >
> > Error Message:
> > Not really whitespace? (@11):
> >
> > Stack Trace:
> > java.lang.AssertionError: Not really whitespace? (@11): ᠎
> > at
> >
> __randomizedtesting.SeedInfo.seed([30B1D909332F3F96:F6C76D478F0D586
> > 0]:0)
> > at org.junit.Assert.fail(Assert.java:93)
> > at org.junit.Assert.assertTrue(Assert.java:43)
> > at
> > org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1191)
> > at
> > org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTes
> > t.ja
> > va:351)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> > ava:62)
> > at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > sorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:504)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> > dRunner.java:1627)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
> > mizedRunner.java:836)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
> > mizedRunner.java:872)
> > at
> >
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> > mizedRunner.java:886)
> > at
> >
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.
> > evaluate(SystemPropertiesRestoreRule.java:57)
> > at
> >
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRul
> > e
> > SetupTeardownChained.java:50)
> > at
> > org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(A

Re: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/ /release/lucene/solr/5.3.0/

[Steve Rowe]

Noble, AFAICT looking at the staging repository you created at 
repository.apache.org, you didn’t close or release the staging repository. 
These are item #s 3 and 5 on 
.

Note that item #4 (drop a staging repository) does not need to be performed - 
it’s there to let you know how to do it, not as a required step in the standard 
maven artifact release process.

Steve

> On Aug 22, 2015, at 1:52 PM, Noble Paul  wrote:
> 
> "Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on
> Maven Central!)"
> 
> I did follow the instructions here
> http://wiki.apache.org/lucene-java/PublishMavenArtifacts . I will have
> to check
> 
> On Sat, Aug 22, 2015 at 11:20 PM, Noble Paul  wrote:
>> done
>> 
>> On Sat, Aug 22, 2015 at 5:42 PM, Noble Paul  wrote:
>>> Sure.  Will do
>>> 
>>> On Aug 22, 2015 4:24 AM, "Uwe Schindler"  wrote:
 
 Hi Noble,
 
 the Lucene/Solr release folders still contains Maven stuff, which should
 not be visible on the download distribution:
 http://www.apache.org/dist/lucene/java/5.3.0/
 Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on Maven
 Central!)
 
 Uwe
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
> -Original Message-
> From: no...@apache.org [mailto:no...@apache.org]
> Sent: Thursday, August 20, 2015 11:29 AM
> To: comm...@lucene.apache.org
> Subject: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-
> rev1696229/solr/ /release/lucene/solr/5.3.0/
> 
> Author: noble
> Date: Thu Aug 20 09:28:55 2015
> New Revision: 10236
> 
> Log:
> Move Solr 5.3.0 RC2 to release repo.
> 
> Added:
>release/lucene/solr/5.3.0/
>  - copied from r10235,
> dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
> Removed:
>dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
>>> 
>> 
>> 
>> 
>> --
>> -
>> Noble Paul
> 
> 
> 
> -- 
> -
> Noble Paul
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Commented] (LUCENE-6743) Allow Ivy lockStrategy to be overridden by system property.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-6743:


Thanks for this. I had to delete my ivy cache several times this week for 
issues like this.

> Allow Ivy lockStrategy to be overridden by system property.
> ---
>
> Key: LUCENE-6743
> URL: https://issues.apache.org/jira/browse/LUCENE-6743
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6743.patch
>
>
> The current hard code lock strategy is imperfect and can fail under parallel 
> load. With Ivy 2.4 there is a better option in artifact-lock-nio. We should 
> allow the lock strategy to be overrideen like the resolutionCacheDir.



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

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

RE: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13959 - Failure!

[Uwe Schindler]

Hi,

This was the same with build 76. It looks like this special character is no 
longer treated as whitespace, although all previous Java versions were treating 
it as whitespace. I will remove this character from the whitespace list for now 
and maybe open issue @ Rory.

Character.isWhitespace('\u180E') returns false. According to Unicode tables it 
could be whitespace, but also inside JDK it's not 100% sure, they opened bug at 
some point but closed as won't fix: 
https://bugs.openjdk.java.net/browse/JDK-4915940; maybe Robert has an idea, if 
this a bug or not!

I checked with this program, it should return true for all the array elements:

==
import java.util.Locale;

public final class Test {
 
  /** List of characters that match {@link Character#isWhitespace} */
  public static final char[] WHITESPACE_CHARACTERS = new char[] {
'\u0009',
'\n',
'\u000B',
'\u000C',
'\r',
'\u001C',
'\u001D',
'\u001E',
'\u001F',
'\u0020',
'\u1680',
'\u180E', // critical char!
'\u2000',
'\u2001',
'\u2002',
'\u2003',
'\u2004',
'\u2005',
'\u2006',
'\u2008',
'\u2009',
'\u200A',
'\u2028',
'\u2029',
'\u205F',
'\u3000',
  };
  
  public static void main(String[] args) throws ParseException {
for (char ch : WHITESPACE_CHARACTERS) {
  System.out.println(String.format(Locale.ROOT, "\\u%04x: %b", (int) ch, 
Character.isWhitespace(ch)));
}
  }
  
}


It prints false for the problematic character:

\u0009: true
\u000a: true
\u000b: true
\u000c: true
\u000d: true
\u001c: true
\u001d: true
\u001e: true
\u001f: true
\u0020: true
\u1680: true
\u180e: false
\u2000: true
\u2001: true
\u2002: true
\u2003: true
\u2004: true
\u2005: true
\u2006: true
\u2008: true
\u2009: true
\u200a: true
\u2028: true
\u2029: true
\u205f: true
\u3000: true

Uwe

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


> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Saturday, August 22, 2015 7:24 PM
> To: dev@lucene.apache.org
> Subject: [JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build
> # 13959 - Failure!
> Importance: Low
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13959/
> Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseG1GC
> 
> 1 tests failed.
> FAILED:  org.apache.solr.search.ReturnFieldsTest.testWhitespace
> 
> Error Message:
> Not really whitespace? (@11): ᠎
> 
> Stack Trace:
> java.lang.AssertionError: Not really whitespace? (@11): ᠎
>   at
> __randomizedtesting.SeedInfo.seed([30B1D909332F3F96:F6C76D478F0D586
> 0]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at org.junit.Assert.assertTrue(Assert.java:43)
>   at
> org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1191)
>   at
> org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTest.ja
> va:351)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:504)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> dRunner.java:1627)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
> mizedRunner.java:836)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
> mizedRunner.java:872)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> mizedRunner.java:886)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.
> evaluate(SystemPropertiesRestoreRule.java:57)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> SetupTeardownChained.java:50)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> fterRule.java:46)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> readAndTestName.java:49)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> IgnoreAfterMaxFailures.java:65)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> .java:48)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> ementAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
> run(ThreadLeakControl.java:365)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
> (ThreadLeakControl.java:798)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
> eakControl.java:458)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
> domizedRunne

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60) - Build # 13680 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13680/
Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Could not find a healthy node to handle the request.

Stack Trace:
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request.
at 
__randomizedtesting.SeedInfo.seed([DBF2204C7EC13CF1:83C08649B4F997]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1071)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:940)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:940)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:940)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:940)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:940)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:135)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:485)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:464)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:443)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Sta

[jira] [Created] (SOLR-7956) There are interrupts on shutdown in places that can cause ChannelAlreadyClosed exceptions which prevents proper closing of transaction logs.

[Mark Miller (JIRA)]

Mark Miller created SOLR-7956:
-

 Summary: There are interrupts on shutdown in places that can cause 
ChannelAlreadyClosed exceptions which prevents proper closing of transaction 
logs.
 Key: SOLR-7956
 URL: https://issues.apache.org/jira/browse/SOLR-7956
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: Trunk, 5.4


Found this while beast testing HttpPartitionTest.



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

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

[jira] [Resolved] (LUCENE-6743) Allow Ivy lockStrategy to be overridden by system property.

[Mark Miller (JIRA)]

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

Mark Miller resolved LUCENE-6743.
-
Resolution: Fixed

This issue is complete. I use the following in ~/build.properties for a nice 
hassle free, no .ivy2 folder delete time, existence:

ivy.bootstrap.version=2.4.0
ivy_checksum_sha1=5abe4c24bbe992a9ac07ca563d5bd3e8d569e9ed
ivy.lock-strategy=artifact-lock-nio

I first removed ivy 2.3.0 from ~/.ant/lib and then used the ant ivy bootstrap 
target to pull in 2.4.0. One time upgrade operation.

The hard part with making this the default is that many devs and users will 
still have ivy 2.3.0 on the classpath and if we specify the artifact-lock-nio 
in the config, that won't work AFAIK. We would need to do it somehow 
conditionally I think. This provides an easy path for anyone else hitting these 
issues now though.

> Allow Ivy lockStrategy to be overridden by system property.
> ---
>
> Key: LUCENE-6743
> URL: https://issues.apache.org/jira/browse/LUCENE-6743
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Minor
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6743.patch
>
>
> The current hard code lock strategy is imperfect and can fail under parallel 
> load. With Ivy 2.4 there is a better option in artifact-lock-nio. We should 
> allow the lock strategy to be overrideen like the resolutionCacheDir.



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

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

Re: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/ /release/lucene/solr/5.3.0/

[Noble Paul]

"Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on
Maven Central!)"

I did follow the instructions here
http://wiki.apache.org/lucene-java/PublishMavenArtifacts . I will have
to check

On Sat, Aug 22, 2015 at 11:20 PM, Noble Paul  wrote:
> done
>
> On Sat, Aug 22, 2015 at 5:42 PM, Noble Paul  wrote:
>> Sure.  Will do
>>
>> On Aug 22, 2015 4:24 AM, "Uwe Schindler"  wrote:
>>>
>>> Hi Noble,
>>>
>>> the Lucene/Solr release folders still contains Maven stuff, which should
>>> not be visible on the download distribution:
>>> http://www.apache.org/dist/lucene/java/5.3.0/
>>> Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on Maven
>>> Central!)
>>>
>>> Uwe
>>>
>>> -
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>>
>>>
>>> > -Original Message-
>>> > From: no...@apache.org [mailto:no...@apache.org]
>>> > Sent: Thursday, August 20, 2015 11:29 AM
>>> > To: comm...@lucene.apache.org
>>> > Subject: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-
>>> > rev1696229/solr/ /release/lucene/solr/5.3.0/
>>> >
>>> > Author: noble
>>> > Date: Thu Aug 20 09:28:55 2015
>>> > New Revision: 10236
>>> >
>>> > Log:
>>> > Move Solr 5.3.0 RC2 to release repo.
>>> >
>>> > Added:
>>> > release/lucene/solr/5.3.0/
>>> >   - copied from r10235,
>>> > dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
>>> > Removed:
>>> > dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>
>
>
> --
> -
> Noble Paul



-- 
-
Noble Paul

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

Re: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/ /release/lucene/solr/5.3.0/

[Noble Paul]

done

On Sat, Aug 22, 2015 at 5:42 PM, Noble Paul  wrote:
> Sure.  Will do
>
> On Aug 22, 2015 4:24 AM, "Uwe Schindler"  wrote:
>>
>> Hi Noble,
>>
>> the Lucene/Solr release folders still contains Maven stuff, which should
>> not be visible on the download distribution:
>> http://www.apache.org/dist/lucene/java/5.3.0/
>> Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on Maven
>> Central!)
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>
>> > -Original Message-
>> > From: no...@apache.org [mailto:no...@apache.org]
>> > Sent: Thursday, August 20, 2015 11:29 AM
>> > To: comm...@lucene.apache.org
>> > Subject: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-
>> > rev1696229/solr/ /release/lucene/solr/5.3.0/
>> >
>> > Author: noble
>> > Date: Thu Aug 20 09:28:55 2015
>> > New Revision: 10236
>> >
>> > Log:
>> > Move Solr 5.3.0 RC2 to release repo.
>> >
>> > Added:
>> > release/lucene/solr/5.3.0/
>> >   - copied from r10235,
>> > dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
>> > Removed:
>> > dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>



-- 
-
Noble Paul

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 13959 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13959/
Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.search.ReturnFieldsTest.testWhitespace

Error Message:
Not really whitespace? (@11): ᠎

Stack Trace:
java.lang.AssertionError: Not really whitespace? (@11): ᠎
at 
__randomizedtesting.SeedInfo.seed([30B1D909332F3F96:F6C76D478F0D5860]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.lucene.util.TestUtil.randomWhitespace(TestUtil.java:1191)
at 
org.apache.solr.search.ReturnFieldsTest.testWhitespace(ReturnFieldsTest.java:351)
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:504)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:746)




Build Log:
[...truncated 9965 lines...]
   [junit4] Suite: org.apache.solr.search.ReturnFieldsTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.se

[jira] [Commented] (SOLR-6760) New optimized DistributedQueue implementation for overseer

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-6760:
--

Gregory, glad you're thinking about this.  This kind of discussion is just what 
I was hoping for when I wrote "I think someone should go back and analyze the 
true needs there and figure out if there's something better we can do." :)

> New optimized DistributedQueue implementation for overseer
> --
>
> Key: SOLR-6760
> URL: https://issues.apache.org/jira/browse/SOLR-6760
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-6760-branch_5x.patch, SOLR-6760.patch, 
> SOLR-6760.patch, SOLR-6760.patch, SOLR-6760.patch, deadlock.patch
>
>
> Currently the DQ works as follows
> * read all items in the directory
> * sort them all 
> * take the head and return it and discard everything else
> * rinse and repeat
> This works well when we have only a handful of items in the Queue. If the 
> items in the queue is much larger (in tens of thousands) , this is 
> counterproductive
> As the overseer queue is a multiple producers + single consumer queue, We can 
> read them all in bulk  and before processing each item , just do a 
> zk.exists(itemname) and if all is well we don't need to do the fetch all + 
> sort thing again



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

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 772 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/772/

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.search.TestReloadDeadlock

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

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


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

Error Message:
Captured an uncaught exception in thread: Thread[id=11405, name=collection0, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=11405, name=collection0, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:35050: Could not find collection : 
awholynewstresscollection_collection0_5
at __randomizedtesting.SeedInfo.seed([7636EEA5640CABE3]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895)


FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=74537, name=collection5, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=74537, name=collection5, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:59781/_x/nu: Could not find collection : 
awholynewstresscollection_collection5_0
at __randomizedtesting.SeedInfo.seed([7636EEA5640CABE3]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:372)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:325)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:857)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:800)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:895)


FAILED:  org.apache.solr.search.TestReloadDeadlock.testReloadDeadlock

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




Build Log:
[...truncated 10261 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J0/temp/solr.cloud.CollectionsAPIDistributedZkTest_7636EEA5640CABE3-001/init-core-data-001
   [junit4]   2> 1141977 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[7636EEA5640CABE3]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 1141977 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[7636EEA5640CABE3]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1141982 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[7636EEA5640CABE3]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1141983 INFO  (Thread-7278

[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6759:
-

Changing isWithin() to be stricter globally seems like a reasonable way to go.  
However, this requires SidedPlane to have two different isWithin() methods 
anyhow.  So I think I'll just bite the bullet and introduce isWithinStrict() as 
a new part of the Membership interface.

This will take some time to propagate and test.


> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_51) - Build # 5185 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5185/
Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([8CC73C6744E2985E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog\tlog.000:
 java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog\tlog.000:
 The process cannot access the file because it is being used by another 
process. 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog

C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data

C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_8CC73C6744E2985E-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b25) - Build # 13957 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13957/
Java: 32bit/jdk1.8.0_60-ea-b25 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([9B6DC283A884E195:3C297A27C53FF22C]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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(StatementA

RE: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/ /release/lucene/solr/5.3.0/

[Noble Paul]

Sure.  Will do
On Aug 22, 2015 4:24 AM, "Uwe Schindler"  wrote:

> Hi Noble,
>
> the Lucene/Solr release folders still contains Maven stuff, which should
> not be visible on the download distribution:
> http://www.apache.org/dist/lucene/java/5.3.0/
> Maven has to be deployed separately (FYI, I still don’t see 5.3.0 on Maven
> Central!)
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: no...@apache.org [mailto:no...@apache.org]
> > Sent: Thursday, August 20, 2015 11:29 AM
> > To: comm...@lucene.apache.org
> > Subject: svn commit: r10236 - /dev/lucene/lucene-solr-5.3.0-RC2-
> > rev1696229/solr/ /release/lucene/solr/5.3.0/
> >
> > Author: noble
> > Date: Thu Aug 20 09:28:55 2015
> > New Revision: 10236
> >
> > Log:
> > Move Solr 5.3.0 RC2 to release repo.
> >
> > Added:
> > release/lucene/solr/5.3.0/
> >   - copied from r10235,
> dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
> > Removed:
> > dev/lucene/lucene-solr-5.3.0-RC2-rev1696229/solr/
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-7850) Move user customization out of solr.in.* scripts

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7850:


I've had some time for my thoughts to gel on this subject.

I think that we should move the bin/solr.in.* scripts to something like 
etc/startupenv.* instead, and place versions with "sample" in the filename in 
the download.  I've thought about placing those sample files in server/etc 
instead, since that directory already exists. I'm open to discussion on both 
the filenames and the location.  I like the idea of an etc directory at the top 
level ... if most of what a user might want to change in server/etc is 
configurable by environment variables in etc (I think we're probably there or 
mostly there now), we can hopefully keep beginners from messing with the jetty 
config and permanent scripts directly.

The main solr script should contain sensible defaults for the variables that 
can be overridden in the startup environment, then read that config script if 
it exists.


> Move user customization out of solr.in.* scripts
> 
>
> Key: SOLR-7850
> URL: https://issues.apache.org/jira/browse/SOLR-7850
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Shawn Heisey
>Priority: Minor
>
> I've seen a fair number of users customizing solr.in.* scripts to make 
> changes to their Solr installs.  I think the documentation suggests this, 
> though I haven't confirmed.
> One possible problem with this is that we might make changes in those scripts 
> which such a user would want in their setup, but if they replace the script 
> with the one in the new version, they will lose their customizations.
> I propose instead that we have the startup script look for and utilize a user 
> customization script, in a similar manner to linux init scripts that look for 
> /etc/default/packagename, but are able to function without it.  I'm not 
> entirely sure where the script should live or what it should be called.  One 
> idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of 
> thought into it yet.
> If the internal behavior of our scripts is largely replaced by a small java 
> app as detailed in SOLR-7043, then the same thing should apply there -- have 
> a config file for a user to specify settings, but work perfectly if that 
> config file is absent.



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

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

[jira] [Comment Edited] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-6759 at 8/22/15 12:16 PM:
---

Thinking through why one error measure just doesn't work in this case:

(1) The point in question is on the wrong side of the GeoCircle plane, and is 
pretty nearly the *closest* point on the XYZSolid to the GeoCircle plane.
(2) The slight tilt of the GeoCircle plane is enough to put the upper 
intersection point beyond the MINIMUM_RESOLUTION distance (at a distance of 
roughly 1e-8).  That removes the first candidate intersection point from 
consideration.
(3) Because the GeoCircle is almost at the edge of the world, the slope between 
the GeoCircle plane and the planet surface is quite high, so a small error 
distance in X translates to a large distance in Y or Z.  That allows the second 
candidate intersection point to be removed from consideration.

The obvious conclusion is that we can tolerate no error at all in determining 
if a point is within a shape or not, for the purposes of evaluating 
relationships.  It's not clear to me yet whether we need to simply tighten the 
existing definition of "isWithin()", or we need to have multiple variants of 
"isWithin()".  Further analysis is needed to figure that out.



was (Author: kwri...@metacarta.com):
Thinking through why one error measure just doesn't work in this case:

(1) The point in question is on the wrong side of the GeoCircle plane, and is 
pretty nearly the *closest* point on the XYZSolid to the GeoCircle plane.
(2) The slight tilt of the GeoCircle plane is enough to put the upper 
intersection point beyond the MINIMUM_RESOLUTION distance (at a distance of 
roughly 1e-8).  That removes the first candidate intersection point from 
consideration.
(3) Because the GeoCircle is almost at the edge of the world, the slope between 
the GeoCircle plane and the planet surface is quite high, so a small error 
distance in X translates to a large distance in Y or Z.  That allows the second 
candidate intersection point to be removed from consideration.



> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6759:
-

Thinking through why one error measure just doesn't work in this case:

(1) The point in question is on the wrong side of the GeoCircle plane, and is 
pretty nearly the *closest* point on the XYZSolid to the GeoCircle plane.
(2) The slight tilt of the GeoCircle plane is enough to put the upper 
intersection point beyond the MINIMUM_RESOLUTION distance (at a distance of 
roughly 1e-8).  That removes the first candidate intersection point from 
consideration.
(3) Because the GeoCircle is almost at the edge of the world, the slope between 
the GeoCircle plane and the planet surface is quite high, so a small error 
distance in X translates to a large distance in Y or Z.  That allows the second 
candidate intersection point to be removed from consideration.



> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[JENKINS] Lucene-Solr-SmokeRelease-5.x - Build # 298 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.x/298/

No tests ran.

Build Log:
[...truncated 52849 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.1 MB in 0.01 sec (14.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.4.0-src.tgz...
   [smoker] 28.5 MB in 0.03 sec (820.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.4.0.tgz...
   [smoker] 65.8 MB in 0.08 sec (804.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.4.0.zip...
   [smoker] 76.1 MB in 0.09 sec (828.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.4.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6063 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6063 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.4.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6063 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6063 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.4.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [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] Releases that don't seem to be tested:
   [smoker]   5.3.0
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/sm
   [smoker] okeTestRelease.py", line 1449, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1394, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1432, in smokeTest
   [smoker] unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % 
version, svnRevision, version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 583, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
svnRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 762, in verifyUnpacked
   [smoker] confirmAllReleasesAreTestedForBackCompat(unpackPath)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.x/dev-tools/scripts/smokeTestRelease.py",
 line 1387, in confirmAllReleasesAreTestedForBackCompat
   [smoker] raise RuntimeError('some releases are not tested by 
TestBackwardsCompatibility?')
   [smoker] RuntimeError: some releases are not tested by 
TestBackwardsC

[jira] [Assigned] (SOLR-6629) Watch /collections zk node on all nodes

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-6629:
---

Assignee: Shalin Shekhar Mangar  (was: Noble Paul)

> Watch /collections zk node on all nodes
> ---
>
> Key: SOLR-6629
> URL: https://issues.apache.org/jira/browse/SOLR-6629
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk
>
> Attachments: SOLR-6629.patch, SOLR-6629.patch, SOLR-6629.patch, 
> SOLR-6629.patch
>
>
> The main clusterstate.json is refreshed/used as a poor substitute for 
> informing all nodes about new or deleted collections even when the collection 
> being created or deleted has state format > 1. When we move away from state 
> format 1 then we should do away with this workaround and start watching the 
> /collections zk node on all nodes.



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

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

[jira] [Commented] (SOLR-7789) Introduce a ConfigSet management API

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7789:
-

{quote}
I am trying to accomplish the following:
#1 Add another OverseerMessageHandler (OverseerConfigSetMessageHandler) to 
handle ConfigSet-related operations.
#2 From the perspective of the non-overseer (i.e. the ConfigSetsHandler), it 
looks like the operations are written to a separate queue from the collection 
queue, i.e. getOverseerConfigSetQueue()
#3 Since the ConfigSet operations are most likely rare and fast, it made sense 
to just use the existing collections queue "under the covers" and handle the 
dispatch separately. The naming here breaks the illusion of #2, i.e. if I 
return an OverseerCollectionQueue it's pretty obvious to the non-overseer 
what's going on.
{quote}

Why should there be a separate queue for such operations? i.e. Why should 
ZkController have method called getOverseerConfigSetQueue() at all? It should 
just use the collection queue. Similarily why does this API need a new 
ConfigSetsHandler and not use CollectionsHandler?

bq. Short term: rename OverseerCollectionQueue to something more 
generic...DistributedTaskQueue? DistributedAsyncAwareQueue? There's nothing in 
there that is actually collection specific (which is why it works for the 
ConfigSet operations)

The only reason why it is called a OverseerCollectionQueue is to indicate that 
it is the queue for OverseerCollectionProcessor.

TBH, all this refactoring of OverseerCollectionProcessor confuses me very much. 
It looks like you want the APIs and tasks run in the overseer to be pluggable 
but I haven't noticed you saying that anywhere. In the absence of them being 
truly pluggable, the current API has become more complicated than it was 
before. We do not need complex dispatch mechanisms in the collection processor. 
If you think that it is wrong to perform tasks that do not involve a Collection 
then it could simply be renamed to OverseerTaskProcessor and we can be done. 
Btw we have had APIs such as clusterprops and request_status in the overseer 
collection processor and I don't think it is confusing anyone.

> Introduce a ConfigSet management API
> 
>
> Key: SOLR-7789
> URL: https://issues.apache.org/jira/browse/SOLR-7789
> Project: Solr
>  Issue Type: New Feature
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
> Attachments: SOLR-7789.patch, SOLR-7789.patch, SOLR-7789.patch, 
> SOLR-7789.patch
>
>
> SOLR-5955 describes a feature to automatically create a ConfigSet, based on 
> another one, from a collection API call (i.e. one step collection creation).  
> Discussion there yielded SOLR-7742, Immutable ConfigSet support.  To close 
> the loop, we need support for a ConfigSet management API.
> The simplest ConfigSet API could have one operation:
> create a new config set, based on an existing one, possible modifying the 
> ConfigSet properties.  Note you need to be able to modify the ConfigSet 
> properties at creation time because otherwise Immutable could not be changed.
> Another logical operation to support is ConfigSet deletion; that may be more 
> complicated to implement than creation because you need to handle the case 
> where a collection is already using the configuration.



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

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

[jira] [Commented] (SOLR-6760) New optimized DistributedQueue implementation for overseer

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-6760:
-

Let's keep this discussion on SOLR-7789. I'll respond on that issue.

> New optimized DistributedQueue implementation for overseer
> --
>
> Key: SOLR-6760
> URL: https://issues.apache.org/jira/browse/SOLR-6760
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-6760-branch_5x.patch, SOLR-6760.patch, 
> SOLR-6760.patch, SOLR-6760.patch, SOLR-6760.patch, deadlock.patch
>
>
> Currently the DQ works as follows
> * read all items in the directory
> * sort them all 
> * take the head and return it and discard everything else
> * rinse and repeat
> This works well when we have only a handful of items in the Queue. If the 
> items in the queue is much larger (in tens of thousands) , this is 
> counterproductive
> As the overseer queue is a multiple producers + single consumer queue, We can 
> read them all in bulk  and before processing each item , just do a 
> zk.exists(itemname) and if all is well we don't need to do the fetch all + 
> sort thing again



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

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

[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6759:
-

[~mikemccand] Here's the analysis, so far.

I first enabled evaluation of all four points where the XYZSolid intersected 
the planet surface.  As you can see, only one of them comes back as being 
inside the GeoCircle:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010919806760743 0.007079167343247293 
-0.001896122718181518: shape.isWithin? false; minx=9.722614064511248E-6, 
maxx=-2.597297212414418E-6, miny=0.0, maxy=-4.618394311805439E-4, 
minz=2.893784038207395E-4, maxz=0.0
   [junit4]   2>  Point 1.001088014365874 0.007541006774427837 
-0.0021855011220022575: shape.isWithin? false; minx=5.7563038642349795E-6, 
maxx=-6.563607412690686E-6, miny=4.618394311805439E-4, maxy=0.0, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010886082665449 0.007541006774427837 
-0.001896122718181518: shape.isWithin? false; minx=6.35020453509938E-6, 
maxx=-5.969706741826286E-6, miny=4.618394311805439E-4, maxy=0.0, 
minz=2.893784038207395E-4, maxz=0.0
{code}

If the above is an accurate picture, then there should be intersections between 
the GeoCircle and two of the edge planes.

miny should intersect:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010919806760743 0.007079167343247293 
-0.001896122718181518: shape.isWithin? false; minx=9.722614064511248E-6, 
maxx=-2.597297212414418E-6, miny=0.0, maxy=-4.618394311805439E-4, 
minz=2.893784038207395E-4, maxz=0.0
{code}

And, minz should intersect:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.001088014365874 0.007541006774427837 
-0.0021855011220022575: shape.isWithin? false; minx=5.7563038642349795E-6, 
maxx=-6.563607412690686E-6, miny=4.618394311805439E-4, maxy=0.0, minz=0.0, 
maxz=-2.893784038207395E-4
{code}

These two intersections are not being detected, and after much careful 
analysis, I concluded that the reason that they are not being detected is 
because no intersection actually happens.  Looking at the miny plane:

{code}
   [junit4]   2> Checking for intersections that should be found...
   [junit4]   2>  Not identical plane
   [junit4]   2> Looking for intersection between plane [A=-0.680546313309, 
B=-0.0046605790633783275, C=0.006493744653569968, D=1.0011065916522879, 
side=-1.0] and plane [A=0.0, B=1.0, C=0.0, D=-0.007079167343247293, side=1.0] 
within bounds
   [junit4]   2>  Two points of intersection
   [junit4]   2>   [X=1.0010359045488204, Y=0.0070791673432472925, 
Z=-0.010729178478687706] this=(0.0) q=(-8.673617379884035E-19), and 
[X=1.0010913867758835, Y=0.0070791673432472925, Z=-0.0021855018140558226] 
this=(0.0) q=(-8.673617379884035E-19)
{code}

Two points of intersection are detected, but both are outside the X or Z bounds 
of the XYZSolid, so they do not represent intersection.

So, how can this be?  Well, the reason for the discrepancy is because the first 
point of the four mentioned at the top is, in fact, not really inside the 
GeoCircle.  It is coming up as being inside the GeoCircle only because of the 
fact that we've increased MINIMUM_RESOLUTION from its original value of 1e-12:

{code}
   [junit4]   2> circlePlane eval = 2.9731772599461692E-12
{code}

So the problem is that ONE measure of error (point within GeoCircle) disagrees 
with another measure of error (intersection points in or out of XYZSolid), 
leading to an incorrect assessment.

This is obviously going to be challenging to address.  I may need to introduce 
two distinct error bounds in order for this logic to be robust.  But I have to 
think it through carefully.

> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.

[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6759:
-

I think you'll need to do that, yes.  But there's more to it than that.  See 
next comment.

> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6699:
-

Ok, I'll move my latest comment over.

> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values.  Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree?  Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape?  Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?



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

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

[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6699:
-

[~mikemccand] Here's the analysis, so far.

I first enabled evaluation of all four points where the XYZSolid intersected 
the planet surface.  As you can see, only one of them comes back as being 
inside the GeoCircle:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010919806760743 0.007079167343247293 
-0.001896122718181518: shape.isWithin? false; minx=9.722614064511248E-6, 
maxx=-2.597297212414418E-6, miny=0.0, maxy=-4.618394311805439E-4, 
minz=2.893784038207395E-4, maxz=0.0
   [junit4]   2>  Point 1.001088014365874 0.007541006774427837 
-0.0021855011220022575: shape.isWithin? false; minx=5.7563038642349795E-6, 
maxx=-6.563607412690686E-6, miny=4.618394311805439E-4, maxy=0.0, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010886082665449 0.007541006774427837 
-0.001896122718181518: shape.isWithin? false; minx=6.35020453509938E-6, 
maxx=-5.969706741826286E-6, miny=4.618394311805439E-4, maxy=0.0, 
minz=2.893784038207395E-4, maxz=0.0
{code}

If the above is an accurate picture, then there should be intersections between 
the GeoCircle and two of the edge planes.

miny should intersect:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.0010919806760743 0.007079167343247293 
-0.001896122718181518: shape.isWithin? false; minx=9.722614064511248E-6, 
maxx=-2.597297212414418E-6, miny=0.0, maxy=-4.618394311805439E-4, 
minz=2.893784038207395E-4, maxz=0.0
{code}

And, minz should intersect:

{code}
   [junit4]   2>  Point 1.0010913867774043 0.007079167343247293 
-0.0021855011220022575: shape.isWithin? true; minx=9.128715394490783E-6, 
maxx=-3.191195882434883E-6, miny=0.0, maxy=-4.618394311805439E-4, minz=0.0, 
maxz=-2.893784038207395E-4
   [junit4]   2>  Point 1.001088014365874 0.007541006774427837 
-0.0021855011220022575: shape.isWithin? false; minx=5.7563038642349795E-6, 
maxx=-6.563607412690686E-6, miny=4.618394311805439E-4, maxy=0.0, minz=0.0, 
maxz=-2.893784038207395E-4
{code}

These two intersections are not being detected, and after much careful 
analysis, I concluded that the reason that they are not being detected is 
because no intersection actually happens.  Looking at the miny plane:

{code}
   [junit4]   2> Checking for intersections that should be found...
   [junit4]   2>  Not identical plane
   [junit4]   2> Looking for intersection between plane [A=-0.680546313309, 
B=-0.0046605790633783275, C=0.006493744653569968, D=1.0011065916522879, 
side=-1.0] and plane [A=0.0, B=1.0, C=0.0, D=-0.007079167343247293, side=1.0] 
within bounds
   [junit4]   2>  Two points of intersection
   [junit4]   2>   [X=1.0010359045488204, Y=0.0070791673432472925, 
Z=-0.010729178478687706] this=(0.0) q=(-8.673617379884035E-19), and 
[X=1.0010913867758835, Y=0.0070791673432472925, Z=-0.0021855018140558226] 
this=(0.0) q=(-8.673617379884035E-19)
{code}

Two points of intersection are detected, but both are outside the X or Z bounds 
of the XYZSolid, so they do not represent intersection.

So, how can this be?  Well, the reason for the discrepancy is because the first 
point of the four mentioned at the top is, in fact, not really inside the 
GeoCircle.  It is coming up as being inside the GeoCircle only because of the 
fact that we've increased MINIMUM_RESOLUTION from its original value of 1e-12:

{code}
   [junit4]   2> circlePlane eval = 2.9731772599461692E-12
{code}

So the problem is that ONE measure of error (point within GeoCircle) disagrees 
with another measure of error (intersection points in or out of XYZSolid), 
leading to an incorrect assessment.

This is obviously going to be challenging to address.  I may need to introduce 
two distinct error bounds in order for this logic to be robust.  But I have to 
think it through carefully.

> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.pa

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 934 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/934/

2 tests failed.
FAILED:  
org.apache.lucene.codecs.lucene46.TestLucene46FieldInfoFormat.testRandomExceptions

Error Message:
hit unexpected FileNotFoundException: file=_5k.si

Stack Trace:
java.lang.AssertionError: hit unexpected FileNotFoundException: file=_5k.si
at 
__randomizedtesting.SeedInfo.seed([DE5D0B60FB3DAD54:B67265A46533F4F4]:0)
at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:753)
at 
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:530)
at 
org.apache.lucene.index.IndexFileDeleter.refresh(IndexFileDeleter.java:456)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3680)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1929)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:4731)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:695)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4757)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:4748)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1476)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1254)
at 
org.apache.lucene.index.BaseIndexFileFormatTestCase.testRandomExceptions(BaseIndexFileFormatTestCase.java:429)
at 
org.apache.lucene.index.BaseFieldInfoFormatTestCase.testRandomExceptions(BaseFieldInfoFormatTestCase.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgn

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5184 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5184/
Java: 32bit/jdk1.8.0_51 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking

Error Message:
Shard a1x2_shard1_replica1 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([6FE3EC72BD1F1A08:27DFB5B249140B9E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakContr

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13955 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13955/
Java: 64bit/jdk1.9.0-ea-b60 -XX:+UseCompressedOops -XX:+UseSerialGC

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([8D7E40399D6D1016]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:236)
at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
[/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data/index.20150822045828958,
 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data/index.20150822045828797]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data/index.20150822045828958,
 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_8D7E40399D6D1016-001/solr-instance-017/./collection1/data/index.20150822045828797]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([8D7E40399D6D1016:7A0DAE615B85BFF0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:813)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1243)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native

[jira] [Commented] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6759:


Maybe, we should take a step back and accept that precision issues mean that 
points near a shape's boundary may or may not be accepted?

I.e. we can just relax the test so that any point within X of the boundary (can 
we compute this easily?) is not tested.

> Integrate lat/long BKD and spatial 3d, part 2
> -
>
> Key: LUCENE-6759
> URL: https://issues.apache.org/jira/browse/LUCENE-6759
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>
> This is just a continuation of LUCENE-6699, which became too big.



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

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

[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6699:


OK I opened LUCENE-6759, let's continue discussion there?

> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values.  Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree?  Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape?  Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?



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

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

[jira] [Created] (LUCENE-6759) Integrate lat/long BKD and spatial 3d, part 2

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6759:
--

 Summary: Integrate lat/long BKD and spatial 3d, part 2
 Key: LUCENE-6759
 URL: https://issues.apache.org/jira/browse/LUCENE-6759
 Project: Lucene - Core
  Issue Type: New Feature
Reporter: Michael McCandless


This is just a continuation of LUCENE-6699, which became too big.



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

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

[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6699:


I'm going to open a "continuation issue" here!  It takes my browser too long to 
scroll through the many comments here ...

> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values.  Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree?  Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape?  Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?



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

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

[jira] [Comment Edited] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-6699 at 8/22/15 8:24 AM:
--

Hmm, as a final check, I took the original point from the original failure, 
which is not adjusted and is therefore on the WGS84 surface.  Unfortunately, 
that too fails in the same way:

{code}
c = new 
GeoCircle(PlanetModel.WGS84,-0.006450320645814321,0.004660694205115142,0.00489710732634323);
//xyzb = new XYZBounds();
//c.getBounds(xyzb);
//System.err.println("xmin="+xyzb.getMinimumX()+", 
xmax="+xyzb.getMaximumX()+",ymin="+xyzb.getMinimumY()+", 
ymax="+xyzb.getMaximumY()+",zmin="+xyzb.getMinimumZ()+", 
zmax="+xyzb.getMaximumZ());
//xmin=1.0010356621420726, 
xmax=1.0011141249179447,ymin=-2.5326643901354566E-4, 
ymax=0.009584741915757169,zmin=-0.011359874956269283, 
zmax=-0.0015549504447452225
area = 
GeoAreaFactory.makeGeoArea(PlanetModel.WGS84,1.0010822580620098,1.0010945779732867,0.007079167343247293,0.007541006774427837,-0.0021855011220022575,-0.001896122718181518);
assertTrue(GeoArea.CONTAINS == area.getRelationship(c));
p2 = new GeoPoint(PlanetModel.WGS84,-0.002164069780096702, 
0.007505617500830066);
assertTrue(PlanetModel.WGS84.pointOnSurface(p2));
assertTrue(!c.isWithin(p2));
assertTrue(!area.isWithin(p2)); // fails
{code}

So there is something more subtle going on than I originally thought.  Looking 
into it now.



was (Author: kwri...@metacarta.com):
Hmm, as a final check, I took the original point from the original failure, 
which is not adjusted and is therefore on the WGS84 surface.  Unfortunately, 
that too fails in the same way:

{code}
c = new 
GeoCircle(PlanetModel.WGS84,-0.006450320645814321,0.004660694205115142,0.00489710732634323);
//xyzb = new XYZBounds();
//c.getBounds(xyzb);
//System.err.println("xmin="+xyzb.getMinimumX()+", 
xmax="+xyzb.getMaximumX()+",ymin="+xyzb.getMinimumY()+", 
ymax="+xyzb.getMaximumY()+",zmin="+xyzb.getMinimumZ()+", 
zmax="+xyzb.getMaximumZ());
//xmin=1.0010356621420726, 
xmax=1.0011141249179447,ymin=-2.5326643901354566E-4, 
ymax=0.009584741915757169,zmin=-0.011359874956269283, 
zmax=-0.0015549504447452225
area = 
GeoAreaFactory.makeGeoArea(PlanetModel.WGS84,1.0010822580620098,1.0010945779732867,0.007079167343247293,0.007541006774427837,-0.0021855011220022575,-0.001896122718181518);
assertTrue(GeoArea.CONTAINS == area.getRelationship(c));
p2 = new GeoPoint(PlanetModel.WGS84,-0.002164069780096702, 
0.007505617500830066);
assertTrue(PlanetModel.WGS84.pointOnSurface(p2));
assertTrue(!c.isWithin(p2));
assertTrue(!area.isWithin(p2));
{code}

So there is something more subtle going on than I originally thought.  Looking 
into it now.


> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values.  Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree?  Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape?  Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?



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

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

[jira] [Commented] (LUCENE-6699) Integrate lat/lon BKD and spatial3d

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-6699:
-

Hmm, as a final check, I took the original point from the original failure, 
which is not adjusted and is therefore on the WGS84 surface.  Unfortunately, 
that too fails in the same way:

{code}
c = new 
GeoCircle(PlanetModel.WGS84,-0.006450320645814321,0.004660694205115142,0.00489710732634323);
//xyzb = new XYZBounds();
//c.getBounds(xyzb);
//System.err.println("xmin="+xyzb.getMinimumX()+", 
xmax="+xyzb.getMaximumX()+",ymin="+xyzb.getMinimumY()+", 
ymax="+xyzb.getMaximumY()+",zmin="+xyzb.getMinimumZ()+", 
zmax="+xyzb.getMaximumZ());
//xmin=1.0010356621420726, 
xmax=1.0011141249179447,ymin=-2.5326643901354566E-4, 
ymax=0.009584741915757169,zmin=-0.011359874956269283, 
zmax=-0.0015549504447452225
area = 
GeoAreaFactory.makeGeoArea(PlanetModel.WGS84,1.0010822580620098,1.0010945779732867,0.007079167343247293,0.007541006774427837,-0.0021855011220022575,-0.001896122718181518);
assertTrue(GeoArea.CONTAINS == area.getRelationship(c));
p2 = new GeoPoint(PlanetModel.WGS84,-0.002164069780096702, 
0.007505617500830066);
assertTrue(PlanetModel.WGS84.pointOnSurface(p2));
assertTrue(!c.isWithin(p2));
assertTrue(!area.isWithin(p2));
{code}

So there is something more subtle going on than I originally thought.  Looking 
into it now.


> Integrate lat/lon BKD and spatial3d
> ---
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, 
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values.  Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss?  Or, we could use BinaryDocValues?  We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree?  Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape?  Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?



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

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