date:20160506

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16672/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Error from server at https://127.0.0.1:43203//collection1: Impossible Exception

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:43203//collection1: Impossible Exception
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:557)
at 
org.apache.solr.handler.component.DistributedFacetPivotLongTailTest.test(DistributedFacetPivotLongTailTest.java:236)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 58 - Still Failing

2016-05-06 Thread Apache Jenkins Server

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

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

Error Message:
document count mismatch.  control=3941 sum(shards)=3940 cloudClient=3940

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=3941 
sum(shards)=3940 cloudClient=3940
at 
__randomizedtesting.SeedInfo.seed([8F44261516A7A083:71019CFB85BCD7B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1319)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:228)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Commented] (SOLR-9055) Make collection backup/restore extensible

2016-05-06 Thread Hrishikesh Gadre (JIRA)


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

Hrishikesh Gadre commented on SOLR-9055:


[~markrmil...@gmail.com]

I successfully refactored the "core backup" logic to use the Repository 
interface. But it looks like during "restore" operation we need to use Lucene 
API to compute the file checksum. This API unfortunately requires the Lucene 
Directory/IndexInput implementation.
https://github.com/apache/lucene-solr/blob/a5586d29b23f7d032e6d8f0cf8758e56b09e0208/solr/core/src/java/org/apache/solr/handler/RestoreCore.java#L83

Is there any other way to compute the checksum? Since without such support, we 
will need to implement Directory interface for each type of file-system we want 
to integrate with (and it makes Repository interface redundant). 

Also I didn't quite understand the logic in the following code-block,
https://github.com/apache/lucene-solr/blob/a5586d29b23f7d032e6d8f0cf8758e56b09e0208/solr/core/src/java/org/apache/solr/handler/RestoreCore.java#L88-L95

Why would we want to use the files in the "local" directory? In case of 
collection restoration, there will be no files (since we create a new core). I 
am not sure if I understand the actual problem here...


 



> Make collection backup/restore extensible
> -
>
> Key: SOLR-9055
> URL: https://issues.apache.org/jira/browse/SOLR-9055
> Project: Solr
>  Issue Type: Task
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
> Attachments: SOLR-9055.patch, SOLR-9055.patch
>
>
> SOLR-5750 implemented backup/restore API for Solr. This JIRA is to track the 
> code cleanup/refactoring. Specifically following improvements should be made,
> - Add Solr/Lucene version to check the compatibility between the backup 
> version and the version of Solr on which it is being restored.
> - Add a backup implementation version to check the compatibility between the 
> "restore" implementation and backup format.
> - Introduce a Strategy interface to define how the Solr index data is backed 
> up (e.g. using file copy approach).
> - Introduce a Repository interface to define the file-system used to store 
> the backup data. (currently works only with local file system but can be 
> extended). This should be enhanced to introduce support for "registering" 
> repositories (e.g. HDFS, S3 etc.)



--
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-9068) BadPaddingException when running SSL test using NullSecureRandom


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

Hoss Man updated SOLR-9068:
---
Description: 
In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
was refactored so that both client & server would use it to prevent blocked 
threads waiting for entropy.

Since those commits to master & branch_6x, all Solaris jenkins builds got 
failures at the same spots in 
TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
the root cause appears to be intranode communication failures due to 
"javax.crypto.BadPaddingException"

Initial speculation was that perhaps the Solaris SSL impl has bugs in it's 
padding code that are tickled when the SecureRandom instance returns long 
strings of null bytes, but subsequently we got reports of similar, less 
frequently occuring, bugs on other OSs (see SOLR-9082).

  was:
In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
was refactored so that both client & server would use it to prevent blocked 
threads waiting for entropy.

Since those commits to master & branch_6x, both Solaris jenkins builds have 
seen failures at the same spots in 
TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
the root cause appears to be intranode communication failures due to 
"javax.crypto.BadPaddingException"

Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
when the SecureRandom instance returns long strings of null bytes?

Summary: BadPaddingException when running SSL test using 
NullSecureRandom  (was: Solaris SSL test failures when using NullSecureRandom?)

revised summary & description based on new evidence of this popping up on other 
operating systems (see SOLR-9082) ... although much less often then on Solaris.

I plan to rollback the conditional logic i added in my last commit and just 
complely replace "NullSecureRandom" with the code Uwe already beasted for me 
and rename it  "NotSecurePsuedoRandom" (since NullSecureRandom as a name really 
won't apply anymore)

> BadPaddingException when running SSL test using NullSecureRandom
> 
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, all Solaris jenkins builds got 
> failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Initial speculation was that perhaps the Solaris SSL impl has bugs in it's 
> padding code that are tickled when the SecureRandom instance returns long 
> strings of null bytes, but subsequently we got reports of similar, less 
> frequently occuring, bugs on other OSs (see SOLR-9082).



--
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-6766) Make index sorting a first-class citizen

2016-05-06 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-6766:


And here's the same patch on github: 
https://github.com/apache/lucene-solr/compare/master...mikemccand:index_sort?expand=1

> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-master-Solaris (64bit/jdk1.8.0) - Build # 561 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/561/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, MockDirectoryWrapper, 
SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([3F44ADA783A687EA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor27.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

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

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

[jira] [Updated] (SOLR-9082) TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure


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

Steve Rowe updated SOLR-9082:
-
Attachment: testSslAndNoClientAuth.failure-3.log
testSslAndNoClientAuth.failure-2.log

Attaching the two beasting failure logs ({{git rev-parse HEAD}} says: 
{{26027259a5fff5f8e7df1a927708f048ba92002f}}) - these are the "stdout" files 
produced by Miller's beasting script.

> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure
> 
>
> Key: SOLR-9082
> URL: https://issues.apache.org/jira/browse/SOLR-9082
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: testSslAndNoClientAuth.failure-2.log, 
> testSslAndNoClientAuth.failure-3.log, testSslAndNoClientAuth.failure.log
>
>
> My Jenkins found a non-reproducing seed:
> {noformat}
> Checking out Revision 26027259a5fff5f8e7df1a927708f048ba92002f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testSslAndNoClientAuth 
> -Dtests.seed=99ED450C4584A212 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=fr-LU -Dtests.timezone=America/Resolute -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   9.54s J5  | 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.SolrServerException: IOException occured when 
> talking to server at: https://127.0.0.1:60891/solr
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([99ED450C4584A212:65579138BDA413D8]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
>[junit4]>  at 
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:411)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:395)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:207)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:198)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:146)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:118)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: javax.net.ssl.SSLHandshakeException: Invalid 
> Padding length: 174
>[junit4]>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
>[junit4]>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
>[junit4]>  at 
>

[jira] [Resolved] (SOLR-9082) TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure


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

Hoss Man resolved SOLR-9082.

Resolution: Duplicate

i'm going to resolve as dup and keep tracking this in SOLR-9068

> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure
> 
>
> Key: SOLR-9082
> URL: https://issues.apache.org/jira/browse/SOLR-9082
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: testSslAndNoClientAuth.failure.log
>
>
> My Jenkins found a non-reproducing seed:
> {noformat}
> Checking out Revision 26027259a5fff5f8e7df1a927708f048ba92002f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testSslAndNoClientAuth 
> -Dtests.seed=99ED450C4584A212 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=fr-LU -Dtests.timezone=America/Resolute -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   9.54s J5  | 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.SolrServerException: IOException occured when 
> talking to server at: https://127.0.0.1:60891/solr
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([99ED450C4584A212:65579138BDA413D8]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
>[junit4]>  at 
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:411)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:395)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:207)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:198)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:146)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:118)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: javax.net.ssl.SSLHandshakeException: Invalid 
> Padding length: 174
>[junit4]>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
>[junit4]>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
>[junit4]>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
>[junit4]>  at 
>

[jira] [Commented] (SOLR-9082) TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure


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

Hoss Man commented on SOLR-9082:


Gah ... aparently whatever causes SOLR-9068 isn't as Solaris specific as i 
thought.

> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure
> 
>
> Key: SOLR-9082
> URL: https://issues.apache.org/jira/browse/SOLR-9082
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: testSslAndNoClientAuth.failure.log
>
>
> My Jenkins found a non-reproducing seed:
> {noformat}
> Checking out Revision 26027259a5fff5f8e7df1a927708f048ba92002f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testSslAndNoClientAuth 
> -Dtests.seed=99ED450C4584A212 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=fr-LU -Dtests.timezone=America/Resolute -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   9.54s J5  | 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.SolrServerException: IOException occured when 
> talking to server at: https://127.0.0.1:60891/solr
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([99ED450C4584A212:65579138BDA413D8]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
>[junit4]>  at 
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:411)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:395)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:207)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:198)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:146)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:118)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: javax.net.ssl.SSLHandshakeException: Invalid 
> Padding length: 174
>[junit4]>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
>[junit4]>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
>[junit4]>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
>

[jira] [Updated] (LUCENE-6766) Make index sorting a first-class citizen

2016-05-06 Thread Michael McCandless (JIRA)


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

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

Here's the current patch (generated from {{diffSources.py}})...

> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch, LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-9082) TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure


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

Steve Rowe updated SOLR-9082:
-
Attachment: testSslAndNoClientAuth.failure.log

Attaching full log for the Jenkins failure

> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure
> 
>
> Key: SOLR-9082
> URL: https://issues.apache.org/jira/browse/SOLR-9082
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: testSslAndNoClientAuth.failure.log
>
>
> My Jenkins found a non-reproducing seed:
> {noformat}
> Checking out Revision 26027259a5fff5f8e7df1a927708f048ba92002f 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testSslAndNoClientAuth 
> -Dtests.seed=99ED450C4584A212 -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=fr-LU -Dtests.timezone=America/Resolute -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR   9.54s J5  | 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth <<<
>[junit4]> Throwable #1: 
> org.apache.solr.client.solrj.SolrServerException: IOException occured when 
> talking to server at: https://127.0.0.1:60891/solr
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([99ED450C4584A212:65579138BDA413D8]:0)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
>[junit4]>  at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
>[junit4]>  at 
> org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:411)
>[junit4]>  at 
> org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:395)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:207)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:198)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:146)
>[junit4]>  at 
> org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:118)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: javax.net.ssl.SSLHandshakeException: Invalid 
> Padding length: 174
>[junit4]>  at 
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
>[junit4]>  at 
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
>[junit4]>  at 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
>[junit4]>  at 
> org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
>[junit4]>  at 
> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
>[junit4]>  at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
>[junit4]>  at 
>

[jira] [Created] (SOLR-9082) TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() failure

Steve Rowe created SOLR-9082:


 Summary: TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth() 
failure
 Key: SOLR-9082
 URL: https://issues.apache.org/jira/browse/SOLR-9082
 Project: Solr
  Issue Type: Bug
Reporter: Steve Rowe


My Jenkins found a non-reproducing seed:

{noformat}
Checking out Revision 26027259a5fff5f8e7df1a927708f048ba92002f 
(refs/remotes/origin/master)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testSslAndNoClientAuth 
-Dtests.seed=99ED450C4584A212 -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=fr-LU -Dtests.timezone=America/Resolute -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   9.54s J5  | 
TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:60891/solr
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([99ED450C4584A212:65579138BDA413D8]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:413)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:366)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
   [junit4]>at 
org.apache.solr.cloud.MiniSolrCloudCluster.makeCollectionsRequest(MiniSolrCloudCluster.java:411)
   [junit4]>at 
org.apache.solr.cloud.MiniSolrCloudCluster.createCollection(MiniSolrCloudCluster.java:395)
   [junit4]>at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:207)
   [junit4]>at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:198)
   [junit4]>at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:146)
   [junit4]>at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:118)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: javax.net.ssl.SSLHandshakeException: Invalid 
Padding length: 174
   [junit4]>at 
sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
   [junit4]>at 
sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
   [junit4]>at 
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
   [junit4]>at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
   [junit4]>at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
   [junit4]>at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
   [junit4]>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
   [junit4]>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
   [junit4]>at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
   [junit4]>at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
   [junit4]>at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
   [junit4]>at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
   [junit4]>at 
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
   [junit4]>at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
   [junit4]>at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
   [junit4]>at

[JENKINS] Lucene-Solr-5.5-MacOSX (64bit/jdk1.7.0) - Build # 54 - Failure!

2016-05-06 Thread ASF subversion and git services (JIRA)

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

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:58312/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:58312/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([F78CB6EB044E4319:7FD88931AAB22EE1]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at

[jira] [Commented] (SOLR-5776) Look at speeding up using SSL with tests.


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

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

Commit a5586d29b23f7d032e6d8f0cf8758e56b09e0208 in lucene-solr's branch 
refs/heads/master from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a5586d2 ]

