[jira] [Commented] (LUCENE-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301863#comment-14301863
 ] 

Uwe Schindler commented on LUCENE-6213:
---

If you want to keep the array, use {{Arrays.asList(array).contains(element)}}, 
that's the pendant to your STL's {{find()}}. But I still think that a set is 
the right data structure.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301958#comment-14301958
 ] 

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

Commit 1656581 from [~rjernst] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656581 ]

LUCENE-6213: Bikeshed the hell out of a 1 element list

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301869#comment-14301869
 ] 

Ryan Ernst commented on LUCENE-6213:


Well, except that would convert the array to a list on each call.  I would 
rather keep the current code.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6919) Log REST info before executing

[Gregory Chanan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302052#comment-14302052
 ] 

Gregory Chanan commented on SOLR-6919:
--

bq. Did you want to add any other queries to the test case as well?

I think this is fine for an initial version...feel free to post follow on jiras 
if you want to improve the testing.

+1.

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301938#comment-14301938
 ] 

Uwe Schindler commented on LUCENE-6213:
---

bq. Well, except that would convert the array to a list on each call. I would 
rather keep the current code.

Well, I would declare it as this List. List and array are basically the same in 
Java. Arrays.asList() does only wrap not convert. In addition the 
declaration of the static constant would be much more readable (sorry, I hate 
this new String[] { ... } syntax - the code looks like written by a C 
developer - not Java like):

{code:java}
private static final ListString unsupportedCodecs = Arrays.asList(
  Lucene3x
);
{code}

Then you can do the contains().
(because its private, there is no need to make it explicitely unmodifiable)

Uwe

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6919) Log REST info before executing

[Mike Drob (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302040#comment-14302040
 ] 

Mike Drob commented on SOLR-6919:
-

bq. Checks that what we are matching against doesn't contain the post-debug 
information (i.e. status, hits, QTime).
+1.

Did you want to add any other queries to the test case as well?

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301962#comment-14301962
 ] 

Uwe Schindler commented on LUCENE-6213:
---

Thanks for changing! Sometimes I have a bad day - I was dealing with C code a 
minute ago! :-)

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6919) Log REST info before executing

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-6919:
-
Attachment: SOLR-6919.patch

Slight change to the test case.  Checks that what we are matching against 
doesn't contain the post-debug information (i.e. status, hits, QTime).

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-Tests-5.x-Java7 - Build # 2575 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2575/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:49868/c8n_1x2_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:49868/c8n_1x2_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([F2B3545EEB50BB53:7AE76B8445ACD6AB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Updated] (SOLR-4905) Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded collection that has a replica on all nodes

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-4905:
-
Attachment: SOLR-4905.patch

Updated patch that removes the change to core container in the previous patch 
and checks if the fromIndex is a collection alias. I wasn't sure how to handle 
aliases that point to multiple collections, so that produces an error now. I 
think this is ready to commit unless there are any other comments?

 Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded 
 collection that has a replica on all nodes
 --

 Key: SOLR-4905
 URL: https://issues.apache.org/jira/browse/SOLR-4905
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Philip K. Warren
Assignee: Timothy Potter
 Attachments: SOLR-4905.patch, SOLR-4905.patch, patch.txt


 Using a non-SolrCloud setup, it is possible to perform cross core joins 
 (http://wiki.apache.org/solr/Join). When testing with SolrCloud, however, 
 neither the collection name, alias name (we have created aliases to SolrCloud 
 collections), or the automatically generated core name (i.e. 
 collection_shard1_replica1) work as the fromIndex parameter for a 
 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] (SOLR-4905) Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded collection that has a replica on all nodes

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-4905:
-
Summary: Allow fromIndex parameter to JoinQParserPlugin to refer to a 
single-sharded collection that has a replica on all nodes  (was: Cross core 
joins don't work for SolrCloud collections and/or aliases)

Renaming this ticket to be more clear about the solution it is solving.

 Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded 
 collection that has a replica on all nodes
 --

 Key: SOLR-4905
 URL: https://issues.apache.org/jira/browse/SOLR-4905
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Philip K. Warren
Assignee: Timothy Potter
 Attachments: SOLR-4905.patch, patch.txt


 Using a non-SolrCloud setup, it is possible to perform cross core joins 
 (http://wiki.apache.org/solr/Join). When testing with SolrCloud, however, 
 neither the collection name, alias name (we have created aliases to SolrCloud 
 collections), or the automatically generated core name (i.e. 
 collection_shard1_replica1) work as the fromIndex parameter for a 
 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

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1927 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1927/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
{   responseHeader:{ status:404, QTime:6},   error:{ 
msg:no such blob or version available: test/1, code:404}}

Stack Trace:
java.lang.AssertionError: {
  responseHeader:{
status:404,
QTime:6},
  error:{
msg:no such blob or version available: test/1,
code:404}}
at 
__randomizedtesting.SeedInfo.seed([905D7635214CC760:48105B62D69162C0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:108)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2576 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2576/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([7112BEB7591E3ECE:F946816DF7E25336]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Commented] (SOLR-6919) Log REST info before executing

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302327#comment-14302327
 ] 

Mark Miller commented on SOLR-6919:
---

We might want to consider making this a special log object like Lucene's 
IndexWriter Info Logger. Having to turn on DEBUG for the whole SolrCore class 
means it's fairly likely that you could inadvertently add a lot of debug 
chatter in the logs in the future when you really just want to turn on logging 
the query before it's executed.

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-6919) Log REST info before executing

[Gregory Chanan (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302354#comment-14302354
 ] 

Gregory Chanan commented on SOLR-6919:
--

bq. We might want to consider making this a special log object like Lucene's 
IndexWriter Info Logger. Having to turn on DEBUG for the whole SolrCore class 
means it's fairly likely that you could inadvertently add a lot of debug 
chatter in the logs in the future when you really just want to turn on logging 
the query before it's executed.

Seems reasonable, do you have a pointer to the Lucene IndexWriter Info Logger?  
FWIW, I only see one other debug statement in SolrCore trunk, and it's in an 
unexpected situation.  So I don't think this is high priority.

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-6919) Log REST info before executing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302079#comment-14302079
 ] 

ASF subversion and git services commented on SOLR-6919:
---

Commit 1656596 from gcha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1656596 ]

SOLR-6919: Log REST info before executing

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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-6919) Log REST info before executing

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302081#comment-14302081
 ] 

ASF subversion and git services commented on SOLR-6919:
---

Commit 1656597 from gcha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656597 ]

SOLR-6919: Log REST info before executing

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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] (SOLR-6919) Log REST info before executing

[Gregory Chanan (JIRA)]

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

Gregory Chanan resolved SOLR-6919.
--
   Resolution: Fixed
Fix Version/s: 5.1
   Trunk

Committed to Trunk and 5.1, thanks for the patch, Mike!

 Log REST info before executing
 --

 Key: SOLR-6919
 URL: https://issues.apache.org/jira/browse/SOLR-6919
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Mike Drob
Assignee: Gregory Chanan
Priority: Minor
 Fix For: Trunk, 5.1

 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch


 We should log request info (path, parameters, etc...) before attempting to 
 execute a query. This is helpful in cases where we get a bad query that 
 causes OOM or something else catastrophic, and are doing post-event triage.



--
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_31) - Build # 4458 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4458/
Java: 64bit/jdk1.8.0_31 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrConfigHandler

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\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf\params.json: 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\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf\params.json: 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\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1\conf
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010\collection1
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001\tempDir-010
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 1C957D9B0F39D234-001: java.nio.file.DirectoryNotEmptyException: 

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2573 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2573/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([520416BD7086DA5C:DA502967DE7AB7A4]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Commented] (SOLR-7068) Collapse on numeric field breaks when min/max values are negative.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301308#comment-14301308
 ] 

ASF subversion and git services commented on SOLR-7068:
---

Commit 1656467 from [~joel.bernstein] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656467 ]

SOLR-7068: Update CHANGES.txt

 Collapse on numeric field breaks when min/max values are negative.
 --

 Key: SOLR-7068
 URL: https://issues.apache.org/jira/browse/SOLR-7068
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Joel Bernstein
 Attachments: SOLR-7068.patch


 The new Solr 5.0 CollapsingQParserPlugin does not collapse properly when 
 collapsing on numeric field and min/max values are negative. 



--
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-7068) Collapse on numeric field breaks when min/max values are negative.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301309#comment-14301309
 ] 

ASF subversion and git services commented on SOLR-7068:
---

Commit 1656468 from [~joel.bernstein] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1656468 ]

SOLR-7068: Update CHANGES.txt

 Collapse on numeric field breaks when min/max values are negative.
 --

 Key: SOLR-7068
 URL: https://issues.apache.org/jira/browse/SOLR-7068
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Joel Bernstein
 Attachments: SOLR-7068.patch


 The new Solr 5.0 CollapsingQParserPlugin does not collapse properly when 
 collapsing on numeric field and min/max values are negative. 