SOLR-9068 / SOLR-5776: Alternate (psuedo random) NullSecureRandom for 
Constants.SUN_OS


> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, master
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
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-9068) Solaris SSL test failures when using NullSecureRandom?

2016-05-06 Thread ASF subversion and git services (JIRA)


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

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

Commit a5586d29b23f7d032e6d8f0cf8758e56b09e0208 in lucene-solr's branch 
refs/heads/master from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a5586d2 ]

SOLR-9068 / SOLR-5776: Alternate (psuedo random) NullSecureRandom for 
Constants.SUN_OS


> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
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-5776) Look at speeding up using SSL with tests.

2016-05-06 Thread ASF subversion and git services (JIRA)


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

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

Commit 7e2f9f506dd3a94c9df0514bf0e22624a8cb0f92 in lucene-solr's branch 
refs/heads/branch_6x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e2f9f5 ]

SOLR-9068 / SOLR-5776: Alternate (psuedo random) NullSecureRandom for 
Constants.SUN_OS

(cherry picked from commit a5586d29b23f7d032e6d8f0cf8758e56b09e0208)

Conflicts:
solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java


> Look at speeding up using SSL with tests.
> -
>
> Key: SOLR-5776
> URL: https://issues.apache.org/jira/browse/SOLR-5776
> Project: Solr
>  Issue Type: Test
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 4.9, master
>
> Attachments: SOLR-5776.patch, SOLR-5776.patch, SOLR-5776.patch
>
>
> We have to disable SSL on a bunch of tests now because it appears to sometime 
> be ridiculously slow - especially in slow envs (I never see timeouts on my 
> machine).
> I was talking to Robert about this, and he mentioned that there might be some 
> settings we could change to speed it up.



--
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-9068) Solaris SSL test failures when using NullSecureRandom?

2016-05-06 Thread ASF subversion and git services (JIRA)


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

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

Commit 7e2f9f506dd3a94c9df0514bf0e22624a8cb0f92 in lucene-solr's branch 
refs/heads/branch_6x from [~hossman_luc...@fucit.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e2f9f5 ]

SOLR-9068 / SOLR-5776: Alternate (psuedo random) NullSecureRandom for 
Constants.SUN_OS

(cherry picked from commit a5586d29b23f7d032e6d8f0cf8758e56b09e0208)

Conflicts:
solr/test-framework/src/java/org/apache/solr/util/SSLTestConfig.java


> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
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-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

2016-05-06 Thread Georg Sorst (JIRA)


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

Georg Sorst updated SOLR-9081:
--
Description: 
{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
currently defined as {{private static void}}. This causes problems with 
Mockito, which requires all test framework methods (including {{@BeforeClass}} 
/ {{@AfterClass}}) to be {{public}}. 

The following test case will show this:

{code:title=MockitoTest.java|borderStyle=solid}
package com.example;

import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {

@Test
public void testSomething() {
  /* Nothing to do, the test runner will fail right away */
}
}
{code}

It will fail with {{java.lang.Exception: Method beforeClass() should be public}}

The very trivial fix is to change both methods to {{public static void}}

  was:
{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
currently defined as {{private static void}}. This causes problems with 
Mockito, which requires all test framework methods (including {{@BeforeClass}} 
/ {{@AfterClass}}) to be {{public}}. 

The following test case will show this:

{code:title=MockitoTest.java|borderStyle=solid}
package com.example;

import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {

@Test
public void testSomething() {
  /* Nothing to do, the test runner will fail right away */
}
}
{code}

It will fail with {{java.lang.Exception: Method beforeClass() should be public}}


> Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with 
> Mockito
> -
>
> Key: SOLR-9081
> URL: https://issues.apache.org/jira/browse/SOLR-9081
> Project: Solr
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0
>Reporter: Georg Sorst
>Priority: Blocker
>
> {{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
> currently defined as {{private static void}}. This causes problems with 
> Mockito, which requires all test framework methods (including 
> {{@BeforeClass}} / {{@AfterClass}}) to be {{public}}. 
> The following test case will show this:
> {code:title=MockitoTest.java|borderStyle=solid}
> package com.example;
> import org.apache.solr.SolrTestCaseJ4;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> import org.mockito.runners.MockitoJUnitRunner;
> @RunWith(MockitoJUnitRunner.class)
> public class MockitoTest extends SolrTestCaseJ4 {
> @Test
> public void testSomething() {
>   /* Nothing to do, the test runner will fail right away */
> }
> }
> {code}
> It will fail with {{java.lang.Exception: Method beforeClass() should be 
> public}}
> The very trivial fix is to change both methods to {{public static void}}



--
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-9081) Make SolrTestCaseJ4.beforeClass() / .afterClass() public so it works with Mockito

2016-05-06 Thread Georg Sorst (JIRA)

Georg Sorst created SOLR-9081:
-

 Summary: Make SolrTestCaseJ4.beforeClass() / .afterClass() public 
so it works with Mockito
 Key: SOLR-9081
 URL: https://issues.apache.org/jira/browse/SOLR-9081
 Project: Solr
  Issue Type: Bug
  Components: Tests
Affects Versions: 6.0
Reporter: Georg Sorst
Priority: Blocker


{{SolrTestCaseJ4.beforeClass()}} / {{SolrTestCaseJ4.afterClass()}} are 
currently defined as {{private static void}}. This causes problems with 
Mockito, which requires all test framework methods (including {{@BeforeClass}} 
/ {{@AfterClass}}) to be {{public}}. 

The following test case will show this:

{code:title=MockitoTest.java|borderStyle=solid}
package com.example;

import org.apache.solr.SolrTestCaseJ4;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.runners.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MockitoTest extends SolrTestCaseJ4 {

@Test
public void testSomething() {
  /* Nothing to do, the test runner will fail right away */
}
}
{code}

It will fail with {{java.lang.Exception: Method beforeClass() should be public}}



--
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-6766) Make index sorting a first-class citizen

2016-05-06 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-6766:


I've been slowly iterating here and pushing changes to 
https://github.com/mikemccand/lucene-solr/tree/index_sort

There are tons of nocommits, but tests do pass, including index sorting tests 
(though they still need improving).

Some details:

  - I added a new {{DocIDMerger}} helper class, and the default merge impls use 
this to abstract away how to iterate the documents from the N sub-readers, 
whether they are simply concatenated or merge-sorted.  I think this should be 
quite a bit more efficient than what {{SortingMergePolicy}} does today, but it 
does add some increase in code complexity, which I think is OK/contained.

  - {{SlowCompositeReader}} is no longer used for index sorting

  - Points now work fine w/ index sorting

  - CheckIndex verifies the claimed per-segment index sort is in fact true

  - IW gets angry if you open an existing index with a different index sort

  - Only simple sort types are allowed; no CUSTOM, SCORE or REWRITEABLE

  - I made a new {{Lucene62Codec}}, with a new {{Lucene62SegmentInfoFormat}} 
that supports index sorting.

  - I added {{LeafReader.getIndexSort}} so apps can check if a given segment 
was sorted

  - I disable bulk merge optos when index sorting is present

IW flush still does not sort, and so at merge time we wrap such segments with 
{{SortingLeafReader}}.  This is quite ugly, that an index can have some 
segments sorted and some not sorted.  E.g. it means IW's check for whether the 
new index sort matches the existing one, is just best effort ... but this is 
already an enormous change so
I think we really have to look into "sort on flush" (which is hairy by itself) 
later, separately


> Make index sorting a first-class citizen
> 
>
> Key: LUCENE-6766
> URL: https://issues.apache.org/jira/browse/LUCENE-6766
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6766.patch
>
>
> Today index sorting is a very expert feature. You need to use a custom merge 
> policy, custom collectors, etc. I would like to explore making it a 
> first-class citizen so that:
>  - the sort order could be configured on IndexWriterConfig
>  - segments would record the sort order that was used to write them
>  - IndexSearcher could automatically early terminate when computing top docs 
> on a sort order that is a prefix of the sort order of a segment (and if the 
> user is not interested in totalHits).



--
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-9080) DateMath is broken before the year 1582


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

David Smiley commented on SOLR-9080:


Hmmm; modifying DateMathParserTest to change most years to 1234 isn't showing 
an issue... need to investigate more.

DateRangeField has some issues too that I have tests for, to be reported 
separately.

> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.0
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



--
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-9068) Solaris SSL test failures when using NullSecureRandom?


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

Hoss Man commented on SOLR-9068:


bq. Why not use this patch also for non-Solaris?

Well, as miller put it in the parent issue once: mainly because the goal here 
is to keep the SSL code as fast as possible since we don't actaully care about 
the "correcectness" of the SSL, we just care that Solr is using SSL and doesn't 
have any hardcoded http assumptions that break when SSL is enabled.  So if we 
can avoid wasting CPU cycles on (psuedo)randomness by having a bunch of No-Op 
methods, then we might as well.

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



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

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

[GitHub] lucene-solr pull request: Move hdfs stuff out into a new contrib

2016-05-06 Thread markrmiller

Github user markrmiller commented on the pull request:

https://github.com/apache/lucene-solr/pull/34#issuecomment-217559403
  
We only have the needs of an hdfs client for shipping. I filed an issue to 
shrink that. Making a whole new contrib, extending the test running time, 
making the integration require more configuration and less just working, 
needing to be configurable instead of being able to take advantage of core 
integration...sorry, I'm against the change.


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

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 119 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/119/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Test abandoned because suite timeout was reached.

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


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

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

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




Build Log:
[...truncated 12082 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_46C97831A68049D6-001/init-core-data-001
   [junit4]   2> 376436 INFO  
(SUITE-HttpPartitionTest-seed#[46C97831A68049D6]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 376441 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 376442 INFO  (Thread-1059) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 376442 INFO  (Thread-1059) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 376543 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.ZkTestServer start zk server on port:64676
   [junit4]   2> 376544 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 376544 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 376560 INFO  (zkCallback-300-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@38348fcf 
name:ZooKeeperConnection Watcher:127.0.0.1:64676 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 376560 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 376560 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 376560 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 376565 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 376565 WARN  (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] 
o.a.z.s.NIOServerCnxn caught end of stream exception
   [junit4]   2> EndOfStreamException: Unable to read additional data from 
client sessionid 0x15487774708, likely client has closed socket
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
   [junit4]   2>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> 376566 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 376568 INFO  (zkCallback-301-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@25d80fae 
name:ZooKeeperConnection Watcher:127.0.0.1:64676/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 376568 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 376569 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 376569 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1
   [junit4]   2> 376574 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/collection1/shards
   [junit4]   2> 376577 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection
   [junit4]   2> 376580 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.c.SolrZkClient makePath: /collections/control_collection/shards
   [junit4]   2> 376584 INFO  
(TEST-HttpPartitionTest.test-seed#[46C97831A68049D6]) [] 
o.a.s.c.AbstractZkTestCase put 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml

[jira] [Assigned] (SOLR-9080) DateMath is broken before the year 1582


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

David Smiley reassigned SOLR-9080:
--

Assignee: David Smiley

> DateMath is broken before the year 1582
> ---
>
> Key: SOLR-9080
> URL: https://issues.apache.org/jira/browse/SOLR-9080
> Project: Solr
>  Issue Type: Bug
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.0
>
>
> In Solr 6.0, dates are parsed using the Java 8 java.time API.  It formerly 
> was parsed using java.util.SimpleDateFormat which uses 
> java.util.GregorianCalendar.  I've learned that the java.time API does _not_ 
> switch to a different algorithm at the Gregorian Change Date (year 1582) 
> whereas GregorianCalendar does.  A ramification of this is that the 
> milliseconds before epoch value is different between the APIs for dates prior 
> to this year.  They both round-trip between themselves but not between each 
> other prior to this date.  Thus, anyone indexing historical dates must 
> re-index when moving to Solr 6.
> What was _not_ changed in the parsing code was Solr's date-math logic -- it 
> still uses the Calendar API.  This works for dates after 1582 but before, 
> it'll introduce discrepancies.  Here's an example showing weird behavior:
> http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
> Note that the year 1300 rounded down to the year, becomes 1299 January 8th 
> (weird in and of itself) and that subsequent gaps start on the 9th.
> {noformat}
> "counts":[
>   "1299-01-08T00:00:00Z",0,
>   "1309-01-09T00:00:00Z",0,
>   "1319-01-09T00:00:00Z",0,  ...
> {noformat}
> This weirdness will show itself for units at the year or month level, but not 
> below that (from what I'm seeing).  In other words, if facet.range.gap is at 
> this amount, or otherwise using the date math syntax to round or add a year 
> or month, there will be issues like this.  Otherwise there doesn't seem to be 
> an issue.
> I think the solution is clearly to switch the date math code to use the 
> java.time API.



--
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-6273) Cross Data Center Replication


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

Joel Bernstein commented on SOLR-6273:
--

Alfresco's Solr implementation doesn't use SolrCloud, so CDCR is not going to 
work with Alfresco Solr.

Alfresco's Solr implementation is eventually consistent though and should work 
across data centers, no CDCR needed. 

> Cross Data Center Replication
> -
>
> Key: SOLR-6273
> URL: https://issues.apache.org/jira/browse/SOLR-6273
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Erick Erickson
> Fix For: master
>
> Attachments: SOLR-6273-5x-rollup.patch, SOLR-6273-plus-8263-5x.patch, 
> SOLR-6273-plus-8263-5x.patch, SOLR-6273-trunk-testfix1.patch, 
> SOLR-6273-trunk-testfix2.patch, SOLR-6273-trunk-testfix3.patch, 
> SOLR-6273-trunk-testfix6.patch, SOLR-6273-trunk-testfix7.patch, 
> SOLR-6273-trunk.patch, SOLR-6273-trunk.patch, SOLR-6273.patch, 
> SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch, forShalin.patch
>
>
> This is the master issue for Cross Data Center Replication (CDCR)
> described at a high level here: 
> http://yonik.com/solr-cross-data-center-replication/



--
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-9079) Upgrade commons-lang to version 3.x


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

Mike Drob commented on SOLR-9079:
-

The arguments about developer effort to upgrade versions and ensure 
compatibility make sense to me. That seems more important than a couple of 
megabytes here or there.

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
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-6968) LSH Filter

2016-05-06 Thread Andy Hind (JIRA)


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

Andy Hind edited comment on LUCENE-6968 at 5/6/16 8:43 PM:
---

After a bit more digging, the single hash and keeping the minimum set can be 
improved.

See: 
[1] http://jmlr.org/proceedings/papers/v32/shrivastava14.pdf
[2] http://www.auai.org/uai2014/proceedings/individuals/225.pdf

In summary: rather than keep the minimum set, split the hash space up into 500 
buckets (for a 500 hash fingerprint) and keep the minimum for each bucket. To 
fill an empty bucket, take the minimum from the next non-empty bucket on the 
right with rotation. 


was (Author: andyhind):
After a bit more digging, the single hash and keeping the minimum set can be 
improved.

See: 
[1] http://jmlr.org/proceedings/papers/v32/shrivastava14.pdf
[2] http://www.auai.org/uai2014/proceedings/individuals/225.pdf

In summary: rather than keep the minimum set, split the hash space up into 500 
buckets (for a 500 hash fingerprint) and keep the minimum for each bucket. To 
fill an empty bucket, take the minimum from the next non-empty bucket on the 
right adding an offset for each step taken. 

> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Tommaso Teofili
> Attachments: LUCENE-6968.4.patch, LUCENE-6968.5.patch, 
> LUCENE-6968.patch, LUCENE-6968.patch, LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given 
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine 
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard measurement with this 
> doc
> {quote}
> Solr is an open source search engine
> {quote}
> It will return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-6968) LSH Filter

2016-05-06 Thread Andy Hind (JIRA)


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

Andy Hind commented on LUCENE-6968:
---

I have attached an updated patch.

This addresses the following issues
# Support for single hash, split into ranges with a minimum for each range
# Remove end to end tests and beefed up unit tests
# Remove Guava in favour of Yonik's murmur hash implementation. (Some 
duplication here with SOLR)
# Fixed alignment and "evil" test case issue   
# TestFactories passes > 200 times (some Japanese Number tokenisation failures)
# Fixed formatting

There were issue applying patch 4 on its own or over the previous patch. I 
believe I have included everything other then the IDE related bits.

> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Tommaso Teofili
> Attachments: LUCENE-6968.4.patch, LUCENE-6968.5.patch, 
> LUCENE-6968.patch, LUCENE-6968.patch, LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given 
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine 
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard measurement with this 
> doc
> {quote}
> Solr is an open source search engine
> {quote}
> It will return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-9079) Upgrade commons-lang to version 3.x

2016-05-06 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-9079:
--

+a lot, I hadn't thought sideways at the problem.

The argument that "some other dependency includes it so we might as well use 
it" is not something I can subscribe to., it just means those other projects 
should see if they can get rid of those dependencies too ;)

Smart-aleckness aside, I think there are very sound reasons to remove 
dependencies if we can. The point of third-party dependencies it to reduce the 
work developers need to do. Including a dependency requires ongoing work to 
maintain it (witness this discussion and Shawn's efforts to see about 
upgrading). So moving from some dependency to core Java seems like a total win 
to me.

Of course "It Depends"(tm) on how much effort it would take to remove the 
dependencies.

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
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-6968) LSH Filter

2016-05-06 Thread Andy Hind (JIRA)


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

Andy Hind updated LUCENE-6968:
--
Attachment: LUCENE-6968.5.patch

> LSH Filter
> --
>
> Key: LUCENE-6968
> URL: https://issues.apache.org/jira/browse/LUCENE-6968
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
>Assignee: Tommaso Teofili
> Attachments: LUCENE-6968.4.patch, LUCENE-6968.5.patch, 
> LUCENE-6968.patch, LUCENE-6968.patch, LUCENE-6968.patch
>
>
> I'm planning to implement LSH. Which support query like this
> {quote}
> Find similar documents that have 0.8 or higher similar score with a given 
> document. Similarity measurement can be cosine, jaccard, euclid..
> {quote}
> For example. Given following corpus
> {quote}
> 1. Solr is an open source search engine based on Lucene
> 2. Solr is an open source enterprise search engine based on Lucene
> 3. Solr is an popular open source enterprise search engine based on Lucene
> 4. Apache Lucene is a high-performance, full-featured text search engine 
> library written entirely in Java
> {quote}
> We wanna find documents that have 0.6 score in jaccard measurement with this 
> doc
> {quote}
> Solr is an open source search engine
> {quote}
> It will return only docs 1,2 and 3 (MoreLikeThis will also return doc 4)



--
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-6273) Cross Data Center Replication

2016-05-06 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-6273:
--

First, it's better to raise this kind of question on the user's list, a closed 
JIRA will only get eyeballs on it by chance.

Gah, there was a kerfuffle with the labels for JIRAs and this one is labeled 
"master", which isn't very helpful. To answer though, this only current on 
6.0+. There is a 5x patch that I put up "just in case" that's never been 
applied to the 5x code line. 4x is not going to happen.

> Cross Data Center Replication
> -
>
> Key: SOLR-6273
> URL: https://issues.apache.org/jira/browse/SOLR-6273
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Erick Erickson
> Fix For: master
>
> Attachments: SOLR-6273-5x-rollup.patch, SOLR-6273-plus-8263-5x.patch, 
> SOLR-6273-plus-8263-5x.patch, SOLR-6273-trunk-testfix1.patch, 
> SOLR-6273-trunk-testfix2.patch, SOLR-6273-trunk-testfix3.patch, 
> SOLR-6273-trunk-testfix6.patch, SOLR-6273-trunk-testfix7.patch, 
> SOLR-6273-trunk.patch, SOLR-6273-trunk.patch, SOLR-6273.patch, 
> SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch, forShalin.patch
>
>
> This is the master issue for Cross Data Center Replication (CDCR)
> described at a high level here: 
> http://yonik.com/solr-cross-data-center-replication/



--
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-9068) Solaris SSL test failures when using NullSecureRandom?

2016-05-06 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on SOLR-9068:
-

OK after 20 rounds I would say: {{new Random(42)}} WORKS :-)

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
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] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

2016-05-06 Thread Uwe Schindler (JIRA)


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

Uwe Schindler edited comment on SOLR-9068 at 5/6/16 8:11 PM:
-

Hi,
sorry for the delay: The patch with the answer to the Ultimate Question of 
Life, the Universe, and Everything looks good. It is currently running using 
{{ant beast -Dbeast.iters=100 -Dtestcase=TestMiniSolrCloudClusterSSL}} (this 
single test) and no failure up to now (already 8 rounds through).

So I think this works. Maybe the padding code in the JDK has a bug that it 
should look random, but not "all bytes are equal". Why not use this patch also 
for non-Solaris?


was (Author: thetaphi):
Hi,
sorry for the delay: The patch with the answer to the Ultimate Question of 
Life, the Universe, and Everything looks good. It is currently running using 
{{ant beast -Dbeast.iters=100 -Dtestcase=TestMiniSolrCloudClusterSSL}} (this 
single test) and no failure up to now (already 8 rounds through).

So I think this works. Maybe the padding has a bug that it should look random, 
but not "all bytes are equal". Why not use this patch also for non-Solaris?

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
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-9068) Solaris SSL test failures when using NullSecureRandom?

2016-05-06 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on SOLR-9068:
-

Hi,
sorry for the delay: The patch with the answer to the Ultimate Question of 
Life, the Universe, and Everything looks good. It is currently running using 
{{ant beast -Dbeast.iters=100 -Dtestcase=TestMiniSolrCloudClusterSSL}} (this 
single test) and no failure up to now (already 8 rounds through).

So I think this works. Maybe the padding has a bug that it should look random, 
but not "all bytes are equal". Why not use this patch also for non-Solaris?

> Solaris SSL test failures when using NullSecureRandom?
> --
>
> Key: SOLR-9068
> URL: https://issues.apache.org/jira/browse/SOLR-9068
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Hoss Man
> Fix For: 4.9, master
>
> Attachments: SOLR-9068.Lucene-Solr-6.x-Solaris_110.log, 
> SOLR-9068.Lucene-Solr-master-Solaris_558.log, SOLR-9068.patch, SOLR-9068.patch
>
>
> In parent issue SOLR-5776, NullSecureRandom was introduced and SSLTestConfig 
> was refactored so that both client & server would use it to prevent blocked 
> threads waiting for entropy.
> Since those commits to master & branch_6x, both Solaris jenkins builds have 
> seen failures at the same spots in 
> TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth - and looking at the logs 
> the root cause appears to be intranode communication failures due to 
> "javax.crypto.BadPaddingException"
> Perhaps the Solaris SSL impl has bugs in it's padding code that are tickeled 
> when the SecureRandom instance returns long strings of null bytes?



--
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-9080) DateMath is broken before the year 1582

David Smiley created SOLR-9080:
--

Summary: DateMath is broken before the year 1582
Key: SOLR-9080
URL: https://issues.apache.org/jira/browse/SOLR-9080
Project: Solr
Issue Type: Bug
Reporter: David Smiley
Fix For: 6.0

In Solr 6.0, dates are parsed using the Java 8 java.time API. It formerly was
parsed using java.util.SimpleDateFormat which uses java.util.GregorianCalendar.
I've learned that the java.time API does _not_ switch to a different algorithm
at the Gregorian Change Date (year 1582) whereas GregorianCalendar does. A
ramification of this is that the milliseconds before epoch value is different
between the APIs for dates prior to this year. They both round-trip between
themselves but not between each other prior to this date. Thus, anyone
indexing historical dates must re-index when moving to Solr 6.

What was _not_ changed in the parsing code was Solr's date-math logic -- it
still uses the Calendar API. This works for dates after 1582 but before, it'll
introduce discrepancies. Here's an example showing weird behavior:
http://localhost:8983/solr/techproducts/select?facet.range.end=1400-01-01T00:00:00Z=%2B10YEARS=1300-01-01T00:00:00Z/YEAR=manufacturedate_dt=on=on=*:*=0=json
Note that the year 1300 rounded down to the year, becomes 1299 January 8th
(weird in and of itself) and that subsequent gaps start on the 9th.