--
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-4524) Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum

[Alan Woodward (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301127#comment-14301127
 ] 

Alan Woodward commented on LUCENE-4524:
---

This is a pre-requisite issue for that, but it doesn't implement it for now.  
All it does is merge the two different postings enumerations, which has a 
follow-on effect that Scorer now has position, offset and payload methods.  For 
now they're not actually implemented for most Scorers though.  That can be done 
in follow-up issues.

 Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
 -

 Key: LUCENE-4524
 URL: https://issues.apache.org/jira/browse/LUCENE-4524
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/codecs, core/index, core/search
Affects Versions: 4.0
Reporter: Simon Willnauer
 Fix For: 4.9, Trunk

 Attachments: LUCENE-4524.patch, LUCENE-4524.patch, LUCENE-4524.patch, 
 LUCENE-4524.patch, LUCENE-4524.patch, LUCENE-4524.patch


 spinnoff from http://www.gossamer-threads.com/lists/lucene/java-dev/172261
 {noformat}
 hey folks, 
 I have spend a hell lot of time on the positions branch to make 
 positions and offsets working on all queries if needed. The one thing 
 that bugged me the most is the distinction between DocsEnum and 
 DocsAndPositionsEnum. Really when you look at it closer DocsEnum is a 
 DocsAndFreqsEnum and if we omit Freqs we should return a DocIdSetIter. 
 Same is true for 
 DocsAndPostionsAndPayloadsAndOffsets*YourFancyFeatureHere*Enum. I 
 don't really see the benefits from this. We should rather make the 
 interface simple and call it something like PostingsEnum where you 
 have to specify flags on the TermsIterator and if we can't provide the 
 sufficient enum we throw an exception? 
 I just want to bring up the idea here since it might simplify a lot 
 for users as well for us when improving our positions / offset etc. 
 support. 
 thoughts? Ideas? 
 simon 
 {noformat}



--
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-6841) Visualize lucene segment info in admin

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301165#comment-14301165
 ] 

Varun Thacker commented on SOLR-6841:
-

This is cool!

While playing around I observed that when there are no segments in the index, 
the Segments Info page says:
Size 0
Deletions: NaN%

In the future it would be awesome if we could click on a segment we could get 
more granular information about it like the number of fields in the segment, 
number of terms in that field, memory consumed by the segment etc. 

 Visualize lucene segment info in admin
 --

 Key: SOLR-6841
 URL: https://issues.apache.org/jira/browse/SOLR-6841
 Project: Solr
  Issue Type: Improvement
Reporter: Alexey Kozhemiakin
 Fix For: 5.0

 Attachments: (old)Overview page.png, SOLR-6841.patch, 
 segments_info.png, segments_info_merge_candidates.png


 We find it useful to tune merge policy not blindly but looking on segment 
 size and fill ratio.
 We're working on a patch that adds a tab to admin page with McCandless-style 
 of segment visualization.
 Draft UI is attached (currenly as part of admin.extra).
 Please share your ideas if it's ok to put the code in core admin.
 More details here
 http://search-lucene.com/m/QTPa44cNJ1 
 https://plus.google.com/+MichaelMcCandless/posts/MJVueTznYnD
 http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html



--
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-7069) A down core(shard replica) on an active node cannot failover the query to its good peer

[Forest Soup (JIRA)]

Forest Soup created SOLR-7069:
-

 Summary: A down core(shard replica) on an active node cannot 
failover the query to its good peer
 Key: SOLR-7069
 URL: https://issues.apache.org/jira/browse/SOLR-7069
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
Reporter: Forest Soup






--
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-3922) Add Japanese Kanji number normalization to Kuromoji

[Christian Moen (JIRA)]

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

Christian Moen updated LUCENE-3922:
---
Fix Version/s: 5.1

 Add Japanese Kanji number normalization to Kuromoji
 ---

 Key: LUCENE-3922
 URL: https://issues.apache.org/jira/browse/LUCENE-3922
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.0-ALPHA
Reporter: Kazuaki Hiraga
Assignee: Christian Moen
  Labels: features
 Fix For: 5.1

 Attachments: LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, 
 LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch


 Japanese people use Kanji numerals instead of Arabic numerals for writing 
 price, address and so on. i.e 12万4800円(124,800JPY), 二番町三ノ二(3-2 Nibancho) and 
 十二月(December).  So, we would like to normalize those Kanji numerals to Arabic 
 numerals (I don't think we need to have a capability to normalize to Kanji 
 numerals).
  



--
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-3922) Add Japanese Kanji number normalization to Kuromoji

[Christian Moen (JIRA)]

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

Christian Moen updated LUCENE-3922:
---
Attachment: LUCENE-3922.patch

Updated patch with decimal number support, additional javadoc and the test code 
now makes precommit happy.

Token-attributes such as part-of-speech, readings, etc. for the normalized 
token is currently inherited from the last token used when composing the 
normalized number. Since these values are likely to be wrong, I'm inclined to 
set this attributes to null or a reasonable default.

I'm very happy to hear your thoughts on this.



 Add Japanese Kanji number normalization to Kuromoji
 ---

 Key: LUCENE-3922
 URL: https://issues.apache.org/jira/browse/LUCENE-3922
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Affects Versions: 4.0-ALPHA
Reporter: Kazuaki Hiraga
Assignee: Christian Moen
  Labels: features
 Fix For: 5.1

 Attachments: LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, 
 LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch, LUCENE-3922.patch


 Japanese people use Kanji numerals instead of Arabic numerals for writing 
 price, address and so on. i.e 12万4800円(124,800JPY), 二番町三ノ二(3-2 Nibancho) and 
 十二月(December).  So, we would like to normalize those Kanji numerals to Arabic 
 numerals (I don't think we need to have a capability to normalize to Kanji 
 numerals).
  



--
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-7069) A down core(shard replica) on an active node cannot failover the query to its good peer

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-7069:
--
Description: When querying a collection with a core in down state, if we 
send the request to the server containing the down core, while the server is 
active, it cannot failover to the good replica of same shard on another server.

 A down core(shard replica) on an active node cannot failover the query to its 
 good peer
 ---

 Key: SOLR-7069
 URL: https://issues.apache.org/jira/browse/SOLR-7069
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
Reporter: Forest Soup

 When querying a collection with a core in down state, if we send the 
 request to the server containing the down core, while the server is active, 
 it cannot failover to the good replica of same shard on another server.



--
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-7068) Collapse on numeric field breaks when min/max values are negative.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301303#comment-14301303
 ] 

ASF subversion and git services commented on SOLR-7068:
---

Commit 1656465 from [~joel.bernstein] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1656465 ]

SOLR-7068: Collapse on numeric field breaks when min/max values are negative.

 Collapse on numeric field breaks when min/max values are negative.
 --

 Key: SOLR-7068
 URL: https://issues.apache.org/jira/browse/SOLR-7068
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Joel Bernstein
 Attachments: SOLR-7068.patch


 The new Solr 5.0 CollapsingQParserPlugin does not collapse properly when 
 collapsing on numeric field and min/max values are negative. 



--
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-7069) A down core(shard replica) on an active node cannot failover the query to its good peer

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-7069:
--
Description: 
When querying a collection with a core in down state, if we send the request 
to the server containing the down core, while the server is active, it cannot 
failover to the good replica of same shard on another server.

The steps to make a core down on an active server is:
1, delete the content of the data folder of the core
2, restart the solr server the core locates.
Then we can see the core is down while other cores on the same server is 
still active. See attached picture.

When we issue a query to the collection, if we send the request to the server 
containing the down core, we receive below errors:
HTTP Status 500 - {msg=SolrCore 'collection5_shard1_replica2' is not available 
due to init failure: Error opening new 
searcher,trace=org.apache.solr.common.SolrException: SolrCore 
'collection5_shard1_replica2' is not available due to init failure: Error 
opening new searcher at 
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:309)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) 
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) 
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
 at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
 at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) 
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:804) Caused by: 
org.apache.solr.common.SolrException: Error opening new searcher at 
org.apache.solr.core.SolrCore.init(SolrCore.java:844) at 
org.apache.solr.core.SolrCore.init(SolrCore.java:630) at 
org.apache.solr.core.ZkContainer.createFromZk(ZkContainer.java:244) at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:595) at 
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258) at 
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250) at 
java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482) at 
java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) 
... 1 more Caused by: org.apache.solr.common.SolrException: Error opening new 
searcher at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1521) 
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1633) at 
org.apache.solr.core.SolrCore.init(SolrCore.java:827) ... 11 more Caused by: 
java.io.FileNotFoundException: 
/mnt/solrdata1/solr/home/collection5_shard1_replica2/data/index/_12x.si (No 
such file or directory) at 
java.io.RandomAccessFile.init(RandomAccessFile.java:252) at 
org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:193) at 
org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:233)
 at 