{noformat}
"counts":[
"1299-01-08T00:00:00Z",0,
"1309-01-09T00:00:00Z",0,
"1319-01-09T00:00:00Z",0, ...
{noformat}

This weirdness will show itself for units at the year or month level, but not
below that (from what I'm seeing). In other words, if facet.range.gap is at
this amount, or otherwise using the date math syntax to round or add a year or
month, there will be issues like this. Otherwise there doesn't seem to be an
issue.

I think the solution is clearly to switch the date math code to use the
java.time API.

--
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-6273) Cross Data Center Replication

2016-05-06 Thread Michael Griffith (JIRA)


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

Michael Griffith commented on SOLR-6273:


Is this CDCR compatible with 4.10.3 -- is it already baked into the code base 
prior to 4.10.3?  Alfresco 5.1 is now out and it uses 4.10.3 as its solr base, 
but the alfresco project heavily modifies the code.  I'm try to figure out if 
this is something that can be used in our alfresco data centers without having 
to patch or change any code.

thanks in advance,



> Cross Data Center Replication
> -
>
> Key: SOLR-6273
> URL: https://issues.apache.org/jira/browse/SOLR-6273
> Project: Solr
>  Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Erick Erickson
> Fix For: master
>
> Attachments: SOLR-6273-5x-rollup.patch, SOLR-6273-plus-8263-5x.patch, 
> SOLR-6273-plus-8263-5x.patch, SOLR-6273-trunk-testfix1.patch, 
> SOLR-6273-trunk-testfix2.patch, SOLR-6273-trunk-testfix3.patch, 
> SOLR-6273-trunk-testfix6.patch, SOLR-6273-trunk-testfix7.patch, 
> SOLR-6273-trunk.patch, SOLR-6273-trunk.patch, SOLR-6273.patch, 
> SOLR-6273.patch, SOLR-6273.patch, SOLR-6273.patch, forShalin.patch
>
>
> This is the master issue for Cross Data Center Replication (CDCR)
> described at a high level here: 
> http://yonik.com/solr-cross-data-center-replication/



--
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-9079) Upgrade commons-lang to version 3.x

2016-05-06 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-9079:
-

Depends if they're compile-time or runtime dependencies, I guess.  I think it's 
worth exploring, anyway.

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
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-9079) Upgrade commons-lang to version 3.x


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

Mike Drob commented on SOLR-9079:
-

Is there a benefit to removing commons-lang or guava when we still transitively 
depend on them?

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



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

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

[GitHub] lucene-solr pull request: Move hdfs stuff out into a new contrib

2016-05-06 Thread romseygeek

Github user romseygeek commented on the pull request:

https://github.com/apache/lucene-solr/pull/34#issuecomment-217531618
  
@markrmiller I don't think we need to make people jump through any more 
hoops, and HDFS integration would stay as part of the core distribution, but 
moving it into a contrib allows us to offer a slimmed-down distro for people 
who aren't using hadoop.  Plus it helps keep us honest when it comes to 
encapsulation and plugs a few leaky abstractions in the core.


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

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

[jira] [Commented] (SOLR-9079) Upgrade commons-lang to version 3.x

2016-05-06 Thread Alan Woodward (JIRA)


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

Alan Woodward commented on SOLR-9079:
-

I'd actually go the other way, and try and remove commons-lang entirely.  Guava 
too, and commons-configuration if we can.  We're on Java 8 now, lots of the 
things that these libraries were introduced to fix are part of the core 
language.  And the few methods that we do need, we can fork and include in a 
Utils package.  Importing jars for the sake of a couple of classes just bloats 
the distribution and leads to dependency hell.

> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
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.5-Linux (32bit/jdk1.8.0_92) - Build # 270 - Failure!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/270/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseSerialGC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.BasicAuthIntegrationTest

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

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


FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

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




Build Log:
[...truncated 12536 lines...]
   [junit4] Suite: org.apache.solr.security.BasicAuthIntegrationTest
   [junit4]   2> 2041632 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2041632 INFO  (Thread-5431) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2041632 INFO  (Thread-5431) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2041732 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.ZkTestServer start zk server on port:45668
   [junit4]   2> 2041732 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2041733 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2041780 INFO  (zkCallback-1965-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@fa73aa name:ZooKeeperConnection 
Watcher:127.0.0.1:45668 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 2041780 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2041780 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2041780 INFO  
(TEST-BasicAuthIntegrationTest.testBasics-seed#[543F82A832C35A6]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 2041850 INFO  (jetty-launcher-1964-thread-3) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2041850 INFO  (jetty-launcher-1964-thread-2) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2041850 INFO  (jetty-launcher-1964-thread-1) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2041850 INFO  (jetty-launcher-1964-thread-4) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2041850 INFO  (jetty-launcher-1964-thread-5) [] 
o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-3) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@b9c0f3{/solr,null,AVAILABLE}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1a3fd81{/solr,null,AVAILABLE}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-4) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1945b79{/solr,null,AVAILABLE}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-5) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@10c3afb{/solr,null,AVAILABLE}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@6a62e7{/solr,null,AVAILABLE}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-3) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@1c01785{HTTP/1.1}{127.0.0.1:37209}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-2) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@18418d8{HTTP/1.1}{127.0.0.1:44161}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-3) [] 
o.e.j.s.Server Started @2043119ms
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-2) [] 
o.e.j.s.Server Started @2043120ms
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-4) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@ab05d0{HTTP/1.1}{127.0.0.1:43522}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-5) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@1f1b73{HTTP/1.1}{127.0.0.1:34784}
   [junit4]   2> 2041852 INFO  (jetty-launcher-1964-thread-4) [] 
o.e.j.s.Server Started @2043120ms
   [junit4]   2> 2041853 INFO  (jetty-launcher-1964-thread-5) [] 
o.e.j.s.Server Started @2043120ms
   [junit4]   2> 2041853 INFO  (jetty-launcher-1964-thread-4) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=43522}
   [junit4]   2>

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3251 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3251/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Expected 2 of 3 replicas to be active but only found 1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:55936","node_name":"127.0.0.1:55936_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:55946;,   
"core":"c8n_1x3_lf_shard1_replica3",   "node_name":"127.0.0.1:55946_"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica2",   
"base_url":"http://127.0.0.1:55941;,   "node_name":"127.0.0.1:55941_",  
 "state":"down"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:55936;,   "node_name":"127.0.0.1:55936_",  
 "state":"active",   "leader":"true",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:55936","node_name":"127.0.0.1:55936_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:55946;,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:55946_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:55941;,
  "node_name":"127.0.0.1:55941_",
  "state":"down"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:55936;,
  "node_name":"127.0.0.1:55936_",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([2CB58FBFD0588C15:A4E1B0657EA4E1ED]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at

[jira] [Comment Edited] (LUCENE-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version


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

Steve Rowe edited comment on LUCENE-7275 at 5/6/16 6:15 PM:


Only 5 issues with afftectedVersion of 5.x or 6.x: 
[https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+affectedVersion+in+(6.x,5.x)]


was (Author: steve_rowe):
Only 5 issues with afftectedVersion of 5.x or 6.x: 
[https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(affectedVersion=6.x+OR+affectedVersion=5.x)]

> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer 
> to the correct version
> 
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and 
> {{5.x}} - there are 38 issues with these as fixVersion-s: 
> [https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)].
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than 
> those retrieved with the above query, since these versions could also have 
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
> the appropriate version.



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

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

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

2016-05-06 Thread Apache Jenkins Server

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

11 tests failed.
FAILED:  org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test

Error Message:
Timeout waiting for all live and active

Stack Trace:
java.lang.AssertionError: Timeout waiting for all live and active
at 
__randomizedtesting.SeedInfo.seed([7FF2899D3F00B9D7:F7A6B64791FCD42F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.testBasics(SharedFSAutoReplicaFailoverTest.java:202)
at 
org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest.test(SharedFSAutoReplicaFailoverTest.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Commented] (LUCENE-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version


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

Steve Rowe commented on LUCENE-7275:


Only 5 issues with afftectedVersion of 5.x or 6.x: 
[https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(affectedVersion=6.x+OR+affectedVersion=5.x)]

> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer 
> to the correct version
> 
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and 
> {{5.x}} - there are 38 issues with these as fixVersion-s: 
> [https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)].
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than 
> those retrieved with the above query, since these versions could also have 
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
> the appropriate version.



--
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-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version


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

Steve Rowe updated LUCENE-7275:
---
Description: 
The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and {{5.x}} 
- there are 38 issues with these as fixVersion-s: 
[https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)].

Should we even have {{6.x}} and {{5.x}} versions at all?

If we get rid of them, all affected issues (which may be a larger number than 
those retrieved with the above query, since these versions could also have been 
used in JIRA's "Affects Version/s" field) will need to be relabeled with the 
appropriate version.

  was:
The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and {{5.x}} 
- there are 38 issues with these as fixVersion-s: 
https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x).

Should we even have {{6.x}} and {{5.x}} versions at all?

If we get rid of them, all affected issues (which may be a larger number than 
those retrieved with the above query, since these versions could also have been 
used in JIRA's "Affects Version/s" field) will need to be relabeled with the 
appropriate version.


> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer 
> to the correct version
> 
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and 
> {{5.x}} - there are 38 issues with these as fixVersion-s: 
> [https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)].
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than 
> those retrieved with the above query, since these versions could also have 
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
> the appropriate version.



--
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-7271) Cleanup jira's concept of 'master' and '6.0'


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

Hoss Man commented on LUCENE-7271:
--

bq. Assuming that is the problem for those issues, we would need to reopen all 
those in order to fix the version then close them 

Bulk Edit is already stressfull enough, I'd really really rather not Bulk Edit 
once to re-open the subset of issues that are currently closed issues (and add 
one comment to keep track of them) then Bulk Edit (2 more times) to add the 
comments i originally wanted to add, then Bulk Edit a third time to re-close 
issues from the 1st time ... 

...particulaly since we're only assuming that's the problem.  who knows what 
other "workflow" constraints might be in place to prevent me from doing a No-op 
Bulk Edit to add a comment to all the issues (they've clearly added a lot more 
"smarts" to bulk editing lately, so i'm not even sure a No-Op edit that just 
adds a comment will even work at this point)

At this point I personally just really want to avoid the Bulk Edits -- but i'm 
happy to hand this issue off to someone else if they feel more confident then 
me about being able to follow the original plan :)



> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: LUCENE-7271_S1_report.csv, LUCENE-7271_S1_report.xls
>
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Generate two CSV reports containing all issues that match these 2 
> queries for fixVersion=master and fixVersion=6.0
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> ** these reports can be attached to this issue (LUCENE-7271) for posterity in 
> case people want to later review what the state of any issue was before this 
> whole process was started and versions were changed/merged
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40

[jira] [Commented] (LUCENE-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version


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

Hoss Man commented on LUCENE-7275:
--

bq. Should we even have 6.x and 5.x versions at all?

Philosophically: Either we should *only* have 6.x and no "6.1" (and then "6.x" 
gets renamed to "6.1" on release) or we should *only* have 6.1 (since we know 
that is what the next version released from the 6x branch will be called).

(Either way we definitely shouldn't have a "5.x" version at this point)

6.1 seems like the better choice given that: it's really the only sane option 
for what will be released off of branch_6x, it fits peoples mental models 
better, and for "things that are going to be released relatively soon" it 
probably makes more sense to end users looking at issues (as opposed to just 
labeling it "6.x" and a user of 6.0 might wonder "is that in my release then? 
my release is a 6.x release)

I think "master" is a special case in that, until we actually fork of a 
development branch ("branch_7x") there's a lot more uncertainty to that branch 
-- as we saw with the creation of branch_5x.  

(But i do think a name like {{master (7.0)}} -- as in "committed to master, 
which will probably be 7.0" is a better choice and a better reminder to all 
devs in the future to rename it once a branch_7x _does_ get created, so we 
don't have another cluster fuck like LUCENE-7271, which is why it's the name 
i'm planning to use when i add back "master" in that issue ... but i digress)

bq. If we get rid of them, all affected issues (which may be a larger number 
than those retrieved with the above query, since these versions could also have 
been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
the appropriate version.

I think getting rid of them (5.x and 6.x) is probably the right call - any 
information value to be had from issues that list them as "affects versions" is 
probably non existent, and there's not going to be any clear cut and obvious 
"easy win" in merging those versions into any other concrete versions  -- we 
just need to run a report on that query first, and then have the handful of 
devs assigned to those ~40 issues to take a few minutes to review the list  and 
make sure the accurate fixVersion(s) is recorded.

> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer 
> to the correct version
> 
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and 
> {{5.x}} - there are 38 issues with these as fixVersion-s: 
> https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x).
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than 
> those retrieved with the above query, since these versions could also have 
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
> the appropriate version.



--
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-9076) Update to Hadoop 2.7.2


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

Mike Drob commented on SOLR-9076:
-

{quote}
+/org.apache.htrace/htrace-core = 3.2.0-incubating
+/org.apache.htrace/htrace-core4 = 4.0.1-incubating
{quote}
We don't need both of these, do we? Just the 4.0.1 version, I'd expect.

> Update to Hadoop 2.7.2
> --
>
> Key: SOLR-9076
> URL: https://issues.apache.org/jira/browse/SOLR-9076
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9076.patch, SOLR-9076.patch, SOLR-9076.patch
>
>




--
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-7271) Cleanup jira's concept of 'master' and '6.0'

2016-05-06 Thread Cassandra Targett (JIRA)


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

Cassandra Targett commented on LUCENE-7271:
---

bq. the "Edit Issues" option was disabled with the text: "NOTE: You do not have 
permission to edit the selected 186 issues or at least one issue has a status 
that forbids editing."

Oh right, if the issue is closed already, you can't edit the fix version at all 
(and it gives that rather unhelpful message about permissions). Assuming that 
is the problem for those issues, we would need to reopen all those in order to 
fix the version then close them again.

> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: LUCENE-7271_S1_report.csv, LUCENE-7271_S1_report.xls
>
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Generate two CSV reports containing all issues that match these 2 
> queries for fixVersion=master and fixVersion=6.0
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> ** these reports can be attached to this issue (LUCENE-7271) for posterity in 
> case people want to later review what the state of any issue was before this 
> whole process was started and versions were changed/merged
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



--
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-8661) Upgrade guava version to 18.0 due to Presto dependency


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