org.apache.lucene.codecs.lucene46.Lucene46SegmentInfoReader.read(Lucene46SegmentInfoReader.java:49)
 at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:340) at 
org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:404) at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:843)
 at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:694)
 at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:400) at 
org.apache.lucene.index.IndexWriter.init(IndexWriter.java:741) at 
org.apache.solr.update.SolrIndexWriter.init(SolrIndexWriter.java:77) at 
org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:64) at 

[jira] [Updated] (SOLR-7069) A down core(shard replica) on an active node cannot failover the query to its good peer

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-7069:
--
Attachment: Untitled.png

A down core on an active node.

 A down core(shard replica) on an active node cannot failover the query to its 
 good peer
 ---

 Key: SOLR-7069
 URL: https://issues.apache.org/jira/browse/SOLR-7069
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
Reporter: Forest Soup
 Attachments: Untitled.png


 When querying a collection with a core in down state, if we send the 
 request to the server containing the down core, while the server is active, 
 it cannot failover to the good replica of same shard on another server.
 The steps to make a core down on an active server is:
 1, delete the content of the data folder of the core
 2, restart the solr server the core locates.
 Then we can see the core is down while other cores on the same server is 
 still active. See attached picture.
 When we issue a query to the collection, if we send the request to the server 
 containing the down core, we receive below errors:
 HTTP Status 500 - {msg=SolrCore 'collection5_shard1_replica2' is not 
 available due to init failure: Error opening new 
 searcher,trace=org.apache.solr.common.SolrException: SolrCore 
 'collection5_shard1_replica2' is not available due to init failure: Error 
 opening new searcher at 
 org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:309)
  at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
  at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
  at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
  at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
  at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
  at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) 
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) 
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
  at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) 
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
  at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
  at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
  at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
  at 
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
  at java.lang.Thread.run(Thread.java:804) Caused by: 
 org.apache.solr.common.SolrException: Error opening new searcher at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:844) at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:630) at 
 org.apache.solr.core.ZkContainer.createFromZk(ZkContainer.java:244) at 
 org.apache.solr.core.CoreContainer.create(CoreContainer.java:595) at 
 org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258) at 
 org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250) at 
 java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482) at 
 java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
  ... 1 more Caused by: org.apache.solr.common.SolrException: Error opening 
 new searcher at 
 org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1521) at 
 org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1633) at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:827) ... 11 more Caused 
 by: java.io.FileNotFoundException: 
 /mnt/solrdata1/solr/home/collection5_shard1_replica2/data/index/_12x.si (No 
 such file or directory) at 
 java.io.RandomAccessFile.init(RandomAccessFile.java:252) at 
 org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:193) at 
 org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:233)
  at 
 org.apache.lucene.codecs.lucene46.Lucene46SegmentInfoReader.read(Lucene46SegmentInfoReader.java:49)
  at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:340) at 
 

[jira] [Commented] (SOLR-7068) Collapse on numeric field breaks when min/max values are negative.

[Joel Bernstein (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301301#comment-14301301
 ] 

Joel Bernstein commented on SOLR-7068:
--

This is purely a bugfix and only effects the CollapsingQParserPlugin, so I 
think it's safe to backport for 5.0. I'll be doing this shortly. 

 Collapse on numeric field breaks when min/max values are negative.
 --

 Key: SOLR-7068
 URL: https://issues.apache.org/jira/browse/SOLR-7068
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Joel Bernstein
 Attachments: SOLR-7068.patch


 The new Solr 5.0 CollapsingQParserPlugin does not collapse properly when 
 collapsing on numeric field and min/max values are negative. 



--
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-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301304#comment-14301304
 ] 

Karl Wright commented on LUCENE-6196:
-

bq. Where in the design is it restricted to lucene?

I did not claim it was restricted to Lucene.  My claim is that the 
functionality is expressly designed to solve the geographic search problem, 
which to me consists of three parts: geohash construction, highly-performant  
result filtering, and highly-performant distance scoring functionality.  A 
general package, in my view, is distinct in the following ways:

(1) It tends to try to solve a broader set of geographic problems, i.e. 
computing a shape's area, intersecting shapes, etc.
(2) There is much less emphasis on the highly-performant computational 
requirements mentioned above; general packages by and large don't have the 
expensive construction/dirt cheap individual evaluation requirement that 
search engines like Lucene would have.

Having said that, I have no objection if you want to use this code in 
spatial4j.  I just cannot contribute to spatial4j at the moment.  And I do 
think that there is a close-enough relationship between the search problem and 
geo3d that it isn't unreasonable to include geo3d in Lucene.



 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_31) - Build # 4456 - Still Failing!

[Robert Muir]

I tried beasting this seed with and without G1... this one recently
started failing fairly regularly, and it never reproduces.

On Mon, Feb 2, 2015 at 2:16 AM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4456/
 Java: 32bit/jdk1.8.0_31 -server -XX:+UseG1GC

 1 tests failed.
 FAILED:  
 org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling

 Error Message:
 68

 Stack Trace:
 java.lang.ArrayIndexOutOfBoundsException: 68
 at 
 __randomizedtesting.SeedInfo.seed([8FD1B023DB0139E2:65C9D93E6A56CE55]:0)
 at 
 org.apache.lucene.facet.TestRandomSamplingFacetsCollector.testRandomSampling(TestRandomSamplingFacetsCollector.java:133)
 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:483)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 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:836)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 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)




 Build Log:
 [...truncated 5928 lines...]
[junit4] Suite: org.apache.lucene.facet.TestRandomSamplingFacetsCollector
[junit4]   2 NOTE: reproduce with: ant test  
 -Dtestcase=TestRandomSamplingFacetsCollector 
 -Dtests.method=testRandomSampling -Dtests.seed=8FD1B023DB0139E2 
 -Dtests.slow=true 

[jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Nicholas Knize (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301274#comment-14301274
 ] 

Nicholas Knize commented on LUCENE-6196:


bq.  Spatial4j is totally wired into a latitude/longitude bounding box 
geometry, and most of the methods required by Shape objects have no 
implementation in a geo3d world. 

David can elaborate, but at the moment that's only a temporary delimitation of 
spatial4j, not a limitation. Spatial4J is intended to expand on JTS (but w/ an 
ASF license) for geospatial applications, not intended to remain restricted to 
a 2D (lat/lon) set of capabilities.  That's why integrating this within S4J is 
an attractive approach.

bq. The geo3d world has exactly what is needed for lucene searching, and no 
more.

It looks to me that any index/search approach based on a space filling curve 
would benefit from geo3d.  In fact, what you have here can just as easily be 
applied to an R/R*-Tree algorithm.  Where in the design is it restricted to 
lucene?

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-7069) A down core(shard replica) on an active node cannot failover the query to its good peer on another server

[Forest Soup (JIRA)]

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

Forest Soup updated SOLR-7069:
--
Summary: A down core(shard replica) on an active node cannot failover the 
query to its good peer on another server  (was: A down core(shard replica) on 
an active node cannot failover the query to its good peer)

 A down core(shard replica) on an active node cannot failover the query to its 
 good peer on another server
 -

 Key: SOLR-7069
 URL: https://issues.apache.org/jira/browse/SOLR-7069
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.7
Reporter: Forest Soup
 Attachments: Untitled.png


 When querying a collection with a core in down state, if we send the 
 request to the server containing the down core, while the server is active, 
 it cannot failover to the good replica of same shard on another server.
 The steps to make a core down on an active server is:
 1, delete the content of the data folder of the core
 2, restart the solr server the core locates.
 Then we can see the core is down while other cores on the same server is 
 still active. See attached picture.
 When we issue a query to the collection, if we send the request to the server 
 containing the down core, we receive below errors:
 HTTP Status 500 - {msg=SolrCore 'collection5_shard1_replica2' is not 
 available due to init failure: Error opening new 
 searcher,trace=org.apache.solr.common.SolrException: SolrCore 
 'collection5_shard1_replica2' is not available due to init failure: Error 
 opening new searcher at 
 org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:309)
  at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
  at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
  at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
  at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
  at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
  at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) 
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950) 
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
  at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) 
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
  at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
  at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
  at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
  at 
 org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
  at java.lang.Thread.run(Thread.java:804) Caused by: 
 org.apache.solr.common.SolrException: Error opening new searcher at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:844) at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:630) at 
 org.apache.solr.core.ZkContainer.createFromZk(ZkContainer.java:244) at 
 org.apache.solr.core.CoreContainer.create(CoreContainer.java:595) at 
 org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258) at 
 org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250) at 
 java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482) at 
 java.util.concurrent.FutureTask.run(FutureTask.java:273) at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
  at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626)
  ... 1 more Caused by: org.apache.solr.common.SolrException: Error opening 
 new searcher at 
 org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1521) at 
 org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1633) at 
 org.apache.solr.core.SolrCore.init(SolrCore.java:827) ... 11 more Caused 
 by: java.io.FileNotFoundException: 
 /mnt/solrdata1/solr/home/collection5_shard1_replica2/data/index/_12x.si (No 
 such file or directory) at 
 java.io.RandomAccessFile.init(RandomAccessFile.java:252) at 
 org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:193) at 
 org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:233)
  at 
 

[jira] [Commented] (SOLR-7068) Collapse on numeric field breaks when min/max values are negative.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301305#comment-14301305
 ] 

ASF subversion and git services commented on SOLR-7068:
---

Commit 1656466 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1656466 ]

SOLR-7068: Update CHANGES.txt

 Collapse on numeric field breaks when min/max values are negative.
 --

 Key: SOLR-7068
 URL: https://issues.apache.org/jira/browse/SOLR-7068
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Joel Bernstein
 Attachments: SOLR-7068.patch


 The new Solr 5.0 CollapsingQParserPlugin does not collapse properly when 
 collapsing on numeric field and min/max values are negative. 



--
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: [CI] Lucene 5x Linux Java8 64 Test Only - Build # 28403 - Failure!

[Michael McCandless]

Grrr, I'll dig: same test I fixed last time, but this time it's a
different-yet-just-as-scary exc (EOFE vs FNFE).

Mike McCandless

http://blog.mikemccandless.com

On Mon, Feb 2, 2015 at 12:08 AM, bu...@elasticsearch.com wrote:

   *BUILD FAILURE*
 Build URL
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/
 Project:lucene_linux_java8_64_test_only Date of build:Mon, 02 Feb 2015
 06:05:57 +0100 Build duration:2 min 24 sec
  *CHANGES* No Changes
  *BUILD ARTIFACTS*
 checkout/lucene/build/core/test/temp/junit4-J0-20150202_060600_466.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J0-20150202_060600_466.events
 checkout/lucene/build/core/test/temp/junit4-J1-20150202_060600_466.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J1-20150202_060600_466.events
 checkout/lucene/build/core/test/temp/junit4-J2-20150202_060600_466.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J2-20150202_060600_466.events
 checkout/lucene/build/core/test/temp/junit4-J3-20150202_060600_466.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J3-20150202_060600_466.events
 checkout/lucene/build/core/test/temp/junit4-J4-20150202_060600_467.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J4-20150202_060600_467.events
 checkout/lucene/build/core/test/temp/junit4-J5-20150202_060600_467.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J5-20150202_060600_467.events
 checkout/lucene/build/core/test/temp/junit4-J6-20150202_060600_467.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J6-20150202_060600_467.events
 checkout/lucene/build/core/test/temp/junit4-J7-20150202_060600_467.events
 http://build-eu-00.elasticsearch.org/job/lucene_linux_java8_64_test_only/28403/artifact/checkout/lucene/build/core/test/temp/junit4-J7-20150202_060600_467.events
  *FAILED JUNIT TESTS* Name: org.apache.lucene.index Failed: 1 test(s),
 Passed: 746 test(s), Skipped: 19 test(s), Total: 766 test(s)
 *Failed:
 org.apache.lucene.index.TestBinaryDocValuesUpdates.testManyReopensAndFields
 *
  *CONSOLE OUTPUT* [...truncated 1561 lines...] [junit4]  [junit4] Tests
 with failures: [junit4] -
 org.apache.lucene.index.TestBinaryDocValuesUpdates.testManyReopensAndFields 
 [junit4]
  [junit4]  [junit4] JVM J0: 1.07 .. 124.01 = 122.94s [junit4] JVM J1:
 1.07 .. 126.70 = 125.63s [junit4] JVM J2: 1.08 .. 123.69 = 122.61s [junit4]
 JVM J3: 0.87 .. 124.41 = 123.54s [junit4] JVM J4: 1.18 .. 129.11 = 127.93s 
 [junit4]
 JVM J5: 1.10 .. 131.12 = 130.02s [junit4] JVM J6: 1.07 .. 125.55 = 124.48s 
 [junit4]
 JVM J7: 0.86 .. 125.65 = 124.79s [junit4] Execution time total: 2 minutes
 11 seconds [junit4] Tests summary: 409 suites, 3237 tests, 1 error, 60
 ignored (50 assumptions) BUILD FAILED 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:49:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1363:
 The following error occurred while executing this line: 
 /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:970:
 There were test failures: 409 suites, 3237 tests, 1 error, 60 ignored (50
 assumptions) Total time: 2 minutes 19 seconds Build step 'Invoke Ant'
 marked build as failure Archiving artifacts Recording test results Email
 was triggered for: Failure - 1st Trigger Failure - Any was overridden by
 another trigger and will not send an email. Trigger Failure - Still was
 overridden by another trigger and will not send an email. Sending email
 for trigger: Failure - 1st

[jira] [Resolved] (SOLR-5815) Non-reproducible failures of TestNonNRTOpen.testReaderIsNotNRT

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-5815.
-
   Resolution: Not a Problem
Fix Version/s: 5.0

This is not a problem because the non-nrt mode and this particular test have 
been removed from 5.0

 Non-reproducible failures of TestNonNRTOpen.testReaderIsNotNRT
 --

 Key: SOLR-5815
 URL: https://issues.apache.org/jira/browse/SOLR-5815
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
 Fix For: 5.0

 Attachments: TestNonNRTOpen.txt, 
 jenkins.thetaphi.de_Lucene-Solr-trunk-MacOSX_1486.log.txt


 SOLR-4909 added TestNonNRTOpen on Sep 10, 2013 - since then the policeman 
 jenkins server has reported {{TestNonNRTOpen.testReaderIsNotNRT}} failing 33 
 times by my count -- but i've never been able to reproduce, nor have I seen 
 any similar failures from apache jenkins.
 The failures are all virtually identical, and seem to happen just as likely 
 on 4x/trunk, mac/linux/windows, 1.6/1.7/1.8
 Recent Example...
 {noformat}
[junit4]   2 NOTE: reproduce with: ant test  -Dtestcase=TestNonNRTOpen 
 -Dtests.method=testReaderIsNotNRT -Dtests.seed=8BF5F44429C5ABCA 
 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=nl 
 -Dtests.timezone=America/Whitehorse -Dtests.file.encoding=ISO-8859-1
[junit4] FAILURE 0.23s J0 | TestNonNRTOpen.testReaderIsNotNRT 
[junit4] Throwable #1: java.lang.AssertionError: expected:3 but 
 was:2
[junit4]  at 
 __randomizedtesting.SeedInfo.seed([8BF5F44429C5ABCA:3E7395C39604193E]:0)
[junit4]  at 
 org.apache.solr.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:133)
[junit4]  at 
 org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:94)
[junit4]  at java.lang.Thread.run(Thread.java:744)
 {noformat}



--
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-5.x-Windows (64bit/jdk1.8.0_31) - Build # 4352 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4352/
Java: 64bit/jdk1.8.0_31 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([36840384DC3E4026:BED03C5E72C22DDE]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:284)
at 
org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Updated] (LUCENE-6200) Highlighter sometime went wrong

[thihy (JIRA)]

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

thihy updated LUCENE-6200:
--
Summary: Highlighter sometime went wrong  (was: Highlight with cjkanalyzer 
went wrong)

 Highlighter sometime went wrong
 ---

 Key: LUCENE-6200
 URL: https://issues.apache.org/jira/browse/LUCENE-6200
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.10.2
Reporter: thihy
  Labels: highlighter

 I have write a test case for this. I expect B游戏/B是B游戏/B, but get 
 B游戏是游戏/B
 {code:java}
   public static void main(String[] args) throws IOException,
   InvalidTokenOffsetsException {
   String text = 游戏是游戏;
   String query = 游戏;
   CJKAnalyzer analyzer = new CJKAnalyzer();
   Scorer fragmentScorer = new QueryScorer(new TermQuery(new 
 Term(field,
   query)));
   Highlighter highlighter = new Highlighter(fragmentScorer);
   String fragment = highlighter.getBestFragment(
   analyzer.tokenStream(field, text), text);
   analyzer.close();
   System.out.println(fragment); // println: B游戏是游戏/B
   }
 {code}



--
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-6215) Move NumberRangePrefixTreeStrategy to correct package

[David Smiley (JIRA)]