Mike Drob commented on SOLR-8661:
-

I think the leak is still there, but they did some work to make compatibility a 
bit better.

HADOOP-11600 - Hadoop 2.7 works with Guava 17
HADOOP-10101 - Hadoop 3.0 will work with Guava 18

> Upgrade guava version to 18.0 due to Presto dependency
> --
>
> Key: SOLR-8661
> URL: https://issues.apache.org/jira/browse/SOLR-8661
> Project: Solr
>  Issue Type: Task
>  Components: Parallell SQL
>Reporter: Jan Høydahl
>Priority: Minor
>  Labels: sql, streaming_api
>
> The Presto parser depends on {{com.google.guava/guava 18.0}}, and Solr 
> currently uses 14.0.1. I have seen a Class not found exception for some 
> {{com.google.common.base}} classes when playing with Parallell SQL.



--
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-7271) Cleanup jira's concept of 'master' and '6.0'


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

Hoss Man updated LUCENE-7271:
-
Description: 
Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
discussed in this mailing list thread...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E

The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0)}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.

I'm using this issue to track this work.



Detailed Check list of planned steps:

* S1: Generate a CSV report listing all resolved/closed Jira's with 
'fixVersion=master AND fixVersion=6.1'
** 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the 
fixVersion set correctly if/when they are resolved in the future
* S2: Generate two CSV reports containing all issues that match these 2 queries 
for fixVersion=master and fixVersion=6.0
*** master: 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
*** 6.0: 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
** these reports can be attached to this issue (LUCENE-7271) for posterity in 
case people want to later review what the state of any issue was before this 
whole process was started and versions were changed/merged
* S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
** This needs to be done distinctly for both LUCENE and SOLR
* S4: Add a new "master (7.0)" version to Jira
** This needs to be done distinctly for both LUCENE and SOLR
* S5: audit every issue in the CSV file from S1 above to determine if/when the 
issue should get fixVersion="master (7.0)" *added* to it or fixVersion="6.0" 
*removed* from it:
** if it only ever had commits to master (ie: before branch_6x was made on 
March 2nd) then no action needed.
** if it has distinct commits to both master after branch_6x was made on March 
2nd, then fixVersion="master (7.0)" should definitely be added.
** if it has no commits to branch_6_0, and the only commits to branch_6x are 
after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
removed.
** if there are no obvious commits in the issue comments, then sanity check why 
it has any fixVersion at all (can't reproduce? dup? etc...)
* S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
fixVersion="master (7.0)" on the handful of issues where appropriate in case 
they fell through the cracks in S5:
** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
features
*** currently only 1 jira mentioned in either files in 7.0 section
** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
'^\+'}} to find changesets on master that were not included in 6.0
*** currently ~40 commits
** before removing fixVersion=6.0 from any of these issues, sanity check if 
this is a deprecation type situation (involving diff commits in both 6.0 and 
master) in which case fixVersion="master (7.0)" should be _added_ in addition 
to fixVersion=6.0




  was:
Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
discussed in this mailing list thread...

http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E

The current best plan of attack (summary) is:
* use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
* add a new {{master (7.0)}} to use moving forward
* manually audit/fix the fixVersion of some clean up issues as needed.

I'm using this issue to track this work.



Detailed Check list of planned steps:

* S1: Generate a CSV report listing all resolved/closed Jira's with 
'fixVersion=master AND fixVersion=6.1'
** 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
*** currently about ~100 issues
** The operating assumption is that any non-resolved issues should have the 
fixVersion set correctly if/when they are resolved in the future
* S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
every issue currently assocaited with fixVersion=6.0 or fixVersio=master
** The comments will include unique strings based on the the specific query 
done,

[jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'


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

Hoss Man commented on LUCENE-7271:
--

Didn't even make it to Step #2 before i discovered a problem...

Jira's "Bulk Edit" feature has been seriously hobbled since the last time i 
used it...

# You can only bulk edit up to  1000 issues at a time now.
#* This makes it impossible to do a bulk edit on all 4K+ issues with 
fixVersion=master
#* I could work around this by crafting 5 distinct queries, but...
# The options you can do when Bulk Editing are really limited...
#* I tried doing a bulk edit on the 186 issues with fixVersion=6.0
#* the "Edit Issues" option was disabled with the text: {{NOTE: You do not have 
permission to edit the selected 186 issues or at least one issue has a status 
that forbids editing.}}
#* The remaining options are "Move Issues" (really bad idea), "Delete Issues" 
(even worse idea), "Transition Issues" (through workflow), "Watch Issues" and 
"Stop Watching Issues"
#* the start/stop watching issues options don't let you add a comment
#* the "Transition Issues" option seemed like a last hope, but it's too smart 
-- it makes you pick a specific transition like "Resolved -> Closed" (no No-Op 
options listed) and knows that that each specific option will only affect a 
subset of the issues (the ones in the iniial state of the option you pick)



I think Step S2 needs to be scrapped.  I would really like to have distinct 
comments identifying all of the issues, both because it would make it easy to 
search for all affected issues (and filter that search by other factors) but 
also so it shows up if/when people read the comments in these issues in case 
something gets missing in Steps S5 and S6 -- but I just don't think that's 
possible.

My next best suggestion is to just run excel/csv reports for the queries in S2 
(just like S1) and attache them to this issue for posterity.

I'll revise the description of the issue to reflect the new plan, and put 
everythine on hold until monday in case anyone has better suggestions.



> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: LUCENE-7271_S1_report.csv, LUCENE-7271_S1_report.xls
>
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0"

[jira] [Commented] (SOLR-8747) ExclusiveMarking enum and checkExclusiveMarking method is very confusing

2016-05-06 Thread Noble Paul (JIRA)


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

Noble Paul commented on SOLR-8747:
--

We need a refactoring of this feature to ensure that locking is done at the 
right level. We should just link these two

> ExclusiveMarking enum and checkExclusiveMarking method is very confusing
> 
>
> Key: SOLR-8747
> URL: https://issues.apache.org/jira/browse/SOLR-8747
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 6.0, master
>
>
> ExclusiveMarking enum and checkExclusiveMarking method is very confusing.  It 
> appears to do the opposite of its name e.g.
> {code}
> @Override
>   public ExclusiveMarking checkExclusiveMarking(String collectionName, 
> ZkNodeProps message) {
> // CLUSTERSTATUS is always mutually exclusive
> //TODO deprecated remove this check .
> if(CLUSTERSTATUS.isEqual(message.getStr(Overseer.QUEUE_OPERATION)))
>   return ExclusiveMarking.EXCLUSIVE;
> synchronized (collectionWip) {
>   if(collectionWip.contains(collectionName))
> return ExclusiveMarking.NONEXCLUSIVE;
> }
> return ExclusiveMarking.NOTDETERMINED;
>   }
> {code}
> I guess it returns exclusive if the current task is the only one to run. We 
> should document it or rename it to make its function more comprehensible.



--
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-7271) Cleanup jira's concept of 'master' and '6.0'


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

Steve Rowe commented on LUCENE-7271:


bq. I'd really prefer not discuss 5.x/6x anymore in this jira and 
confuse/complicate the issue anymore.

I created LUCENE-7275 for this.

> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: LUCENE-7271_S1_report.csv, LUCENE-7271_S1_report.xls
>
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



--
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-8747) ExclusiveMarking enum and checkExclusiveMarking method is very confusing

2016-05-06 Thread Scott Blum (JIRA)


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

Scott Blum commented on SOLR-8747:
--

CC: [~noble.paul] related to SOLR-8744

> ExclusiveMarking enum and checkExclusiveMarking method is very confusing
> 
>
> Key: SOLR-8747
> URL: https://issues.apache.org/jira/browse/SOLR-8747
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 6.0, master
>
>
> ExclusiveMarking enum and checkExclusiveMarking method is very confusing.  It 
> appears to do the opposite of its name e.g.
> {code}
> @Override
>   public ExclusiveMarking checkExclusiveMarking(String collectionName, 
> ZkNodeProps message) {
> // CLUSTERSTATUS is always mutually exclusive
> //TODO deprecated remove this check .
> if(CLUSTERSTATUS.isEqual(message.getStr(Overseer.QUEUE_OPERATION)))
>   return ExclusiveMarking.EXCLUSIVE;
> synchronized (collectionWip) {
>   if(collectionWip.contains(collectionName))
> return ExclusiveMarking.NONEXCLUSIVE;
> }
> return ExclusiveMarking.NOTDETERMINED;
>   }
> {code}
> I guess it returns exclusive if the current task is the only one to run. We 
> should document it or rename it to make its function more comprehensible.



--
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-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version


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

Steve Rowe commented on LUCENE-7275:


LUCENE-7271 covers similar ground for master->6.0

> Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer 
> to the correct version
> 
>
> Key: LUCENE-7275
> URL: https://issues.apache.org/jira/browse/LUCENE-7275
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Steve Rowe
>
> The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and 
> {{5.x}} - there are 38 issues with these as fixVersion-s: 
> https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x).
> Should we even have {{6.x}} and {{5.x}} versions at all?
> If we get rid of them, all affected issues (which may be a larger number than 
> those retrieved with the above query, since these versions could also have 
> been used in JIRA's "Affects Version/s" field) will need to be relabeled with 
> the appropriate version.



--
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-7275) Consider removing LUCENE JIRA versions 5.x and 6.x and fixing issues to refer to the correct version

Steve Rowe created LUCENE-7275:
--

 Summary: Consider removing LUCENE JIRA versions 5.x and 6.x and 
fixing issues to refer to the correct version
 Key: LUCENE-7275
 URL: https://issues.apache.org/jira/browse/LUCENE-7275
 Project: Lucene - Core
  Issue Type: Task
Reporter: Steve Rowe


The LUCENE JIRA project (but not the SOLR one) has versions {{6.x}} and {{5.x}} 
- there are 38 issues with these as fixVersion-s: 
https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x).

Should we even have {{6.x}} and {{5.x}} versions at all?

If we get rid of them, all affected issues (which may be a larger number than 
those retrieved with the above query, since these versions could also have been 
used in JIRA's "Affects Version/s" field) will need to be relabeled with the 
appropriate version.



--
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-7271) Cleanup jira's concept of 'master' and '6.0'


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

Hoss Man updated LUCENE-7271:
-
Attachment: LUCENE-7271_S1_report.xls
LUCENE-7271_S1_report.csv

Step S1...

Attaching 2 files:

* LUCENE-7271_S1_report.xls - Using "Export to Excel (Current Fields)" option 
from Jira for this URL...
** 
https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
* LUCENE-7271_S1_report.csv - using OpenOffice to convert 
LUCENE-7271_S1_report.xls to plain text on my local machine.


> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: LUCENE-7271_S1_report.csv, LUCENE-7271_S1_report.xls
>
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



--
This message

[jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'


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

Hoss Man commented on LUCENE-7271:
--

bq. I think this is a related problem to the master->6.0 issue being dealt with 
here.

I think it is a similar _class_ of problem, and a similar audit could/should be 
done to fix those issues, but the specific steps needed to assess those issues 
and deal with that confusion will be distinctly diff from what needs done here 
to fix "master" (which affects a few order of magnitude more issues)

I'd really prefer not discuss 5.x/6x anymore in this jira and 
confuse/complicate the issue anymore.


> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



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

-
To

[jira] [Commented] (SOLR-9079) Upgrade commons-lang to version 3.x


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

Shawn Heisey commented on SOLR-9079:


Finished checking the dependencies on all the non-lucene_solr jars in 
WEB-INF/lib, using maven central.  Other dependencies (besides zookeeper) which 
depend on commons-lang 2.x:

commons-configuration (we're using a release that's over 7 years old!)
hadoop-common
hadoop-hdfs


> Upgrade commons-lang to version 3.x
> ---
>
> Key: SOLR-9079
> URL: https://issues.apache.org/jira/browse/SOLR-9079
> Project: Solr
>  Issue Type: Wish
>Reporter: Christine Poerschke
>Priority: Minor
>
> Current version used is [/commons-lang/commons-lang = 
> 2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
>  and a key motivation would be to have 
> [commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
>  APIs available e.g. 
> [org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
>  as an alternative to 
> [org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
>  variant.
> [This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
>  dev list posting reports on exploring use of 3.4 instead of 2.6 and 
> concludes with the discovery of an optional zookeeper dependency on 
> commons-lang-2.4 version.
> So upgrading commons-lang can't happen anytime soon but this ticket here to 
> track motivations and findings so far for future reference.
> selected links into other relevant dev list threads:
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E
> *  
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E
> * 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e



--
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-6.x-Windows (32bit/jdk1.8.0_92) - Build # 159 - Still Failing!

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/159/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

No tests ran.

Build Log:
[...truncated 14 lines...]
FATAL: Could not delete file 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\.caches\test-stats
org.eclipse.jgit.api.errors.JGitInternalException: Could not delete file 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\.caches\test-stats
at org.eclipse.jgit.api.CleanCommand.call(CleanCommand.java:138)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1300)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at ..remote call to Windows VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel.call(Channel.java:781)
at 
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250)
at com.sun.proxy.$Proxy54.clean(Unknown Source)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl.clean(RemoteGitImpl.java:453)
at 
hudson.plugins.git.extensions.impl.CleanBeforeCheckout.decorateFetchCommand(CleanBeforeCheckout.java:32)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:806)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:607)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1738)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: java.io.IOException: Could not delete file 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\.caches\test-stats
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:181)
at org.eclipse.jgit.util.FileUtils.delete(FileUtils.java:150)
at org.eclipse.jgit.api.CleanCommand.call(CleanCommand.java:133)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl.clean(JGitAPIImpl.java:1300)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: Test reports were found 
but none of them are new. Did tests run? 
For example,

[jira] [Commented] (SOLR-9078) Let Parallel SQL support offset or start


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

Joel Bernstein commented on SOLR-9078:
--

[~caomanhdat], up to you then. You can use this ticket or create a new one.

> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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-8825) SolrJ JDBC - SQuirrel SQL documentation


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

Kevin Risden resolved SOLR-8825.

Resolution: Fixed
  Assignee: Kevin Risden

Added page to CWIKI: 
https://cwiki.apache.org/confluence/display/solr/Solr+JDBC+-+SQuirreL+SQL

> SolrJ JDBC - SQuirrel SQL documentation
> ---
>
> Key: SOLR-8825
> URL: https://issues.apache.org/jira/browse/SOLR-8825
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: solr_jdbc_SQuirrelSQL_20160311.pdf, 
> squirrelsql_solrjdbc.zip
>
>
> Like SOLR-8521, it would be great to document how SQuirrel SQL can be used 
> with SolrJ JDBC.



--
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-9078) Let Parallel SQL support offset or start


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

Kevin Risden commented on SOLR-9078:


Doesn't matter to me either way. I didn't file this originally. Just saw it 
come through.

> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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-9078) Let Parallel SQL support offset or start


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

Joel Bernstein commented on SOLR-9078:
--

It might be cleaner to do this in a separate ticket. Any thoughts on this 
[~risdenk]?

> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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] (SOLR-9078) Let Parallel SQL support offset or start

2016-05-06 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat edited comment on SOLR-9078 at 5/6/16 3:24 PM:


That's a good solution. Should we add it in this ticket or open another ticket?


was (Author: caomanhdat):
That's good be great solution. Should we add it in this ticket or open another 
ticket?

> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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-9078) Let Parallel SQL support offset or start

2016-05-06 Thread Cao Manh Dat (JIRA)


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

Cao Manh Dat commented on SOLR-9078:


That's good be great solution. Should we add it in this ticket or open another 
ticket?

> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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-8521) Add documentation for how to use Solr JDBC driver with SQL client like DB Visualizer


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

Kevin Risden resolved SOLR-8521.

Resolution: Fixed
  Assignee: Kevin Risden

Added page to CWIKI: 
https://cwiki.apache.org/confluence/display/solr/Solr+JDBC+-+DbVisualizer