David Smiley created LUCENE-6215:


 Summary: Move NumberRangePrefixTreeStrategy to correct package
 Key: LUCENE-6215
 URL: https://issues.apache.org/jira/browse/LUCENE-6215
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.1


I completely overlooked that NumberRangePrefixTreeStrategy is in the wrong 
package.  It's at the top level of the spatial package 
{{org.apache.lucene.spatial}} instead of being in the {{prefix}} sub-package.  
Doh!

As soon as LUCENE-5735 finishes up, I'll do an 'svn move', and then add a 
same-named subclass to where it is now extending the real one, and deprecate it 
of course.



--
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-Tests-5.x-Java7 - Build # 2577 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2577/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([DCCE318C9D38F1D2:549A0E5633C49C2A]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_31) - Build # 4354 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4354/
Java: 32bit/jdk1.8.0_31 -server -XX:+UseSerialGC

3 tests failed.
FAILED:  org.apache.solr.core.TestLazyCores.testLazyLoad

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


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

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

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


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

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf\params.json: The process 
cannot access the file because it is being used by another process. 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf\params.json: 
java.nio.file.FileSystemException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf\params.json: The process 
cannot access the file because it is being used by another process.

   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1\conf
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1: 
java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010\collection1
   
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010: java.nio.file.DirectoryNotEmptyException: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-5.x-Windows\solr\build\solr-core\test\J0\temp\solr.core.TestSolrConfigHandler
 24213FA591553A8-001\tempDir-010
   

[jira] [Resolved] (LUCENE-6190) spatial pointsOnly flag shouldn't force predicate to Intersects

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-6190.
--
Resolution: Fixed

 spatial pointsOnly flag shouldn't force predicate to Intersects
 ---

 Key: LUCENE-6190
 URL: https://issues.apache.org/jira/browse/LUCENE-6190
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.1

 Attachments: LUCENE-6190__pointsOnly_RPT_predicate_bug.patch


 In the process of testing the pointsOnly flag, I realized RPT's optimization 
 to force the predicate to Intersects from Within|Contains isn't sound.  In 
 the case of Within, this is only valid if there is one point per document but 
 not multiple (since _all_ points on a doc need to intersect the query shape), 
 and for Contains it was simply wrong.  
 Note that the strategy has no multi-valued hint or some-such.  If it did, 
 then if !multiValued  pointsOnly, *then* Within could be changed to 
 Intersects.  Regardless, swapping the predicate can be done at a higher level 
 (Solr/ES).



--
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-Linux (64bit/jdk1.9.0-ea-b47) - Build # 11733 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
Some resources were not closed, shutdown, or released.

Stack Trace:
java.lang.AssertionError: Some resources were not closed, shutdown, or released.
at __randomizedtesting.SeedInfo.seed([DE996C22B256E59]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:213)
at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:790)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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.CollectionsAPIDistributedZkTest

Error Message:
5 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=3817, 
name=TEST-CollectionsAPIDistributedZkTest.test-seed#[DE996C22B256E59]-EventThread,
 state=WAITING, group=TGRP-CollectionsAPIDistributedZkTest] 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 org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:494)
2) Thread[id=3881, name=zkCallback-483-thread-2, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  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:745)3) Thread[id=3818, 
name=zkCallback-483-thread-1, state=TIMED_WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 

[jira] [Commented] (LUCENE-6190) spatial pointsOnly flag shouldn't force predicate to Intersects

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301327#comment-14301327
 ] 

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

Commit 1656473 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1656473 ]

LUCENE-6190: PrefixTreeStrategy pointsOnly bug: don't switch predicate
 Also refactored placement of hasIndexedLeaves, and fixed a minor 
equals/hashcode bug.

 spatial pointsOnly flag shouldn't force predicate to Intersects
 ---

 Key: LUCENE-6190
 URL: https://issues.apache.org/jira/browse/LUCENE-6190
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.1

 Attachments: LUCENE-6190__pointsOnly_RPT_predicate_bug.patch


 In the process of testing the pointsOnly flag, I realized RPT's optimization 
 to force the predicate to Intersects from Within|Contains isn't sound.  In 
 the case of Within, this is only valid if there is one point per document but 
 not multiple (since _all_ points on a doc need to intersect the query shape), 
 and for Contains it was simply wrong.  
 Note that the strategy has no multi-valued hint or some-such.  If it did, 
 then if !multiValued  pointsOnly, *then* Within could be changed to 
 Intersects.  Regardless, swapping the predicate can be done at a higher level 
 (Solr/ES).



--
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-6196) Include geo3d package, along with Lucene integration to make it useful

[Nicholas Knize (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301356#comment-14301356
 ] 

Nicholas Knize commented on LUCENE-6196:


Intent and design of general utility libraries certainly vary. One thing is for 
sure, they all start somewhere.  IMHO this is a good start to the 3D 
computational geospatial problem space and incubating it within Spatial4J 
(rc-0.4.2 or rc-0.5) would give it broader exposure / potential for greater 
contribution from the geospatial community.

That being said, you're the original author.  I suppose its up to the community 
to decide where the contribution best fits? Taking into consideration, of 
course, the inability for you to continue contributing to one of the candidate 
packages.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-4524) Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301379#comment-14301379
 ] 

Robert Muir commented on LUCENE-4524:
-

Thanks Alan: I benchmarked the current patch, i dont see any performance 
problems:

{noformat}
Task   QPS trunk  StdDev   QPS patch  StdDev
Pct diff
  IntNRQ8.73  (5.7%)8.21  (8.8%)   
-6.0% ( -19% -8%)
   MedPhrase  261.88  (5.1%)  249.79  (4.6%)   
-4.6% ( -13% -5%)
 Prefix3  218.79  (5.3%)  210.03  (6.0%)   
-4.0% ( -14% -7%)
  HighPhrase   18.04  (4.2%)   17.35  (3.3%)   
-3.8% ( -10% -3%)
Wildcard   46.18  (3.3%)   44.65  (5.0%)   
-3.3% ( -11% -5%)
   LowPhrase   34.95  (2.2%)   34.35  (1.5%)   
-1.7% (  -5% -1%)
HighTerm  119.48  (3.7%)  117.73  (5.2%)   
-1.5% ( -10% -7%)
 MedTerm  175.53  (3.5%)  173.14  (5.0%)   
-1.4% (  -9% -7%)
 LowTerm  931.30  (2.9%)  924.38  (4.5%)   
-0.7% (  -7% -6%)
HighSpanNear  143.52  (4.7%)  142.48  (3.5%)   
-0.7% (  -8% -7%)
 LowSpanNear   27.97  (3.4%)   27.79  (2.6%)   
-0.7% (  -6% -5%)
  AndHighLow 1167.87  (2.0%) 1161.24  (2.1%)   
-0.6% (  -4% -3%)
 MedSpanNear  143.90  (4.1%)  143.30  (3.6%)   
-0.4% (  -7% -7%)
OrNotHighLow  953.80  (2.0%)  951.43  (1.7%)   
-0.2% (  -3% -3%)
 LowSloppyPhrase  119.56  (3.0%)  119.79  (2.7%)
0.2% (  -5% -6%)
  Fuzzy1  107.94  (2.7%)  108.20  (3.0%)
0.2% (  -5% -6%)
 Respell   88.19  (3.3%)   88.51  (3.1%)
0.4% (  -5% -6%)
OrNotHighMed  182.77  (2.6%)  183.48  (2.1%)
0.4% (  -4% -5%)
 MedSloppyPhrase   15.83  (4.8%)   15.91  (4.5%)
0.5% (  -8% -   10%)
  Fuzzy2   66.59  (2.9%)   66.96  (3.1%)
0.5% (  -5% -6%)
 AndHighHigh   87.34  (1.9%)   88.01  (1.6%)
0.8% (  -2% -4%)
  AndHighMed  122.26  (2.0%)  123.39  (1.5%)
0.9% (  -2% -4%)
   OrNotHighHigh   48.70  (3.6%)   49.29  (4.4%)
1.2% (  -6% -9%)
   OrHighNotHigh   29.09  (3.7%)   29.44  (4.5%)
1.2% (  -6% -9%)
   OrHighLow   55.62  (7.6%)   56.35  (9.5%)
1.3% ( -14% -   19%)
OrHighNotMed   87.78  (3.9%)   88.99  (5.0%)
1.4% (  -7% -   10%)
OrHighNotLow  106.31  (4.1%)  107.84  (5.4%)
1.4% (  -7% -   11%)
   OrHighMed   57.15  (7.7%)   58.06  (9.5%)
1.6% ( -14% -   20%)
  OrHighHigh   26.80  (8.3%)   27.26 (10.1%)
1.7% ( -15% -   21%)
HighSloppyPhrase   13.10 (11.3%)   13.43 (12.1%)
2.5% ( -18% -   29%)
{noformat}

I will try to go thru it today and review the changes.

 Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
 -

 Key: LUCENE-4524
 URL: https://issues.apache.org/jira/browse/LUCENE-4524
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/codecs, core/index, core/search
Affects Versions: 4.0
Reporter: Simon Willnauer
 Fix For: 4.9, Trunk

 Attachments: LUCENE-4524.patch, LUCENE-4524.patch, LUCENE-4524.patch, 
 LUCENE-4524.patch, LUCENE-4524.patch, LUCENE-4524.patch


 spinnoff from http://www.gossamer-threads.com/lists/lucene/java-dev/172261
 {noformat}
 hey folks, 
 I have spend a hell lot of time on the positions branch to make 
 positions and offsets working on all queries if needed. The one thing 
 that bugged me the most is the distinction between DocsEnum and 
 DocsAndPositionsEnum. Really when you look at it closer DocsEnum is a 
 DocsAndFreqsEnum and if we omit Freqs we should return a DocIdSetIter. 
 Same is true for 
 DocsAndPostionsAndPayloadsAndOffsets*YourFancyFeatureHere*Enum. I 
 don't really see the benefits from this. We should rather make the 
 interface simple and call it something like PostingsEnum where you 
 have to specify flags on the TermsIterator and if we can't provide the 
 sufficient enum we throw an exception? 
 I just want to bring up the idea here since it might simplify a lot 
 for users as well for us when improving our positions / offset etc. 
 support. 
 thoughts? 

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1926 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1926/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.handler.component.DistributedFacetPivotLongTailTest.test

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

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:61733//collection1
at 
__randomizedtesting.SeedInfo.seed([76CD2F69FA512F7B:FE9910B354AD4283]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:568)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:214)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:210)
at 
org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:124)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:124)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:110)
at 
org.apache.solr.handler.component.DistributedFacetPivotLongTailTest.test(DistributedFacetPivotLongTailTest.java:100)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Commented] (LUCENE-6190) spatial pointsOnly flag shouldn't force predicate to Intersects

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301330#comment-14301330
 ] 

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

Commit 1656475 from [~dsmiley] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656475 ]

LUCENE-6190: PrefixTreeStrategy pointsOnly bug: don't switch predicate
 Also refactored placement of hasIndexedLeaves, and fixed a minor 
equals/hashcode bug.

 spatial pointsOnly flag shouldn't force predicate to Intersects
 ---

 Key: LUCENE-6190
 URL: https://issues.apache.org/jira/browse/LUCENE-6190
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.1

 Attachments: LUCENE-6190__pointsOnly_RPT_predicate_bug.patch


 In the process of testing the pointsOnly flag, I realized RPT's optimization 
 to force the predicate to Intersects from Within|Contains isn't sound.  In 
 the case of Within, this is only valid if there is one point per document but 
 not multiple (since _all_ points on a doc need to intersect the query shape), 
 and for Contains it was simply wrong.  
 Note that the strategy has no multi-valued hint or some-such.  If it did, 
 then if !multiValued  pointsOnly, *then* Within could be changed to 
 Intersects.  Regardless, swapping the predicate can be done at a higher level 
 (Solr/ES).



--
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-6640) ChaosMonkeySafeLeaderTest failure with CorruptIndexException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302858#comment-14302858
 ] 

ASF subversion and git services commented on SOLR-6640:
---

Commit 1656631 from sha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656631 ]

SOLR-6640: Use SegmentInfos.files in unused file check

 ChaosMonkeySafeLeaderTest failure with CorruptIndexException
 

 Key: SOLR-6640
 URL: https://issues.apache.org/jira/browse/SOLR-6640
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 5.0
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.0

 Attachments: Lucene-Solr-5.x-Linux-64bit-jdk1.8.0_20-Build-11333.txt, 
 SOLR-6640-test.patch, SOLR-6640.patch, SOLR-6640.patch, SOLR-6640.patch, 
 SOLR-6640.patch, SOLR-6640_new_index_dir.patch, corruptindex.log


 Test failure found on jenkins:
 http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11333/
 {code}
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
 Error Message:
 shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 Stack Trace:
 java.lang.AssertionError: shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 at 
 __randomizedtesting.SeedInfo.seed([F4B371D421E391CD:7555FFCC56BCF1F1]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1255)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1234)
 at 
 org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:162)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
 {code}
 Cause of inconsistency is:
 {code}
 Caused by: org.apache.lucene.index.CorruptIndexException: file mismatch, 
 expected segment id=yhq3vokoe1den2av9jbd3yp8, got=yhq3vokoe1den2av9jbd3yp7 
 (resource=BufferedChecksumIndexInput(MMapIndexInput(path=/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-F4B371D421E391CD-001/tempDir-001/jetty3/index/_1_2.liv)))
[junit4]   2  at 
 org.apache.lucene.codecs.CodecUtil.checkSegmentHeader(CodecUtil.java:259)
[junit4]   2  at 
 org.apache.lucene.codecs.lucene50.Lucene50LiveDocsFormat.readLiveDocs(Lucene50LiveDocsFormat.java:88)
[junit4]   2  at 
 org.apache.lucene.codecs.asserting.AssertingLiveDocsFormat.readLiveDocs(AssertingLiveDocsFormat.java:64)
[junit4]   2  at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:102)
 {code}



--
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-6640) ChaosMonkeySafeLeaderTest failure with CorruptIndexException

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302857#comment-14302857
 ] 

ASF subversion and git services commented on SOLR-6640:
---

Commit 1656630 from sha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1656630 ]

SOLR-6640: Use SegmentInfos.files in unused file check

 ChaosMonkeySafeLeaderTest failure with CorruptIndexException
 

 Key: SOLR-6640
 URL: https://issues.apache.org/jira/browse/SOLR-6640
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 5.0
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.0

 Attachments: Lucene-Solr-5.x-Linux-64bit-jdk1.8.0_20-Build-11333.txt, 
 SOLR-6640-test.patch, SOLR-6640.patch, SOLR-6640.patch, SOLR-6640.patch, 
 SOLR-6640.patch, SOLR-6640_new_index_dir.patch, corruptindex.log


 Test failure found on jenkins:
 http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11333/
 {code}
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
 Error Message:
 shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 Stack Trace:
 java.lang.AssertionError: shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 at 
 __randomizedtesting.SeedInfo.seed([F4B371D421E391CD:7555FFCC56BCF1F1]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1255)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1234)
 at 
 org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:162)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
 {code}
 Cause of inconsistency is:
 {code}
 Caused by: org.apache.lucene.index.CorruptIndexException: file mismatch, 
 expected segment id=yhq3vokoe1den2av9jbd3yp8, got=yhq3vokoe1den2av9jbd3yp7 
 (resource=BufferedChecksumIndexInput(MMapIndexInput(path=/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-F4B371D421E391CD-001/tempDir-001/jetty3/index/_1_2.liv)))
[junit4]   2  at 
 org.apache.lucene.codecs.CodecUtil.checkSegmentHeader(CodecUtil.java:259)
[junit4]   2  at 
 org.apache.lucene.codecs.lucene50.Lucene50LiveDocsFormat.readLiveDocs(Lucene50LiveDocsFormat.java:88)
[junit4]   2  at 
 org.apache.lucene.codecs.asserting.AssertingLiveDocsFormat.readLiveDocs(AssertingLiveDocsFormat.java:64)
[junit4]   2  at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:102)
 {code}



--
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-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301416#comment-14301416
 ] 

Karl Wright commented on LUCENE-6196:
-

Nicholas,

In the long run I doubt I will continue to have the same restrictions in place 
as to what I can contribute to.  But for now, they are what they are, and I 
have to live within them.

My recommendation: Keep geo3d as a distinct library, within Lucene for the 
moment, but with the option of eventually spinning it off or integrating with 
Spatial4j.  To that end, it would be ideal if it were packaged in its own jar, 
etc.


 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-5379) Query-time multi-word synonym expansion