> Add documentation for how to use Solr JDBC driver with SQL client like DB 
> Visualizer
> 
>
> Key: SOLR-8521
> URL: https://issues.apache.org/jira/browse/SOLR-8521
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: dbvisualizer_solrjdbc.zip, 
> solr_jdbc_dbvisualizer_20160203.pdf
>
>
> Currently this requires the following:
> * a JDBC SQL client program (like DBVisualizer or SQuirrelSQL)
> * all jars from solr/dist/solrj-lib/* to be on the SQL client classpath
> * solr/dist/solr-solrj-6.0.0-SNAPSHOT.jar on the SQL client classpath
> * a valid JDBC connection string (like 
> jdbc:solr://SOLR_ZK_CONNECTION_STRING?collection=COLLECTION_NAME)
> * without SOLR-8213, the username/password supplied by the SQL client will be 
> ignored.



--
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-9071) rename the getters in org.apache.solr.common.util.Pair class

2016-05-06 Thread Christine Poerschke (JIRA)


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

Christine Poerschke commented on SOLR-9071:
---

Yes, so sounds like upgrading to 3.x could/would happen only when/after 
ZooKeeper depends on 3.x also, at some point in the future.

> rename the getters in org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Attachments: SOLR-9071.patch
>
>




--
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-9071) rename the getters in org.apache.solr.common.util.Pair class

2016-05-06 Thread Christine Poerschke (BLOOMBERG/ LONDON)


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

Shawn Heisey commented on SOLR-9071:


I did some experimentation where I tried to upgrade to 3.4.

I fixed all resulting issues in *our* codebase -- Solr will compile ... but 
Zookeeper depends on the 2.x version, so SolrCloud doesn't work if you 
*upgrade* commons-lang.

I'm sure that both jars will coexist because of the package name change ... but 
including both would add 2.4MB (the size of the lang3 jar) to the download size 
of Solr.  That's is an insane thing to do if the primary motivation is "get rid 
of a few dozen lines of java code."


> rename the getters in org.apache.solr.common.util.Pair class
> 
>
> Key: SOLR-9071
> URL: https://issues.apache.org/jira/browse/SOLR-9071
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Attachments: SOLR-9071.patch
>
>




--
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-9055) Make collection backup/restore extensible

2016-05-06 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-9055:
---

+1, that makes sense to me.

> Make collection backup/restore extensible
> -
>
> Key: SOLR-9055
> URL: https://issues.apache.org/jira/browse/SOLR-9055
> Project: Solr
>  Issue Type: Task
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
> Attachments: SOLR-9055.patch, SOLR-9055.patch
>
>
> SOLR-5750 implemented backup/restore API for Solr. This JIRA is to track the 
> code cleanup/refactoring. Specifically following improvements should be made,
> - Add Solr/Lucene version to check the compatibility between the backup 
> version and the version of Solr on which it is being restored.
> - Add a backup implementation version to check the compatibility between the 
> "restore" implementation and backup format.
> - Introduce a Strategy interface to define how the Solr index data is backed 
> up (e.g. using file copy approach).
> - Introduce a Repository interface to define the file-system used to store 
> the backup data. (currently works only with local file system but can be 
> extended). This should be enhanced to introduce support for "registering" 
> repositories (e.g. HDFS, S3 etc.)



--
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: solr.common.util.Pair --> commons.lang3.tuple.Pair

Thanks everyone for your input!

I have created https://issues.apache.org/jira/browse/SOLR-9079 as a future 
'wish' item.

Christine

- Original Message -
From: dev@lucene.apache.org
To: dev@lucene.apache.org
At: May  5 2016 19:53:58

On 5/5/2016 11:07 AM, Erick Erickson wrote:
> Or upgrade commons-lang

I did think of that, and thought it probably would not work because
commons-lang 2.x was almost guaranteed to be a sub-dependency to one of
Solr's other dependencies.

Just for giggles, I updated the ivy config to pull in 3.4 instead of
2.6.  I did "ant clean clean-jars clean-eclipse eclipse" and refreshed
the eclipse project ... I managed to figure out the correct ivy changes.

Then I used "organize imports" in Eclipse to fix the majority of the
errors - a bit of a sledgehammer approach, I admit.  There was one
source file where I had to adjust actual code, but the change was very
minor, and the javadoc suggested it wouldn't be an issue.  Then I ran
"ant clean server" and "bin\solr start -f" in the solr directory to see
if there would be any *obvious* problems where one of Solr's *other*
dependencies expected the legacy commons-lang jar.

Surprisingly, there were no immediate indications of problems.  Solr
started and the admin UI worked.  I did not try any other operations.

After a little more investigating, and seeing a ton of cloud tests
failing, I did learn that zookeeper (even 3.5 alpha versions) has an
optional dependency on commons-lang-2.4, so I tried "bin\solr -e cloud
-noprompt".  That's when it became apparent that this wasn't going to
work.  There are errors in the log about commons.lang classes not being
found.

Thanks,
Shawn

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

[jira] [Created] (SOLR-9079) Upgrade commons-lang to version 3.x

2016-05-06 Thread Christine Poerschke (JIRA)

Christine Poerschke created SOLR-9079:
-

 Summary: Upgrade commons-lang to version 3.x
 Key: SOLR-9079
 URL: https://issues.apache.org/jira/browse/SOLR-9079
 Project: Solr
  Issue Type: Wish
Reporter: Christine Poerschke
Priority: Minor


Current version used is [/commons-lang/commons-lang = 
2.6|https://github.com/apache/lucene-solr/blob/master/lucene/ivy-versions.properties#L68]
 and a key motivation would be to have 
[commons.lang3|http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/package-summary.html]
 APIs available e.g. 
[org.apache.commons.lang3.tuple.Pair|http://commons.apache.org/proper/commons-lang/apidocs/index.html?org/apache/commons/lang3/tuple/Pair.html]
 as an alternative to 
[org.apache.solr.common.util.Pair|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Pair.java]
 variant.

[This|http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e]
 dev list posting reports on exploring use of 3.4 instead of 2.6 and concludes 
with the discovery of an optional zookeeper dependency on commons-lang-2.4 
version.

So upgrading commons-lang can't happen anytime soon but this ticket here to 
track motivations and findings so far for future reference.

selected links into other relevant dev list threads:
* 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CA9C1B04B-EA67-4F2F-A9F3-B24A2AFB8598%40gmail.com%3E


*  
http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdSrZXDJk7VwuVzxDeqdocagS33Fx%2BstYD3yTx5--WXiA%40mail.gmail.com%3E

* 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3CCAN4YXvdWmCDSzXV40-wz1sr766GSwONGFem7UutkdXnsy0%2BXrg%40mail.gmail.com%3E

* 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201605.mbox/%3cc6c4e67c-9506-cb1f-1ca5-cfa6fc880...@elyograg.org%3e




--
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-9078) Let Parallel SQL support offset or start


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

Joel Bernstein commented on SOLR-9078:
--

Not yet. I think the easiest approach is to add a Stream implementation that 
does this (OffsetStream perhaps). It would need to skip Tuples until it reaches 
the offset. The /export handler probably can't support this directly so the 
Tuples will have to be sent and skipped.



> Let Parallel SQL support offset or start
> 
>
> Key: SOLR-9078
> URL: https://issues.apache.org/jira/browse/SOLR-9078
> Project: Solr
>  Issue Type: Bug
>Reporter: lingya
>Priority: Minor
>
> In solr6 ,Parallel SQL Interface don't support  offset  or  start  .



--
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-5724) Two node, one shard solr instance intermittently going offline


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

Shawn Heisey commented on SOLR-5724:


With the recent release of 6.0.0, 4.x is effectively dead.

Only *major* security issues and showstopper problems without a workaround will 
receive any attention ... and even those might not actually be fixed in 4.x.  
Only 5.x (on a limited basis) and 6.x are likely to get changes now.  If any 
fixes *do* happen in 4.x, they will only happen in 4.10.x, not 4.7.x.


> Two node, one shard solr instance intermittently going offline 
> ---
>
> Key: SOLR-5724
> URL: https://issues.apache.org/jira/browse/SOLR-5724
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6.1
> Environment: Ubuntu 12.04.3 LTS, 64 bit,  java version "1.6.0_45"
> Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
>Reporter: Joseph Duchesne
>
> One server is stuck in state "recovering" while the other is stuck in state 
> "down". After waiting 45 minutes or so for the cluster to recover, the 
> statuses were the same. 
> Log messages on the "recovering" server: (Just the individual errors for 
> brevity, I can provide full stack traces if that is helpful)
> {quote}
> We are not the leader
> ClusterState says we are the leader, but locally we don't think so
> cancelElection did not find election node to remove
> We are not the leader
> No registered leader was found, collection:listsC slice:shard1
> No registered leader was found, collection:listsC slice:shard1
> {quote}
> On the "down" server at the same timeframe:
> {quote}
> org.apache.solr.common.SolrException; forwarding update to 
> http://10.0.2.48:8983/solr/listsC/ failed - retrying ... retries: 3
> org.apache.solr.update.StreamingSolrServers$1; error
> Error while trying to recover. 
> core=listsC:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
>  We are not the leader
> Recovery failed - trying again... (0) core=listsC
> Stopping recovery for zkNodeName=core_node2core=listsC
> org.apache.solr.update.StreamingSolrServers$1; error
> org.apache.solr.common.SolrException: Service Unavailable
> {quote}
> I am not sure what is causing this, however it has happened a 3 times in the 
> past week. If there are any additional logs I can provide, or if there is 
> anything I can do to try to figure this out myself I will gladly try to help. 



--
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-8825) SolrJ JDBC - SQuirrel SQL documentation


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

Kevin Risden updated SOLR-8825:
---
Attachment: squirrelsql_solrjdbc.zip

Adding images I used for a post on this topic 
([here|https://www.linkedin.com/pulse/apache-solr-jdbc-squirrel-sql-kevin-risden]
 and 
[here|http://blogs.avalonconsult.com/blog/search/apache-solr-jdbc-squirrel-sql/]).
 Planning to create CWIKI page shortly.

> SolrJ JDBC - SQuirrel SQL documentation
> ---
>
> Key: SOLR-8825
> URL: https://issues.apache.org/jira/browse/SOLR-8825
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: solr_jdbc_SQuirrelSQL_20160311.pdf, 
> squirrelsql_solrjdbc.zip
>
>
> Like SOLR-8521, it would be great to document how SQuirrel SQL can be used 
> with SolrJ JDBC.



--
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-8521) Add documentation for how to use Solr JDBC driver with SQL client like DB Visualizer


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

Kevin Risden updated SOLR-8521:
---
Attachment: dbvisualizer_solrjdbc.zip

Adding images I used for a post on this topic 
([here|https://www.linkedin.com/pulse/apache-solr-jdbc-dbvisualizer-kevin-risden]
 and 
[here|http://blogs.avalonconsult.com/blog/search/apache-solr-jdbc-dbvisualizer/]).
 Planning to create CWIKI page shortly.

> Add documentation for how to use Solr JDBC driver with SQL client like DB 
> Visualizer
> 
>
> Key: SOLR-8521
> URL: https://issues.apache.org/jira/browse/SOLR-8521
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, SolrJ
>Affects Versions: master
>Reporter: Kevin Risden
> Attachments: dbvisualizer_solrjdbc.zip, 
> solr_jdbc_dbvisualizer_20160203.pdf
>
>
> Currently this requires the following:
> * a JDBC SQL client program (like DBVisualizer or SQuirrelSQL)
> * all jars from solr/dist/solrj-lib/* to be on the SQL client classpath
> * solr/dist/solr-solrj-6.0.0-SNAPSHOT.jar on the SQL client classpath
> * a valid JDBC connection string (like 
> jdbc:solr://SOLR_ZK_CONNECTION_STRING?collection=COLLECTION_NAME)
> * without SOLR-8213, the username/password supplied by the SQL client will be 
> ignored.



--
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-8996) Add Random Streaming Expression


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

Shawn Heisey commented on SOLR-8996:


I've never looked at streaming at all, so perhaps I should be ignored ...

Is there any way to detect this situation and note in the error message that it 
may not be a real failure?

> Add Random Streaming Expression
> ---
>
> Key: SOLR-8996
> URL: https://issues.apache.org/jira/browse/SOLR-8996
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: RandomStream.java, 
> SOLR-8996-decrease-failure-probability.patch, SOLR-8996.patch
>
>
> The random Streaming Expression will return a *limited* random stream of 
> Tuples that match a query. This will be useful in many different scenarios 
> where random data sets are needed.
> Proposed syntax:
> {code}
> random(baskets, q="productID:productX", rows="100", fl="basketID") 
> {code}
> The sample code above will query the *baskets* collection and return 100 
> random *basketID's* where the productID is productX.
> The underlying implementation will rely on Solr's random field type.



--
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-8458) Add Streaming Expressions tests for parameter substitution

2016-05-06 Thread ASF subversion and git services (JIRA)


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

Kevin Risden resolved SOLR-8458.

   Resolution: Implemented
Fix Version/s: master
   6.1

> Add Streaming Expressions tests for parameter substitution
> --
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 6.1, master
>
> Attachments: SOLR-8458.patch, SOLR-8458.patch, SOLR-8458.patch, 
> SOLR-8458.patch, SOLR-8458.patch
>
>
> This ticket is to add Streaming Expression tests that exercise the existing 
> macro expansion feature described here:  
> http://yonik.com/solr-query-parameter-substitution/
> Sample syntax below:
> {code}
> http://localhost:8983/col/stream?expr=merge(${left}, ${right}, 
> ...)=search(...)=search(...)
> {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

Re: JIRA version cleanup

2016-05-06 Thread David Smiley

Thanks for doing that Steve.

On Fri, May 6, 2016 at 9:54 AM Steve Rowe  wrote:

> I was looking at the published 5.5.1 Changes.html and noticed that there
> was no release date associated with the 5.3.2 release, and so I went and
> looked at the JIRA version management pages, which is where this
> information is drawn from when Changes.html is built:
>
> <
> https://issues.apache.org/jira/plugins/servlet/project-config/LUCENE/versions
> >
> <
> https://issues.apache.org/jira/plugins/servlet/project-config/SOLR/versions
> >
>
> I noticed that as far as JIRA was concerned, 5.3.2 and 6.0.0 had never
> been released, and had no release dates.  So I added release dates for
> those two, and added missing descriptions, and archived older placeholder
> versions that were never released.
>
> Anshum, notice that I did not “release” 5.5.1 and add a release date.
>
> Release managers apparently aren’t always following the “Update JIRA”
> section in the ReleaseToDo: <
> http://wiki.apache.org/lucene-java/ReleaseTodo#Update_JIRA>
>
> --
> Steve
> www.lucidworks.com
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-8458) Add Streaming Expressions tests for parameter substitution


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

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

Commit 26027259a5fff5f8e7df1a927708f048ba92002f in lucene-solr's branch 
refs/heads/master from [~risdenk]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2602725 ]

SOLR-8458: Add Streaming Expressions tests for parameter substitution


> Add Streaming Expressions tests for parameter substitution
> --
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8458.patch, SOLR-8458.patch, SOLR-8458.patch, 
> SOLR-8458.patch, SOLR-8458.patch
>
>
> This ticket is to add Streaming Expression tests that exercise the existing 
> macro expansion feature described here:  
> http://yonik.com/solr-query-parameter-substitution/
> Sample syntax below:
> {code}
> http://localhost:8983/col/stream?expr=merge(${left}, ${right}, 
> ...)=search(...)=search(...)
> {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-8458) Add Streaming Expressions tests for parameter substitution

2016-05-06 Thread ASF subversion and git services (JIRA)


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

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

Commit 4d15b9fa080cb95465338ec773a972559de7ec3d in lucene-solr's branch 
refs/heads/branch_6x from [~risdenk]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4d15b9f ]

SOLR-8458: Add Streaming Expressions tests for parameter substitution


> Add Streaming Expressions tests for parameter substitution
> --
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8458.patch, SOLR-8458.patch, SOLR-8458.patch, 
> SOLR-8458.patch, SOLR-8458.patch
>
>
> This ticket is to add Streaming Expression tests that exercise the existing 
> macro expansion feature described here:  
> http://yonik.com/solr-query-parameter-substitution/
> Sample syntax below:
> {code}
> http://localhost:8983/col/stream?expr=merge(${left}, ${right}, 
> ...)=search(...)=search(...)
> {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-7241) Improve performance of geo3d for polygons with very large numbers of points


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

David Smiley commented on LUCENE-7241:
--

Awesome; thanks for sharing :-)  Spatial is really moving these days.

> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL: https://issues.apache.org/jira/browse/LUCENE-7241
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7241.patch, LUCENE-7241.patch, LUCENE-7241.patch, 
> LUCENE-7241.patch, LUCENE-7241.patch
>
>
> This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.
> The trick here is to organize edges by some criteria, e.g. z value range, and 
> use that to avoid needing to go through all edges and/or tile large irregular 
> polygons.  Then we use the ability to quickly determine intersections to 
> figure out whether a point is within the polygon, or not.
> The current way geo3d polygons are constructed involves finding a single 
> point, or "pole", which all polygon points circle.  This point is known to be 
> either "in" or "out" based on the direction of the points.  So we have one 
> place of "truth" on the globe that is known at polygon setup time.
> If edges are organized by z value, where the z values for an edge are 
> computed by the standard way of computing bounds for a plane, then we can 
> readily organize edges into a tree structure such that it is easy to find all 
> edges we need to check for a given z value.  Then, we merely need to compute 
> how many intersections to consider as we navigate from the "truth" point to 
> the point being tested.  In practice, this means both having a tree that is 
> organized by z, and a tree organized by (x,y), since we need to navigate in 
> both directions.  But then we can cheaply count the number of intersections, 
> and once we do that, we know whether our point is "in" or "out".
> The other performance improvement we need is whether a given plane intersects 
> the polygon within provided bounds.  This can be done using the same two 
> trees (z and (x,y)), by virtue of picking which tree to use based on the 
> plane's minimum bounds in z or (x,y).  And, in practice, we might well use 
> three trees: one in x, one in y, and one in z, which would mean we didn't 
> have to compute longitudes ever.
> An implementation like this trades off the cost of finding point membership 
> in near O\(log\(n)) time vs. the extra expense per step of finding that 
> membership.  Setup of the query is O\(n) in this scheme, rather than O\(n^2) 
> in the current implementation, but once again each individual step is more 
> expensive.  Therefore I would expect we'd want to use the current 
> implementation for simpler polygons and this sort of implementation for 
> tougher polygons.  Choosing which to use is a topic for another ticket.



--
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: org.apache.solr.schema.TestManagedSchemaAPI.test

2016-05-06 Thread Steve Rowe

Hi Christine,

This test was added in SOLR-8662.  Varun did the work and I reviewed.

I asked a similar question about testReloadAndAddSimple - from 

 :

> testReloadAndAddSimple() always succeeds, regardless of the SchemaManager 
> changes, so I'm not sure why it's there, since it doesn't have anything to do 
> with new field visibility - can it be removed?


Varun replied (from 
):

> I've kept testReloadAndAddSimple() for now. In one test run when I was using 
> AbstractDistribZkTestBase, I'd seen after the reload the session had expired 
> while reading the managed-schema file. So I had added the test and retry 
> logic. This was a couple of months back when I had initially worked on the 
> patch so I don't remember everything.

--
Steve
www.lucidworks.com

> On May 6, 2016, at 9:43 AM, Christine Poerschke (BLOOMBERG/ LONDON) 
>  wrote:
> 
> Hello.
> 
> Just wondering if anyone is looking into these?
> 
> I took a little look and am unclear on the difference between the 
> testReloadAndAddSimple and testAddFieldAndDocument methods.
> 
> Happy to @BadApple annotate and create a JIRA ticket for follow-up if that 
> would help?
> 
> Christine
> 
> - Original Message -
> From: dev@lucene.apache.org
> To: dev@lucene.apache.org
> At: May  5 2016 22:13:48
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/266/
> Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseSerialGC
> 
> 1 tests failed.
> FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test
> 
> Error Message:
> Error from server at 
> http://127.0.0.1:36313/solr/testschemaapi_shard1_replica1: ERROR: [doc=2] 
> unknown field 'myNewField1'
> 
> Stack Trace:
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:36313/solr/testschemaapi_shard1_replica1: ERROR: 
> [doc=2] unknown field 'myNewField1'
>at __randomizedtesting.SeedInfo.seed([91AE8EA7EC777680:19FAB17D428B1B78]:0)
>at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
>at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
>at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
>at 
> org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
>at 
> org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
>at 
> org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
>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:1764)
>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
>at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
>at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
>at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
>at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
>at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
>at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
>at 
>

[jira] [Commented] (SOLR-8661) Upgrade guava version to 18.0 due to Presto dependency


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

Kevin Risden commented on SOLR-8661:


[~mdrob] or [~markrmil...@gmail.com] Did the Guava version leak get fixed in 
later versions of Hadoop? Saw SOLR-9076 filed to update the Hadoop version.

> Upgrade guava version to 18.0 due to Presto dependency
> --
>
> Key: SOLR-8661
> URL: https://issues.apache.org/jira/browse/SOLR-8661
> Project: Solr
>  Issue Type: Task
>  Components: Parallell SQL
>Reporter: Jan Høydahl
>Priority: Minor
>  Labels: sql, streaming_api
>
> The Presto parser depends on {{com.google.guava/guava 18.0}}, and Solr 
> currently uses 14.0.1. I have seen a Class not found exception for some 
> {{com.google.common.base}} classes when playing with Parallell SQL.



--
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-8458) Add Streaming Expressions tests for parameter substitution


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

Kevin Risden updated SOLR-8458:
---
Attachment: SOLR-8458.patch

Updated patch to master based on SOLR-9065. Running tests and precommit now.

> Add Streaming Expressions tests for parameter substitution
> --
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8458.patch, SOLR-8458.patch, SOLR-8458.patch, 
> SOLR-8458.patch, SOLR-8458.patch
>
>
> This ticket is to add Streaming Expression tests that exercise the existing 
> macro expansion feature described here:  
> http://yonik.com/solr-query-parameter-substitution/
> Sample syntax below:
> {code}
> http://localhost:8983/col/stream?expr=merge(${left}, ${right}, 
> ...)=search(...)=search(...)
> {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

Re: [jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'

2016-05-06 Thread Mark Miller

Should we even have {{6.x}} and {{5.x}} versions at all?

No. We have too many people with JIRA admin it seems.

- Mark

On Fri, May 6, 2016 at 10:14 AM Steve Rowe (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/LUCENE-7271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274079#comment-15274079
> ]
>
> Steve Rowe commented on LUCENE-7271:
> 
>
> Looking at a different JIRA version problem (see [
> http://markmail.org/message/6ac5szyce3qhoo3l]), I noticed that LUCENE
> (and not SOLR) has version contstants {{6.x}} and {{5.x}} - there are 38
> issues with these as fixVersion-s: [
> https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)
> ].
>
> I think this is a related problem to the master->6.0 issue being dealt
> with here.
>
> Should we even have {{6.x}} and {{5.x}} versions at all?
>
> > Cleanup jira's concept of 'master' and '6.0'
> > 
> >
> > Key: LUCENE-7271
> > URL: https://issues.apache.org/jira/browse/LUCENE-7271
> > Project: Lucene - Core
> >  Issue Type: Bug
> >Reporter: Hoss Man
> >Assignee: Hoss Man
> >
> > Jira's concept of "Fix Version: master" is currently screwed up, as
> noted & discussed in this mailing list thread...
> >
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> > The current best plan of attack (summary) is:
> > * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> > * add a new {{master (7.0)}} to use moving forward
> > * manually audit/fix the fixVersion of some clean up issues as needed.
> > I'm using this issue to track this work.
> > 
> > Detailed Check list of planned steps:
> > * S1: Generate a CSV report listing all resolved/closed Jira's with
> 'fixVersion=master AND fixVersion=6.1'
> > **
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> > *** currently about ~100 issues
> > ** The operating assumption is that any non-resolved issues should have
> the fixVersion set correctly if/when they are resolved in the future
> > * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL*
> to every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> > ** The comments will include unique strings based on the the specific
> query done, and will map the list back to this issue (ex
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> > ** These comments will serve as a backup plan making it possible to find
> all issues affected (by merging jira's concepts of 'master' and '6.0')
> after the fact if need be.
> > ** Queries to use for bulk edits:
> > *** master:
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> > *** 6.0:
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> > * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> > ** This needs to be done distinctly for both LUCENE and SOLR
> > * S4: Add a new "master (7.0)" version to Jira
> > ** This needs to be done distinctly for both LUCENE and SOLR
> > * S5: audit every issue in the CSV file from S1 above to determine
> if/when the issue should get fixVersion="master (7.0)" *added* to it or
> fixVersion="6.0" *removed* from it:
> > ** if it only ever had commits to master (ie: before branch_6x was made
> on March 2nd) then no action needed.
> > ** if it has distinct commits to both master after branch_6x was made on
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> > ** if it has no commits to branch_6_0, and the only commits to branch_6x
> are after branch_6_0 was created on March 3rd, then fixVersion="6.0" should
> be removed.
> > ** if there are no obvious commits in the issue comments, then sanity
> check why it has any fixVersion at all (can't reproduce? dup? etc...)
> > * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with
> fixVersion="master (7.0)" on the handful of issues where appropriate in
> case they fell through the cracks in S5:
> > ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for
> new features
> > *** currently only 1 jira mentioned in either files in 7.0 section
> > ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master |
> egrep '^\+'}} to find changesets on master that were not included in 6.0
> > *** currently ~40 commits
> > ** before removing fixVersion=6.0 from any of these issues, sanity check
> if this is a deprecation type situation

[jira] [Commented] (LUCENE-7271) Cleanup jira's concept of 'master' and '6.0'


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

Steve Rowe commented on LUCENE-7271:


Looking at a different JIRA version problem (see 
[http://markmail.org/message/6ac5szyce3qhoo3l]), I noticed that LUCENE (and not 
SOLR) has version contstants {{6.x}} and {{5.x}} - there are 38 issues with 
these as fixVersion-s: 
[https://issues.apache.org/jira/issues/?jql=project+in+(LUCENE,SOLR)+AND+(fixVersion=6.x+OR+fixVersion=5.x)].

I think this is a related problem to the master->6.0 issue being dealt with 
here.

Should we even have {{6.x}} and {{5.x}} versions at all?

> Cleanup jira's concept of 'master' and '6.0'
> 
>
> Key: LUCENE-7271
> URL: https://issues.apache.org/jira/browse/LUCENE-7271
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>
> Jira's concept of "Fix Version: master" is currently screwed up, as noted & 
> discussed in this mailing list thread...
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201604.mbox/%3Calpine.DEB.2.11.1604131529140.15570@tray%3E
> The current best plan of attack (summary) is:
> * use Jira's "Merge Versions" feature to merge {{master}} into {{6.0}}
> * add a new {{master (7.0)}} to use moving forward
> * manually audit/fix the fixVersion of some clean up issues as needed.
> I'm using this issue to track this work.
> 
> Detailed Check list of planned steps:
> * S1: Generate a CSV report listing all resolved/closed Jira's with 
> 'fixVersion=master AND fixVersion=6.1'
> ** 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%20master%20AND%20fixVersion%20%3D%206.1%20ORDER%20BY%20resolved%20DESC%2C%20key%20DESC
> *** currently about ~100 issues
> ** The operating assumption is that any non-resolved issues should have the 
> fixVersion set correctly if/when they are resolved in the future
> * S2: Use Jira's "Bulk Edit" feature to add comments *W/O SENDING EMAIL* to 
> every issue currently assocaited with fixVersion=6.0 or fixVersio=master
> ** The comments will include unique strings based on the the specific query 
> done, and will map the list back to this issue (ex 
> {{LUCENE-7271_20160503_master}} and {{LUCENE-7271_20160503_60}})
> ** These comments will serve as a backup plan making it possible to find all 
> issues affected (by merging jira's concepts of 'master' and '6.0') after the 
> fact if need be.
> ** Queries to use for bulk edits:
> *** master: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%20master%20ORDER%20BY%20key%20DESC
> *** 6.0: 
> https://issues.apache.org/jira/issues/?jql=project%20in%20%28LUCENE%2C%20SOLR%29%20AND%20fixVersion%20%3D%206.0%20ORDER%20BY%20key%20DESC
> * S3: Use Jira's "Merge Versions" feature to merge "master" into "6.0"
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S4: Add a new "master (7.0)" version to Jira
> ** This needs to be done distinctly for both LUCENE and SOLR
> * S5: audit every issue in the CSV file from S1 above to determine if/when 
> the issue should get fixVersion="master (7.0)" *added* to it or 
> fixVersion="6.0" *removed* from it:
> ** if it only ever had commits to master (ie: before branch_6x was made on 
> March 2nd) then no action needed.
> ** if it has distinct commits to both master after branch_6x was made on 
> March 2nd, then fixVersion="master (7.0)" should definitely be added.
> ** if it has no commits to branch_6_0, and the only commits to branch_6x are 
> after branch_6_0 was created on March 3rd, then fixVersion="6.0" should be 
> removed.
> ** if there are no obvious commits in the issue comments, then sanity check 
> why it has any fixVersion at all (can't reproduce? dup? etc...)
> * S6: Audit CHANGES.txt & git commits and *replace* fixVersion=6.0 with 
> fixVersion="master (7.0)" on the handful of issues where appropriate in case 
> they fell through the cracks in S5:
> ** Look at the 7.0 section of lucene/CHANGES.txt & solr/CHANGES.txt for new 
> features
> *** currently only 1 jira mentioned in either files in 7.0 section
> ** Use {{git co releases/lucene-solr/6.0.0 && git cherry -v master | egrep 
> '^\+'}} to find changesets on master that were not included in 6.0
> *** currently ~40 commits
> ** before removing fixVersion=6.0 from any of these issues, sanity check if 
> this is a deprecation type situation (involving diff commits in both 6.0 and 
> master) in which case fixVersion="master (7.0)" should be _added_ in addition 
> to fixVersion=6.0



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

-
To unsubscribe, e-mail:

[jira] [Assigned] (SOLR-8458) Add Streaming Expressions tests for parameter substitution


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

Kevin Risden reassigned SOLR-8458:
--

Assignee: Kevin Risden

> Add Streaming Expressions tests for parameter substitution
> --
>
> Key: SOLR-8458
> URL: https://issues.apache.org/jira/browse/SOLR-8458
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8458.patch, SOLR-8458.patch, SOLR-8458.patch, 
> SOLR-8458.patch
>
>
> This ticket is to add Streaming Expression tests that exercise the existing 
> macro expansion feature described here:  
> http://yonik.com/solr-query-parameter-substitution/
> Sample syntax below:
> {code}
> http://localhost:8983/col/stream?expr=merge(${left}, ${right}, 
> ...)=search(...)=search(...)
> {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] [Resolved] (SOLR-8184) Negative tests for JDBC Connection String

2016-05-06 Thread ASF subversion and git services (JIRA)


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

Kevin Risden resolved SOLR-8184.

   Resolution: Implemented
Fix Version/s: master
   6.1

Thanks [~susheel2...@gmail.com] and [~gerlowskija]. Sorry took so long to get 
back to this.

> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 6.1, master
>
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch, 
> SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String


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

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

Commit 219ddbb998cf0e011c087e7a0629908f40dd0d5d in lucene-solr's branch 
refs/heads/branch_6x from [~risdenk]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=219ddbb ]

SOLR-8184: Negative tests for JDBC Connection String


> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch, 
> SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-8184) Negative tests for JDBC Connection String

2016-05-06 Thread ASF subversion and git services (JIRA)


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

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

Commit 732e7e80c6fcb3d8ec2ecee3908dde88009f82d8 in lucene-solr's branch 
refs/heads/master from [~risdenk]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=732e7e8 ]

SOLR-8184: Negative tests for JDBC Connection String


> Negative tests for JDBC Connection String
> -
>
> Key: SOLR-8184
> URL: https://issues.apache.org/jira/browse/SOLR-8184
> Project: Solr
>  Issue Type: Test
> Environment: Trunk
>Reporter: Susheel Kumar
>Assignee: Kevin Risden
>Priority: Minor
> Attachments: SOLR-8184.patch, SOLR-8184.patch, SOLR-8184.patch, 
> SOLR-8184.patch
>
>
> Ticket to track negative tests for JDBC connection string SOLR-7986



--
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-9078) Let Parallel SQL support offset or start