[Otis Gospodnetic (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301433#comment-14301433
 ] 

Otis Gospodnetic commented on SOLR-5379:


Is there any interest in committing this to 4.x or 5.x?  We have a client at 
Sematext who needs query-time synonym support for their Solr 4.x setup.  So we 
can make sure this patch works for 4.x.  If any of the Solr developers wants to 
commit this to 5.x, please leave a comment here.

 Query-time multi-word synonym expansion
 ---

 Key: SOLR-5379
 URL: https://issues.apache.org/jira/browse/SOLR-5379
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Reporter: Tien Nguyen Manh
  Labels: multi-word, queryparser, synonym
 Fix For: 4.9, Trunk

 Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, 
 quoted.patch, synonym-expander-4_8_1.patch, synonym-expander.patch


 While dealing with synonym at query time, solr failed to work with multi-word 
 synonyms due to some reasons:
 - First the lucene queryparser tokenizes user query by space so it split 
 multi-word term into two terms before feeding to synonym filter, so synonym 
 filter can't recognized multi-word term to do expansion
 - Second, if synonym filter expand into multiple terms which contains 
 multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to 
 handle synonyms. But MultiPhraseQuery don't work with term have different 
 number of words.
 For the first one, we can extend quoted all multi-word synonym in user query 
 so that lucene queryparser don't split it. There are a jira task related to 
 this one https://issues.apache.org/jira/browse/LUCENE-2605.
 For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery 
 SHOULD which contains multiple PhraseQuery in case tokens stream have 
 multi-word synonym.



--
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 # 751 - Still Failing

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:48789/vl/o/c8n_1x2_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:48789/vl/o/c8n_1x2_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([1EB0D3AF9780128D:96E4EC75397C7F75]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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)

[jira] [Commented] (SOLR-6640) ChaosMonkeySafeLeaderTest failure with CorruptIndexException

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301444#comment-14301444
 ] 

Shalin Shekhar Mangar commented on SOLR-6640:
-

I had been ill last week so I am resuming work on this today. 

I suspect you're right, Mark. I should use the info.files(). Better yet, we can 
use SegmentInfos.files(Directory dir, boolean includeSegmentsFile) method and 
avoid iterating through SegmentCommitInfo objects.

 ChaosMonkeySafeLeaderTest failure with CorruptIndexException
 

 Key: SOLR-6640
 URL: https://issues.apache.org/jira/browse/SOLR-6640
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 5.0
Reporter: Shalin Shekhar Mangar
Priority: Blocker
 Fix For: 5.0

 Attachments: Lucene-Solr-5.x-Linux-64bit-jdk1.8.0_20-Build-11333.txt, 
 SOLR-6640-test.patch, SOLR-6640.patch, SOLR-6640.patch, SOLR-6640.patch, 
 SOLR-6640.patch, SOLR-6640_new_index_dir.patch, corruptindex.log


 Test failure found on jenkins:
 http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11333/
 {code}
 1 tests failed.
 REGRESSION:  org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.testDistribSearch
 Error Message:
 shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 Stack Trace:
 java.lang.AssertionError: shard2 is not consistent.  Got 62 from 
 http://127.0.0.1:57436/collection1lastClient and got 24 from 
 http://127.0.0.1:53065/collection1
 at 
 __randomizedtesting.SeedInfo.seed([F4B371D421E391CD:7555FFCC56BCF1F1]:0)
 at org.junit.Assert.fail(Assert.java:93)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1255)
 at 
 org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1234)
 at 
 org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.doTest(ChaosMonkeySafeLeaderTest.java:162)
 at 
 org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869)
 {code}
 Cause of inconsistency is:
 {code}
 Caused by: org.apache.lucene.index.CorruptIndexException: file mismatch, 
 expected segment id=yhq3vokoe1den2av9jbd3yp8, got=yhq3vokoe1den2av9jbd3yp7 
 (resource=BufferedChecksumIndexInput(MMapIndexInput(path=/mnt/ssd/jenkins/workspace/Lucene-Solr-5.x-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.ChaosMonkeySafeLeaderTest-F4B371D421E391CD-001/tempDir-001/jetty3/index/_1_2.liv)))
[junit4]   2  at 
 org.apache.lucene.codecs.CodecUtil.checkSegmentHeader(CodecUtil.java:259)
[junit4]   2  at 
 org.apache.lucene.codecs.lucene50.Lucene50LiveDocsFormat.readLiveDocs(Lucene50LiveDocsFormat.java:88)
[junit4]   2  at 
 org.apache.lucene.codecs.asserting.AssertingLiveDocsFormat.readLiveDocs(AssertingLiveDocsFormat.java:64)
[junit4]   2  at 
 org.apache.lucene.index.SegmentReader.init(SegmentReader.java:102)
 {code}



--
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_31) - Build # 4457 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:284)
at 
org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Commented] (LUCENE-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301651#comment-14301651
 ] 

Uwe Schindler commented on LUCENE-6213:
---

[~jpountz]: Why is the list of unsupported codecs an Array. A simple 
unmodifiable set would be better, would spare lots of code :-) If its a 
singletonSet its even simpler :-) Otherwise use 
{{Collections.unmodifiableSet(new HashSet(Arrays.asList(codecs)))}}. You 
don't need to change that, but to me this looks simplier and more correct. 
Memory usage or speed is not a problem here, it is static and never changes 
after class init.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301961#comment-14301961
 ] 

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

Commit 1656582 from [~rjernst] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1656582 ]

LUCENE-6213: Bikeshed the hell out of a 1 element list

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6196) Include geo3d package, along with Lucene integration to make it useful

[David Smiley (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301476#comment-14301476
 ] 

David Smiley commented on LUCENE-6196:
--

Aha, my hunch was right then.  You've already made your contribution even 
though it hasn't been committed here.  I theoretically don't need anything from 
you for this to have a home in Spatial4j but I'll let you know otherwise -- 
e.g. a simple attestation that you had permission from your employer to license 
it as-such.

I still want to hook a Lucene spatial test to it so see how it fairs.

 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6213:
---
Attachment: LUCENE-6213.patch

Sure, new patch with initCause added.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

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

Ryan Ernst resolved LUCENE-6213.

Resolution: Fixed
  Assignee: Ryan Ernst

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6213:
---
Attachment: LUCENE-6213.patch

I tried the codec idea, but it unfortunately required changing a lot of callers 
to handling IOException or themselves throw IOException, and the change got 
very large.

Here is a new patch (still against branch_5x) that incorporates an additional 
check to give a nice error message if the user should probably include 
backward-codecs.jar.  It also is setup to easily forward port to trunk (just 
adding to the list of unsupportedCodecs).

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301478#comment-14301478
 ] 

Robert Muir commented on LUCENE-6213:
-

I like the simple solution for now! 

When throwing the too-old exception, can we initCause() it with the original 
exception we got? I think it is not good to lose it.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301507#comment-14301507
 ] 

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

Commit 1656523 from [~rjernst] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1656523 ]

LUCENE-6213: Add useful exception message when commit contains segments from 
legacy codecs

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-Tests-5.x-Java7 - Build # 2574 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2574/

11 tests failed.
REGRESSION:  org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.test

Error Message:
Could not get the port for ZooKeeper server

Stack Trace:
java.lang.RuntimeException: Could not get the port for ZooKeeper server
at org.apache.solr.cloud.ZkTestServer.run(ZkTestServer.java:482)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.distribSetUp(AbstractDistribZkTestBase.java:62)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribSetUp(AbstractFullDistribZkTestBase.java:198)
at 
org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.distribSetUp(DeleteLastCustomShardedReplicaTest.java:55)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:910)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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)


REGRESSION:  org.apache.solr.cloud.SaslZkACLProviderTest.testSaslZkACLProvider

Error Message:
Could not get the port for ZooKeeper server

Stack Trace:
java.lang.RuntimeException: Could not get the port for ZooKeeper server
at org.apache.solr.cloud.ZkTestServer.run(ZkTestServer.java:482)
at 
org.apache.solr.cloud.SaslZkACLProviderTest$SaslZkTestServer.run(SaslZkACLProviderTest.java:225)
at 
org.apache.solr.cloud.SaslZkACLProviderTest.setUp(SaslZkACLProviderTest.java:90)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at 

[jira] [Commented] (LUCENE-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301492#comment-14301492
 ] 

Robert Muir commented on LUCENE-6213:
-

+1, the only thing i might do is move unsupportedCodecs to be right above 
readCodec() in the code. 

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301500#comment-14301500
 ] 

Ryan Ernst commented on LUCENE-6213:


Ok, I'll move unsupportedCodecs before committing.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Adrien Grand (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301510#comment-14301510
 ] 

Adrien Grand commented on LUCENE-6213:
--

+1

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301518#comment-14301518
 ] 

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

Commit 1656528 from [~rjernst] in branch 'dev/branches/lucene_solr_5_0'
[ https://svn.apache.org/r1656528 ]

LUCENE-6213: Add useful exception message when commit contains segments from 
legacy codecs (merged 1656523)

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Anshum Gupta (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301559#comment-14301559
 ] 

Anshum Gupta commented on LUCENE-6213:
--

Thanks for getting this into 5.0.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-4905) Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded collection that has a replica on all nodes

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14302699#comment-14302699
 ] 

ASF subversion and git services commented on SOLR-4905:
---

Commit 1656622 from [~thelabdude] in branch 'dev/trunk'
[ https://svn.apache.org/r1656622 ]

SOLR-4905: Allow fromIndex parameter to JoinQParserPlugin to refer to a 
single-sharded collection that has a replica on all nodes

 Allow fromIndex parameter to JoinQParserPlugin to refer to a single-sharded 
 collection that has a replica on all nodes
 --

 Key: SOLR-4905
 URL: https://issues.apache.org/jira/browse/SOLR-4905
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Philip K. Warren
Assignee: Timothy Potter
 Attachments: SOLR-4905.patch, SOLR-4905.patch, patch.txt


 Using a non-SolrCloud setup, it is possible to perform cross core joins 
 (http://wiki.apache.org/solr/Join). When testing with SolrCloud, however, 
 neither the collection name, alias name (we have created aliases to SolrCloud 
 collections), or the automatically generated core name (i.e. 
 collection_shard1_replica1) work as the fromIndex parameter for a 
 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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_31) - Build # 4353 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4353/
Java: 64bit/jdk1.8.0_31 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:57305/repfacttest_c8n_1x3_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:57305/repfacttest_c8n_1x3_shard1_replica1
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:575)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:884)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:787)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.ReplicationFactorTest.testRf3(ReplicationFactorTest.java:284)
at 
org.apache.solr.cloud.ReplicationFactorTest.test(ReplicationFactorTest.java:112)
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:483)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Commented] (LUCENE-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301675#comment-14301675
 ] 

Karl Wright commented on LUCENE-6196:
-

bq.  I theoretically don't need anything from you for this to have a home in 
Spatial4j but I'll let you know otherwise – e.g. a simple attestation that you 
had permission from your employer to license it as-such.

Are you asking me yet again whether I had permission to contribute this?

The permission I have from my employer is a long-granted corporate permission 
to contribute to Lucene and Solr.  My employer is aware that any and all code 
contributed to this project will be licensed with the Apache 2 license.  There 
are, of course, certain restrictions as to exactly *what* can be contributed, 
but I do not believe this geospatial library violates any of those restrictions.

I hope this is sufficient; you are unlikely to get more detail.



 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-6196) Include geo3d package, along with Lucene integration to make it useful

[Karl Wright (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301675#comment-14301675
 ] 

Karl Wright edited comment on LUCENE-6196 at 2/2/15 7:06 PM:
-

bq.  I theoretically don't need anything from you for this to have a home in 
Spatial4j but I'll let you know otherwise – e.g. a simple attestation that you 
had permission from your employer to license it as-such.

Are you asking me yet again whether I had permission to contribute this?

The permission I have from my employer is a long-granted corporate permission 
to contribute to Lucene and Solr.  My employer is aware that any and all code 
contributed to this project will be licensed with the Apache 2 license.  There 
are, of course, certain restrictions as to exactly *what* can be contributed, 
but I do not believe this geospatial library violates any of those restrictions.

I hope this is sufficient; you are unlikely to get more detail.

However, as I have indicated earlier in this thread, unless this code winds up 
in Lucene or Solr, for the moment I can't contribute to it any further.  This 
may change in the future, but that is the situation at the moment.



was (Author: kwri...@metacarta.com):
bq.  I theoretically don't need anything from you for this to have a home in 
Spatial4j but I'll let you know otherwise – e.g. a simple attestation that you 
had permission from your employer to license it as-such.

Are you asking me yet again whether I had permission to contribute this?

The permission I have from my employer is a long-granted corporate permission 
to contribute to Lucene and Solr.  My employer is aware that any and all code 
contributed to this project will be licensed with the Apache 2 license.  There 
are, of course, certain restrictions as to exactly *what* can be contributed, 
but I do not believe this geospatial library violates any of those restrictions.

I hope this is sufficient; you are unlikely to get more detail.



 Include geo3d package, along with Lucene integration to make it useful
 --

 Key: LUCENE-6196
 URL: https://issues.apache.org/jira/browse/LUCENE-6196
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/spatial
Reporter: Karl Wright
Assignee: David Smiley
 Attachments: ShapeImpl.java, geo3d-tests.zip, geo3d.zip


 I would like to explore contributing a geo3d package to Lucene.  This can be 
 used in conjunction with Lucene search, both for generating geohashes (via 
 spatial4j) for complex geographic shapes, as well as limiting results 
 resulting from those queries to those results within the exact shape in 
 highly performant ways.
 The package uses 3d planar geometry to do its magic, which basically limits 
 computation necessary to determine membership (once a shape has been 
 initialized, of course) to only multiplications and additions, which makes it 
 feasible to construct a performant BoostSource-based filter for geographic 
 shapes.  The math is somewhat more involved when generating geohashes, but is 
 still more than fast enough to do a good job.



--
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-6213) Add test for IndexFormatTooOldException if a commit has a 3.x segment

[Ryan Ernst (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301731#comment-14301731
 ] 

Ryan Ernst commented on LUCENE-6213:


[~thetaphi] While that might be less lines of code (but only by 1 or 2 I 
think), that is a much more complicated data structure than an array.  In fact, 
if java just had an {{Arrays.find}} like STL's {{find()}} then there would be 
no difference in number of lines.

 Add test for IndexFormatTooOldException if a commit has a 3.x segment
 -

 Key: LUCENE-6213
 URL: https://issues.apache.org/jira/browse/LUCENE-6213
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Ryan Ernst
 Attachments: LUCENE-6213.patch, LUCENE-6213.patch, LUCENE-6213.patch, 
 unsupported.4x-with-3x-segments.zip


 We should add a 4.x index (4.x commit) with some 3.x segment(s) to our 
 backwards tests.
 I don't think we throw IndexFormatTooOldException correctly in this case. I 
 think instead the user will get a confusing SPI error about a missing codec 
 Lucene3x.



--
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-Tests-5.x-Java7 - Build # 2571 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2571/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([7CCC061A3491FAE1:F49839C09A6D9719]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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 

[jira] [Updated] (SOLR-6841) Visualize lucene segment info in admin

[Michal Bienkowski (JIRA)]

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

Michal Bienkowski updated SOLR-6841:

Attachment: SOLR-6841.patch

 Visualize lucene segment info in admin
 --

 Key: SOLR-6841
 URL: https://issues.apache.org/jira/browse/SOLR-6841
 Project: Solr
  Issue Type: Improvement
Reporter: Alexey Kozhemiakin
 Fix For: 5.0

 Attachments: (old)Overview page.png, SOLR-6841.patch, 
 segments_info.png, segments_info_merge_candidates.png


 We find it useful to tune merge policy not blindly but looking on segment 
 size and fill ratio.
 We're working on a patch that adds a tab to admin page with McCandless-style 
 of segment visualization.
 Draft UI is attached (currenly as part of admin.extra).
 Please share your ideas if it's ok to put the code in core admin.
 More details here
 http://search-lucene.com/m/QTPa44cNJ1 
 https://plus.google.com/+MichaelMcCandless/posts/MJVueTznYnD
 http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html



--
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-6841) Visualize lucene segment info in admin

[Michal Bienkowski (JIRA)]

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

Michal Bienkowski updated SOLR-6841:

Attachment: (was: SOLR-6841.patch)

 Visualize lucene segment info in admin
 --

 Key: SOLR-6841
 URL: https://issues.apache.org/jira/browse/SOLR-6841
 Project: Solr
  Issue Type: Improvement
Reporter: Alexey Kozhemiakin
 Fix For: 5.0

 Attachments: (old)Overview page.png, SOLR-6841.patch, 
 segments_info.png, segments_info_merge_candidates.png


 We find it useful to tune merge policy not blindly but looking on segment 
 size and fill ratio.
 We're working on a patch that adds a tab to admin page with McCandless-style 
 of segment visualization.
 Draft UI is attached (currenly as part of admin.extra).
 Please share your ideas if it's ok to put the code in core admin.
 More details here
 http://search-lucene.com/m/QTPa44cNJ1 
 https://plus.google.com/+MichaelMcCandless/posts/MJVueTznYnD
 http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html



--
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.0 - Build # 21 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.0/21/

No tests ran.

Build Log:
[...truncated 12060 lines...]
BUILD FAILED
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/build.xml:399:
 The following error occurred while executing this line:
/usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.0/lucene/build.xml:389:
 java.net.ConnectException: Operation 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.init(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: 7 minutes 54 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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2572 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2572/

5 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
org.apache.http.NoHttpResponseException: The target server failed to respond

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.NoHttpResponseException: The target server failed to respond
at 
__randomizedtesting.SeedInfo.seed([CBD53B5C9563F223:438104863B9F9FDB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:865)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:730)
at 
org.apache.solr.cloud.HttpPartitionTest.doSendDoc(HttpPartitionTest.java:484)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:501)
at 
org.apache.solr.cloud.HttpPartitionTest.testRf2(HttpPartitionTest.java:193)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:106)
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:1618)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:940)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:915)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
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