[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 573 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/573/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseParallelGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([5BDB8779A2DB9146]: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:256)
at sun.reflect.GeneratedMethodAccessor19.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:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([5BDB8779A2DB9146:D38FB8A30C27FCBE]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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.RandomizedRunne

[RESULT] Lucene/Solr 5.5.1 RC1 Release vote

[Anshum Gupta]

The release vote for Lucene/Solr 5.5.1 RC1 has passed. I will work on
publishing it tomorrow.

Thanks to everyone who voted and helped with the release process!

-- 
Anshum Gupta

Re: lucene-solr:master: added a couple of extra methods

[Noble Paul]

There is nothing more I hate than bikeshedding. So, here we go

I'm gonna remove the getKey(), getValue() from pair and replace them with
fist() and second(). No deprecation or anything.
if anyone has any objection, please raise your hand and go ahead with your
preferred names. I can live with any name because we have enough instances
in Solr where naming is totally screwed up and I have managed to maintain
my sanity all these years.

Cheers

On Thu, May 5, 2016 at 8:15 AM, Scott Blum  wrote:

> Thanks Hoss, I think I just spit coffee all over my keyboard :D
>
> Sometimes you just gotta grow a Pair API.
>
> On Wed, May 4, 2016 at 2:29 PM, Chris Hostetter 
> wrote:
>
>>
>> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
>>
>> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
>>
>> how do those method names sound?
>>
>>
>> : Date: Wed, 4 May 2016 14:26:41 -0400
>> : From: Scott Blum 
>> : Reply-To: dev@lucene.apache.org
>> : To: dev@lucene.apache.org
>> : Subject: Re: lucene-solr:master: added a couple of extra methods
>> :
>> : Or left() and right()
>> :
>> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
>> : ichattopadhy...@gmail.com> wrote:
>> :
>> : > Another option to consider could be: first() and second()
>> : >
>> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>> : >
>> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
>> wrote:
>> : >
>> : >> The names getKey() and getValue() are not always relevant for a pair
>> : >> object. it's not necessarily a key and value. In that case, it makes
>> sense
>> : >> to use the index .
>> : >>
>> : >>
>> : >> This is a convention followed Scala. Tuple2 (
>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>> : >>
>> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
>> hossman_luc...@fucit.org
>> : >> > wrote:
>> : >>
>> : >>>
>> : >>> WTF is this?
>> : >>>
>> : >>> why are these (poorly named) alternatives for getKey and getValue
>> useful?
>> : >>>
>> : >>>
>> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>> : >>> : From: no...@apache.org
>> : >>> : Reply-To: dev@lucene.apache.org
>> : >>> : To: comm...@lucene.apache.org
>> : >>> : Subject: lucene-solr:master: added a couple of extra methods
>> : >>> :
>> : >>> : Repository: lucene-solr
>> : >>> : Updated Branches:
>> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>> : >>> :
>> : >>> :
>> : >>> : added a couple of extra methods
>> : >>> :
>> : >>> :
>> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> : >>> : Commit:
>> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>> : >>> : Tree:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>> : >>> : Diff:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>> : >>> :
>> : >>> : Branch: refs/heads/master
>> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>> : >>> : Parents: 0ebe6b0
>> : >>> : Author: Noble Paul 
>> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
>> : >>> : Committer: Noble Paul 
>> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
>> : >>> :
>> : >>> :
>> --
>> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
>> 
>> : >>> :  1 file changed, 8 insertions(+)
>> : >>> :
>> --
>> : >>> :
>> : >>> :
>> : >>> :
>> : >>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> :
>> --
>> : >>> : diff --git
>> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : index 423f94c..f87323c 100644
>> : >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : >>> : @@ -27,6 +27,14 @@ public class Pair implements
>> Serializable {
>> : >>> :
>> : >>> :private V value;
>> : >>> :
>> : >>> : +  public K _1() {
>> : >>> : +return key;
>> : >>> : +  }
>> : >>> : +
>> : >>> : +  public V _2() {
>> : >>> : +return value;
>> : >>> : +  }
>> : >>> : +
>> : >>> :public V getValue() {
>> : >>> :  return value;
>> : >>> :}
>> : >>> :
>> : >>> :
>> : >>>
>> : >>> -Hoss
>> : >>> http://www.lucidworks.com/
>> : >>>
>> : >>>
>> -
>> : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> : >>>
>> : >>>
>> : >>
>> : >>
>> : >> --
>> : >> -
>> : >> Noble Paul
>> : >>
>> : >
>> : >
>> :
>>
>> -Hoss
>> http://www.lucidworks.c

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_92) - Build # 5818 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([32DA28CACEAF189D]: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.GeneratedMethodAccessor18.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:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([32DA28CACEAF189D:BA8E171060537565]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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.RandomizedRun

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

[Apache Jenkins Server]

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

No tests ran.

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

[jira] [Commented] (SOLR-9063) CloudSolrClient with _route_ shouldn't require collection param to disambig cores

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9063:


Okay I chased this one down sufficiently to know what's going on.  Strictly 
speaking, there is no bug, or perhaps a small one.  In SOLR-5380 
[~markrmil...@gmail.com] fixed a bug in CloudSolrClient involving aliases 
pointing to multiple collections, and when "collection" was not specified as a 
parameter thus relying on the default collection (an alias).  I think it's 
because when the server gets the request to a specific core, doesn't know what 
the original/unresolved alias was.  So the solution implemented as seen in the 
code now is to send the request to a collection (the alias) level URL instead 
of to a specific core, but to do this only when "collection" isn't a parameter. 
 If "collection" *is* a parameter, then the server end will know how to deal 
with it.

But I think the logic to know when to do this should be improved to go to the 
collection level URL (thus not to the core) in more constrained circumstances.  
In particular, if {{collectionNames.size() == 1}} then it can go directly to 
the core URL, as we just resolved the alias (if there even was one).  I think 
the condition to differentiate should be exactly that instead of combining in 
the current condition looking to see if "collection" was specified, if at least 
for the reason of simpler understanding.  Would this be an optimization or 
simplification?  I'm not completely sure.

Here's the snippet I propose it become:
{code:java}
String url;
if (collectionNames.size() > 1) {
  // If there was an alias pointing to multiple collections, we 
can't send directly to a core.  If it were
  // convenient to modify the params to add collection=(list) we 
would but it isn't.  So we send the request
  // to the collection at the node and let the server end handle 
dispatching (incl. alias resolution).
  url = 
ZkCoreNodeProps.getCoreUrl(nodeProps.getStr(ZkStateReader.BASE_URL_PROP), 
collection);
} else {
  url = coreNodeProps.getCoreUrl();
}
((!sendToLeaders || coreNodeProps.isLeader()) ? urlList2 : 
replicas).add(url);
{code}

How did I run into this?  I'm working with a codebase that wanted to make a 
request to a custom request handler that did _not_ extend SearchHandler.  It's 
expected that a request be routed to the proper shard via an explicit 
{{\_route\_}}, which we do and CloudSolrClient processes that param.  However, 
because we didn't set "collection" as a param (we relied on the default 
collection prop), CloudSolrClient ignored it's work in figuring out which shard 
to send it to and instead sent the request to the collection level.  At the 
server end, HttpSolrCall doesn't process {{\_route_}} so it arbitrarily passed 
the request to a shard that was the wrong one on the node.  If the request 
handler were a SearchHandler (it isn't), then it'd become a distributed search 
to the {{\_route\_}} handling logic in HttpShardHandler.  The solution was 
quite simple -- add "collection" and don't use the default collection setting.  
That seemed awfully weird so I spent today finding out why it didn't work.  I 
argue this _should_ work and hence I propose the simple change above.

Testing in progress...

> CloudSolrClient with _route_ shouldn't require collection param to disambig 
> cores
> -
>
> Key: SOLR-9063
> URL: https://issues.apache.org/jira/browse/SOLR-9063
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, SolrJ
>Affects Versions: 4.10.4
>Reporter: David Smiley
>Assignee: David Smiley
>
> CloudSolrClient uses {{\_route\_}} to know where to send a request  It sorta 
> works -- it'll go to an appropriate _node_.  But it will only go to the 
> correct core on that node if the {{collection}} parameter is explicitly 
> added.  In another words, it ignores the default collection configured on 
> CloudSolrClient.  It also seems to ignore "collection" parameter to the 
> protected method sendRequest for this purpose too.  As I write this, see line 
> 1139 on master.



--
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-9070) how to range search on the field which contains multiple decimal point (eg: 2.5.0.4)

[Santhosh (JIRA)]

Santhosh created SOLR-9070:
--

 Summary: how to range search on the field which contains multiple 
decimal point (eg: 2.5.0.4)
 Key: SOLR-9070
 URL: https://issues.apache.org/jira/browse/SOLR-9070
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 3.6.1
Reporter: Santhosh
Priority: Blocker


Hi,

I have issue in my server. As I stated in the subject I want to do range search 
query on the field (eg: filed name is “version”) which contains value like 
(2.5.0.1, 2.5.0.4 and 2.5.0.10 etc).

When I do range search on the “version” field with criteria [* TO 2.5.0.5], it 
gave me all the value like (2.5.0.1, 2.5.0.10, 2.5.0.4). But this is wrong 
result. Since I was expecting only 2.5.0.1 and 2.5.0.4. 
But it include 2.5.0.10 with the results. I googled and found that solr does 
lexical sorting. But I want numerical sorting. I declared the field type as 
string in schema.xml.

I did the following solution but nothing worked. 
•   Converted the field type to number. But it gave me 
“NumberFormatException”.  Because java does not allow multiple decimal point.
•   I added left pad 0 with the value while adding document in solr. But no 
luck

Can you please give me good solution to come out of the issue?




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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1122 - Failure

[Apache Jenkins Server]

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

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([FF11B4792287D19:87A5249D3CD410E1]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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.l

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16659 - Still Failing!

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([EE1B7910DCCDD531:196897481A257AD7]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1248)
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 
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.handler.TestSolrConfigHandlerConcurrent.test

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([EE1B7910DCCDD531:664F46CA7231B8C9]:0)
at 
org.apache.solr.handler.Test

[JENKINS] Lucene-Solr-Tests-5.5-Java7 - Build # 24 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5-Java7/24/

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([BB3822E21AD5F41F:A4825315CAB532DA]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:136)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh(ZkStateReaderTest.java:42)
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 
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)




Build Log:
[...truncated 11242 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/111/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([AD868AB7C6C78C1F:25D2B56D683BE1E7]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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.TestRuleMarkFail

[jira] [Commented] (SOLR-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9069:
-

bq. My suggestion: nuke BaseDistributedSearchTestCase entirely and migrate 
everything to SolrCloudTestCase.

I am all for cutting over cloud tests to SolrCloudTestCase but 
BaseDistributedSearchTestCase is for testing non-cloud distributed search e.g. 
TestDistributedSearch so it shouldn't be nuked entirely.

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



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

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

[JENKINS] Lucene-Solr-NightlyTests-5.5 - Build # 11 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.5/11/

4 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:56352/_/ou

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:56352/_/ou
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:586)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:477)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
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 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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.j

[jira] [Comment Edited] (SOLR-8208) DocTransformer executes sub-queries

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat edited comment on SOLR-8208 at 5/5/16 3:06 AM:


[~ryantxu] I think the above code is quite dangerous because the original 
SolrRequestInfo can have some close hooks and the call to {code} 
SolrRequestInfo.clearRequestInfo(){code} will close all the hooks.

[~mkhludnev] I'm not laughing at all, i think it is a clever idea to handle 
swap out/swap in SolrRequestInfo (without modify SolrRequestInfo class) . I 
propose another approach, that change SolrRequestInfo a little bit.

{code}
public static void doActionInEmptyRequestInfo(Action action) throws IOException 
{
SolrRequestInfo prev = threadLocal.get();
threadLocal.remove();
try {
  action.doAction();
  SolrRequestInfo current = threadLocal.get();
  if (current != null) {
log.error("New SolrRequestInfo was not closed!  req=" + 
current.req.getOriginalParams().toString());
  }
  assert current == null;
} finally {
  threadLocal.set(prev);
}
  }

  public interface Action {
void doAction() throws IOException;
  }
{code}


was (Author: caomanhdat):
[~ryantxu] I think the above code is quite dangerous because the original 
SolrRequestInfo can have some close hooks and the call to {code} 
SolrRequestInfo.clearRequestInfo(){code} will close all the hooks.

[~mkhludnev] I'm not laughing at all, i think it is a good idea to handle 
SolrRequestInfo. I propose another approach

{code}
public static void doActionInEmptyRequestInfo(Action action) throws IOException 
{
SolrRequestInfo prev = threadLocal.get();
threadLocal.remove();
try {
  action.doAction();
  SolrRequestInfo current = threadLocal.get();
  if (current != null) {
log.error("New SolrRequestInfo was not closed!  req=" + 
current.req.getOriginalParams().toString());
  }
  assert current == null;
} finally {
  threadLocal.set(prev);
}
  }

  public interface Action {
void doAction() throws IOException;
  }
{code}

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..&q=name_s:john&fl=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}&depts.fl=text_t,dept_id_s_dv&depts.rows=12&depts.sort=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..&dept.q={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> propo

[jira] [Commented] (SOLR-8208) DocTransformer executes sub-queries

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-8208:


[~ryantxu] I think the above code is quite dangerous because the original 
SolrRequestInfo can have some close hooks and the call to {code} 
SolrRequestInfo.clearRequestInfo(){code} will close all the hooks.

[~mkhludnev] I'm not laughing at all, i think it is a good idea to handle 
SolrRequestInfo. I propose another approach

{code}
public static void doActionInEmptyRequestInfo(Action action) throws IOException 
{
SolrRequestInfo prev = threadLocal.get();
threadLocal.remove();
try {
  action.doAction();
  SolrRequestInfo current = threadLocal.get();
  if (current != null) {
log.error("New SolrRequestInfo was not closed!  req=" + 
current.req.getOriginalParams().toString());
  }
  assert current == null;
} finally {
  threadLocal.set(prev);
}
  }

  public interface Action {
void doAction() throws IOException;
  }
{code}

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..&q=name_s:john&fl=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}&depts.fl=text_t,dept_id_s_dv&depts.rows=12&depts.sort=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..&dept.q={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave&indent=true&fl=*,depts:[subquery]&rows=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}&depts.fl=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10&depts.logParamsList=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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 # 559 - Still Failing!

[Policeman Jenkins Server]

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

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([5B72EF769E95B60C:D326D0AC3069DBF4]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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.TestRuleMarkFailur

Re: jira git bot skipping janhoy -- was: Re: [jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[Tomás Fernández Löbbe]

I believe it may be a problem with special characters (in the author
name?). I had the same issue

On Wed, May 4, 2016 at 7:30 PM, David Smiley 
wrote:

> Not even on master or 6x branches?  That'd be weird.  FYI no commits to
> branches matching /(lucene|solr)-.*/ will be posted to JIRA; that's the
> filter (from memory) we got infra to add.
>
>
> On Wed, May 4, 2016 at 7:48 PM Chris Hostetter 
> wrote:
>
>>
>> : [~markrmil...@gmail.com], I don't think that a single one of my GIT
>> : commits have ever been tagged by the tag bot... It does not like me :(
>>
>>
>> that's really bizzare -- you should definitely file a jira with infra to
>> try and get to the bottom of this.
>>
>>
>>
>> -Hoss
>> http://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-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9069:


BaseDistributedSearchTestCase actually doesn't bother me, it's the other 
abstract classes below it for ZK -- AbstractDistribZkTestBase and 
AbstractFullDistribZkTestBase.  BaseDistributedSearchTestCase is very useful 
for testing parity between sharded and non-sharded.  Do you have plans to 
introduce another mechanism to replace this key nature of 
BaseDistributedSearchTestCase?

bq. ...migrate everything to SolrCloudTestCase. I'm going to be working on that 
this week...

That sounds like a lot of work!  You might first introduce a test shim, 
deprecated from the outset, that exists to house many of the utility methods 
involved.  And then tests below AbstractDistribZkTestBase can subclass _this_ 
one.  This will make the change less disruptive and more manageable.

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



--
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-Linux (32bit/jdk1.8.0_92) - Build # 572 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/572/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseG1GC

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([CD132CDD4048D109:45471307EEB4BCF1]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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(TestRuleMa

Re: lucene-solr:master: added a couple of extra methods

[Scott Blum]

Thanks Hoss, I think I just spit coffee all over my keyboard :D

Sometimes you just gotta grow a Pair API.

On Wed, May 4, 2016 at 2:29 PM, Chris Hostetter 
wrote:

>
> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
>
> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
>
> how do those method names sound?
>
>
> : Date: Wed, 4 May 2016 14:26:41 -0400
> : From: Scott Blum 
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : Subject: Re: lucene-solr:master: added a couple of extra methods
> :
> : Or left() and right()
> :
> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
> : ichattopadhy...@gmail.com> wrote:
> :
> : > Another option to consider could be: first() and second()
> : >
> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
> : >
> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
> wrote:
> : >
> : >> The names getKey() and getValue() are not always relevant for a pair
> : >> object. it's not necessarily a key and value. In that case, it makes
> sense
> : >> to use the index .
> : >>
> : >>
> : >> This is a convention followed Scala. Tuple2 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
> : >>
> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
> hossman_luc...@fucit.org
> : >> > wrote:
> : >>
> : >>>
> : >>> WTF is this?
> : >>>
> : >>> why are these (poorly named) alternatives for getKey and getValue
> useful?
> : >>>
> : >>>
> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
> : >>> : From: no...@apache.org
> : >>> : Reply-To: dev@lucene.apache.org
> : >>> : To: comm...@lucene.apache.org
> : >>> : Subject: lucene-solr:master: added a couple of extra methods
> : >>> :
> : >>> : Repository: lucene-solr
> : >>> : Updated Branches:
> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
> : >>> :
> : >>> :
> : >>> : added a couple of extra methods
> : >>> :
> : >>> :
> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : >>> : Commit:
> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
> : >>> : Tree:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
> : >>> : Diff:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
> : >>> :
> : >>> : Branch: refs/heads/master
> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
> : >>> : Parents: 0ebe6b0
> : >>> : Author: Noble Paul 
> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
> : >>> : Committer: Noble Paul 
> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
> : >>> :
> : >>> :
> --
> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
> 
> : >>> :  1 file changed, 8 insertions(+)
> : >>> :
> --
> : >>> :
> : >>> :
> : >>> :
> : >>>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> :
> --
> : >>> : diff --git
> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : index 423f94c..f87323c 100644
> : >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : @@ -27,6 +27,14 @@ public class Pair implements Serializable
> {
> : >>> :
> : >>> :private V value;
> : >>> :
> : >>> : +  public K _1() {
> : >>> : +return key;
> : >>> : +  }
> : >>> : +
> : >>> : +  public V _2() {
> : >>> : +return value;
> : >>> : +  }
> : >>> : +
> : >>> :public V getValue() {
> : >>> :  return value;
> : >>> :}
> : >>> :
> : >>> :
> : >>>
> : >>> -Hoss
> : >>> http://www.lucidworks.com/
> : >>>
> : >>> -
> : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> : >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> : >>>
> : >>>
> : >>
> : >>
> : >> --
> : >> -
> : >> Noble Paul
> : >>
> : >
> : >
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: jira git bot skipping janhoy -- was: Re: [jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[David Smiley]

Not even on master or 6x branches?  That'd be weird.  FYI no commits to
branches matching /(lucene|solr)-.*/ will be posted to JIRA; that's the
filter (from memory) we got infra to add.

On Wed, May 4, 2016 at 7:48 PM Chris Hostetter 
wrote:

>
> : [~markrmil...@gmail.com], I don't think that a single one of my GIT
> : commits have ever been tagged by the tag bot... It does not like me :(
>
>
> that's really bizzare -- you should definitely file a jira with infra to
> try and get to the bottom of this.
>
>
>
> -Hoss
> http://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

Re: lucene-solr:master: added a couple of extra methods

[Steve Davids]

Looks like both Kotlin and C# also use first() and second() for their Pair 
classes:

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-pair/#properties 

https://msdn.microsoft.com/en-us/library/system.web.ui.pair(v=vs.110).aspx#Anchor_4
 


Though, out of curiosity why not just use the Pair class in Apache 
Commons-Lang? 
http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/Pair.html
 


-Steve

> On May 4, 2016, at 4:08 PM, David Smiley  wrote:
> 
> LOL  we need javadocs on more methods (and classes) indeed.
> 
> On Wed, May 4, 2016 at 2:29 PM Chris Hostetter  > wrote:
> 
> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
> 
> how do those method names sound?
> 
> 
> : Date: Wed, 4 May 2016 14:26:41 -0400
> : From: Scott Blum mailto:dragonsi...@gmail.com>>
> : Reply-To: dev@lucene.apache.org 
> : To: dev@lucene.apache.org 
> : Subject: Re: lucene-solr:master: added a couple of extra methods
> :
> : Or left() and right()
> :
> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
> : ichattopadhy...@gmail.com > wrote:
> :
> : > Another option to consider could be: first() and second()
> : >
> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/ 
> 
> : >
> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul  > wrote:
> : >
> : >> The names getKey() and getValue() are not always relevant for a pair
> : >> object. it's not necessarily a key and value. In that case, it makes 
> sense
> : >> to use the index .
> : >>
> : >>
> : >> This is a convention followed Scala. Tuple2 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html 
>  ) to Tuple10 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html 
> )
> : >>
> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter 
> mailto:hossman_luc...@fucit.org>
> : >> > wrote:
> : >>
> : >>>
> : >>> WTF is this?
> : >>>
> : >>> why are these (poorly named) alternatives for getKey and getValue 
> useful?
> : >>>
> : >>>
> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
> : >>> : From: no...@apache.org 
> : >>> : Reply-To: dev@lucene.apache.org 
> : >>> : To: comm...@lucene.apache.org 
> : >>> : Subject: lucene-solr:master: added a couple of extra methods
> : >>> :
> : >>> : Repository: lucene-solr
> : >>> : Updated Branches:
> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
> : >>> :
> : >>> :
> : >>> : added a couple of extra methods
> : >>> :
> : >>> :
> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo 
> 
> : >>> : Commit:
> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998 
> 
> : >>> : Tree: 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998 
> 
> : >>> : Diff: 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998 
> 
> : >>> :
> : >>> : Branch: refs/heads/master
> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
> : >>> : Parents: 0ebe6b0
> : >>> : Author: Noble Paul  >
> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
> : >>> : Committer: Noble Paul  >
> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
> : >>> :
> : >>> : --
> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8 
> 
> : >>> :  1 file changed, 8 insertions(+)
> : >>> : --
> : >>> :
> : >>> :
> : >>> :
> : >>> 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>  
> 
> : >>> : --
> : >>> : diff --git a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : index 423f94c..f87323c 100644
> : >>> : --- a/sol

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 263 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/263/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:38310/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:38310/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([C3AD7780EC309553:4BF9485A42CCF8AB]: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 
org.apache.lucene.util.TestRuleI

[jira] [Updated] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9068:
---
Attachment: SOLR-9068.patch

on the theory that the Solaris SSL impl has bugs when the SecureRandom returns 
nothing but NUL bytes, I drafted this patch to always fill any byte[] with 
Byte.MAX_VALUE.

I'm not seeing any measurably slowdown when using this patch, but obviously it 
isn'

[~thetaphi]: I'd love to know if you can (semi-)reliably reproduce the failures 
your jenkins machines were getting on your Solaris box, and if this patch fixes 
those bugs.

(I'm not seeing any measurably slowdown when using this patch, but it obviously 
involves some extra cycles, so it's not really worth committing unless it 
solves the problem)



> 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
>
>
> 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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_92) - Build # 16658 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16658/
Java: 32bit/jdk1.8.0_92 -client -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestSolrConfigHandlerCloud

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([C24312FB4480E56D]: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.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$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:  org.apache.solr.cloud.TestCloudBackupRestore.test

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([C24312FB4480E56D:4A172D21EA7C8895]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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.ja

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[ASF subversion and git services (JIRA)]

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

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

Commit 6ade99947a6e123e3783eb3c3799525e4328e8bc in lucene-solr's branch 
refs/heads/master from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6ade999 ]

SOLR-9014: Fix javadoc


> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 183 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/183/

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([F697283DCB4364CB:7EC317E765BF0933]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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.luce

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

[Policeman Jenkins Server]

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

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([431376F96060D568:CB474923CE9CB890]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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.

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9014: Deprecate ClusterState.getCollections and introduce a new 
ClusterState.getCollectionsMap instead


> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[ASF subversion and git services (JIRA)]

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

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

Commit 827573b1a7bda2ae853f03c518f313e5992c1a7c in lucene-solr's branch 
refs/heads/master from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=827573b ]

SOLR-9030: Added a code comment as to why we use Integer.MAX_VALUE instead of -1


> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
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 git bot skipping janhoy -- was: Re: [jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[Chris Hostetter]

: [~markrmil...@gmail.com], I don't think that a single one of my GIT 
: commits have ever been tagged by the tag bot... It does not like me :(


that's really bizzare -- you should definitely file a jira with infra to 
try and get to the bottom of this.



-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9030: The 'downnode' overseer command can trip asserts in ZkStateWriter


> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
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-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9030:

Attachment: SOLR-9030.patch

I made the znode version final as well. I'll commit this now.

> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch, SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
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-8208) DocTransformer executes sub-queries

[Ryan McKinley (JIRA)]

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

Ryan McKinley commented on SOLR-8208:
-

Did you try something like:

{code}
SolrRequestInfo orig = SolrRequestInfo.getRequestInfo();
try {
  SolrRequestInfo.clearRequestInfo();
  
  // TODO, make whatever call you need
}
finally {
  SolrRequestInfo.setRequestInfo(orig);
}
{code}

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..&q=name_s:john&fl=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}&depts.fl=text_t,dept_id_s_dv&depts.rows=12&depts.sort=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..&dept.q={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave&indent=true&fl=*,depts:[subquery]&rows=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}&depts.fl=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10&depts.logParamsList=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9030:
-

Regarding #1, somebody still has to determine when to flush, maybe we just 
always do it time-based. In that case the logic can move (back) to Overseer. 
This flushing logic used to live in Overseer initially but it made things 
complicated so I moved it out to ZkStateWriter to simplify the overseer loop.

For #2 -- the ZkStateWriter's live nodes aren't used anywhere. It is only for 
correctness that I always copy over live nodes from the ZkStateReader. I don't 
mind doing this though.

For #3 -- I never liked ZkWriteCallback even though I wrote that bit. It was 
always a hack. I like your idea of peeking N items at a time.

Let's create separate issues to track these improvements.

> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+116) - Build # 571 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/571/
Java: 32bit/jdk-9-ea+116 -server -XX:+UseConcMarkSweepGC

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([9AD4AA2DF0AE4548:128095F75E5228B0]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
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(TestRuleAss

[jira] [Updated] (SOLR-9030) The 'downnode' command can trip asserts in ZkStateWriter or cause BadVersionException in Overseer

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9030:

Attachment: SOLR-9030.patch

Patch which uses Integer.MAX_VALUE as the default znodeVersion and removes the 
assert in ZkStateWriter. The 'downnode' still has the problem that I described 
above but with this patch it will cause a BadVersionException which the 
Overseer is designed to recover from.

> The 'downnode' command can trip asserts in ZkStateWriter or cause 
> BadVersionException in Overseer
> -
>
> Key: SOLR-9030
> URL: https://issues.apache.org/jira/browse/SOLR-9030
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9030.patch
>
>
> While working on SOLR-9014 I came across a strange test failure.
> {code}
>[junit4] ERROR   16.9s | 
> AsyncCallRequestStatusResponseTest.testAsyncCallStatusResponse <<<
>[junit4]> Throwable #1: 
> com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an 
> uncaught exception in thread: Thread[id=46, 
> name=OverseerStateUpdate-95769832112259076-127.0.0.1:51135_z_oeg%2Ft-n_00,
>  state=RUNNABLE, group=Overseer state updater.]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3:CBF7E84BCF328A1A]:0)
>[junit4]> Caused by: java.lang.AssertionError
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([91F68DA7E10807C3]:0)
>[junit4]>  at 
> org.apache.solr.cloud.overseer.ZkStateWriter.writePendingUpdates(ZkStateWriter.java:231)
>[junit4]>  at 
> org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:240)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {code}
> The underlying problem can manifest by tripping the above assert or a 
> BadVersionException as well. I found that this was introduced in SOLR-7281 
> where a new 'downnode' command was added.



--
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-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9014:
-

Thanks Shawn, we should fix linkConfig -- I don't think we should support that 
use-case. We should also remove bootstrapping, it is long overdue. I'll create 
an issue though I won't have the time to attack it soon.

> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9014:

Attachment: SOLR-9014-deprecate-getCollections.patch

# Deprecates the ClusterState.getCollections method and introduces a new 
getCollectionsMap method.
# Removes a redundant call at ZkController.publishAndWaitForDownStates 
# Fixed SQLHandler.open which called getCollections twice, once to get size and 
then again to actually get the set of collection names

As I said earlier this change trips SOLR-9030 a lot more. I'll fix that issue 
first before I commit this patch.


> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014-deprecate-getCollections.patch, SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling

[Shikha Somani (JIRA)]

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

Shikha Somani commented on SOLR-8297:
-

To avoid confusion about this fix below is a comparison between how join worked 
in various versions:

||Solr 4.x||Solr 5.x|
|Secondary collection can be well sharded. |Secondary collection should be 
singly sharded||
|​Secondary collection shard/replica should be present on each node where 
primary collection shards are |Secondary collection should be replicated on all 
nodes where primary is present|
|Join query should have core name of both the collections|Join query should 
have only collection name and not core name. Specifying core name will throw 
exception|

Because of the above mentioned differences Solr 5.x has lost backward 
compatibility for join queries. Making it *nearly impossible* to upgrade to 
Solr 5.x from Solr 4.x.

The provided solution is adding backward compatibility for join queries with 
following conditions:
* Single shard of both primary and secondary collection present on same node
* Both primary and secondary collection should have same numShards and 
replicationFactor

This fix is providing *backward compatibility* and is *not an enhancement* for 
above requirements. If required another defect can be opened for backward 
compatibility support and this fix can be part of the new defect. 

> Allow join query over 2 sharded collections: enhance functionality and 
> exception handling
> -
>
> Key: SOLR-8297
> URL: https://issues.apache.org/jira/browse/SOLR-8297
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.3
>Reporter: Paul Blanchaert
>
> Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail 
> Khludnev.
> A) exception handling:
> The exception "SolrCloud join: multiple shards not yet supported" thrown in 
> the function findLocalReplicaForFromIndex of JoinQParserPlugin is not 
> triggered correctly: In my use-case, I've a join on a facet.query and when my 
> results are only found in 1 shard and the facet.query with the join is 
> querying the last replica of the last slice, then the exception is not thrown.
> I believe it's better to verify the nr of slices when we want to verify the  
> "multiple shards not yet supported" exception (so exception is thrown when 
> zkController.getClusterState().getSlices(fromIndex).size()>1).
> B) functional enhancement:
> I would expect that there is no problem to perform a cross-core join over 
> sharded collections when the following conditions are met:
> 1) both collections are sharded with the same replicationFactor and numShards
> 2) router.field of the collections is set to the same "key-field" (collection 
> of "fromindex" has router.field = "from" field and collection joined to has 
> router.field = "to" field)
> The router.field setup ensures that documents with the same "key-field" are 
> routed to the same node. 
> So the combination based on the "key-field" should always be available within 
> the same node.
> From a user perspective, I believe these assumptions seem to be a "normal" 
> use-case in the cross-core join in SolrCloud.
> Hope this helps



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

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

[JENKINS] Lucene-Solr-SmokeRelease-6.x - Build # 52 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/52/

No tests ran.

Build Log:
[...truncated 40519 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.03 sec (5.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.1.0-src.tgz...
   [smoker] 28.6 MB in 0.03 sec (1089.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.tgz...
   [smoker] 63.0 MB in 0.06 sec (1081.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.1.0.zip...
   [smoker] 73.5 MB in 0.07 sec (1073.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5999 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 5999 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] 
   [smoker] command "export 
JAVA_HOME="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8" 
PATH="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8/bin/java";
 ant clean test -Dtests.slow=false" failed:
   [smoker] Buildfile: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.1.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.1.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.1.0/ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.6 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 152ms :: artifacts 
dl 2ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker] 
-
   [smoker] 
   [smoker] -init-totals:
   [smoker] 
   [smoker] test-core:
   [smoker] 
   [smoker] -clover.disable:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: loading settings :: file = 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/lucene-6.1.0/ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] -clover.classpath:
   [smoker] 
   [smoker] -clover.setup:
   [smoker] 
   [smoker] clover:
   [smoker] 
   [smoker] -check-git-state:
   [smoker] 
   [smoker] -git-cleanroot:
   [smoker] 
   [smoker] -copy-git-state:
   [smoker] 
   [smoker] git-autoclean:
   

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3248 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
No collection param specified on request and no default collection has been set.

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No collection param specified 
on request and no default collection has been set.
at 
__randomizedtesting.SeedInfo.seed([56745CA0BD45D07F:DE20637A13B9BD87]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:590)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:106)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:71)
at org.apache.solr.client.solrj.SolrClient.add(SolrClient.java:85)
at 
org.apache.solr.cloud.TestCloudBackupRestore.indexDocs(TestCloudBackupRestore.java:132)
at 
org.apache.solr.cloud.TestCloudBackupRestore.test(TestCloudBackupRestore.java:93)
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 
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$

[jira] [Closed] (SOLR-9064) UpdateStream Explanation should include the explanation for the incoming stream

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-9064.
-
   Resolution: Fixed
Fix Version/s: master
   6.1

Applied to master and branch_6x.

> UpdateStream Explanation should include the explanation for the incoming 
> stream
> ---
>
> Key: SOLR-9064
> URL: https://issues.apache.org/jira/browse/SOLR-9064
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.1, master
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Fix For: 6.1, master
>
> Attachments: SOLR-9064.patch
>
>
> The explanation for an UpdateStream does not include a child explanation of 
> the incoming stream. This results in the UpdateStream explanation not being 
> all that informative.
> Simple fix, line 191 should add
> {code}
> child.addChild(tupleSource.toExplanation(factory));
> {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-9064) UpdateStream Explanation should include the explanation for the incoming stream

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9064: Adds an explanation of the incoming stream to an UpdateStream's 
explanation


> UpdateStream Explanation should include the explanation for the incoming 
> stream
> ---
>
> Key: SOLR-9064
> URL: https://issues.apache.org/jira/browse/SOLR-9064
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.1, master
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9064.patch
>
>
> The explanation for an UpdateStream does not include a child explanation of 
> the incoming stream. This results in the UpdateStream explanation not being 
> all that informative.
> Simple fix, line 191 should add
> {code}
> child.addChild(tupleSource.toExplanation(factory));
> {code}



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

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

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.8.0_92) - Build # 262 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/262/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([9785C6EF51156FA0:883FB7188175A965]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:136)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefresh(ZkStateReaderTest.java:42)
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 
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 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11173 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 
/h

[jira] [Commented] (SOLR-9064) UpdateStream Explanation should include the explanation for the incoming stream

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9064: Adds an explanation of the incoming stream to an UpdateStream's 
explanation


> UpdateStream Explanation should include the explanation for the incoming 
> stream
> ---
>
> Key: SOLR-9064
> URL: https://issues.apache.org/jira/browse/SOLR-9064
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.1, master
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Minor
> Attachments: SOLR-9064.patch
>
>
> The explanation for an UpdateStream does not include a child explanation of 
> the incoming stream. This results in the UpdateStream explanation not being 
> all that informative.
> Simple fix, line 191 should add
> {code}
> child.addChild(tupleSource.toExplanation(factory));
> {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-9053) Upgrade fileupload-commons to 1.3.1

[JIRA]

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

Jan Høydahl commented on SOLR-9053:
---

Fixed attribution and code refactor. master: b6f8c65, 6x: b6b6d24

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-6.x - Build # 56 - Still Failing

[Apache Jenkins Server]

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

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

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

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=17253, name=collection1, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:39126: collection already exists: 
awholynewstresscollection_collection1_0
at __randomizedtesting.SeedInfo.seed([358C62A1A273FF2D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:590)
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.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:404)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:357)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1192)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:962)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:898)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1595)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1616)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:987)




Build Log:
[...truncated 11942 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/solr/build/solr-core/test/J2/temp/solr.cloud.CollectionsAPIDistributedZkTest_358C62A1A273FF2D-001/init-core-data-001
   [junit4]   2> 2210492 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[358C62A1A273FF2D]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 2210492 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[358C62A1A273FF2D]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 2210494 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 2210494 INFO  (Thread-6400) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2210494 INFO  (Thread-6400) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 2210594 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.ZkTestServer start zk server on port:57646
   [junit4]   2> 2210594 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2210594 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2210596 INFO  (zkCallback-2424-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@6d7a83b4 
name:ZooKeeperConnection Watcher:127.0.0.1:57646 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 2210596 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 2210596 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 2210596 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 2210597 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 2210598 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[358C62A1A273FF2D]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 2210598 INFO  (zkCallback-2425-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@46c47bd5 
name:ZooKeeperConnection Watcher:127.0.0.1:57646/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:No

[jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[JIRA]

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

Jan Høydahl commented on SOLR-9053:
---

Thanks for the explanation of the refactor, I did not realize the change was 
directly related to the upgrade. I'll include those changes too.

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8208:


hmm... you might be laughing, but game is over.
The problem is to call EmbeddedSolrServer from DocTransformer. This call isn't 
possible from thread where SolrRequestInfo is present. So far it's not possible 
to suspend and then resume SolrRequestInfo. Juggling with threads complicates 
it a lot, however it's possible to manage threads after all, but not 
SolrRequestInfo.

[~ysee...@gmail.com] can you suggest an approach? 

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call it sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can specify subquery parameter prefix:
> {code}
> ..&q=name_s:john&fl=*,depts:[subquery fromIndex=departments]&
> depts.q={!term f=dept_id_s 
> v=$row.dept_ss_dv}&depts.fl=text_t,dept_id_s_dv&depts.rows=12&depts.sort=id 
> desc
> {code}   
> response is like
> {code}   
> 
> ...
> 
> 
> 1
> john
> ..
> 
> 
> Engineering
> These guys develop stuff
> 
> 
> Support
> These guys help users
> 
> 
> 
> 
> 
> {code}   
> * {{fl=depts:\[subquery]}} executes a separate request for every query result 
> row, and adds it into a document as a separate result list. The given field 
> name (here it's 'depts') is used as a prefix to shift subquery parameters 
> from main query parameter, eg {{depts.q}} turns to {{q}} for subquery, 
> {{depts.rows}} to {{rows}}.
> * document fields are available as implicit parameters with prefix {{row.}} 
> eg. if result document has a field {{dept_id}} it can be referred as 
> {{v=$row.dept_id}} this combines well with \{!terms} query parser   
> * {{separator=','}} is used when multiple field values are combined in 
> parameter. eg. a document has multivalue field {code}dept_ids={2,3}{code}, 
> thus referring to it via {code}..&dept.q={!terms f=id 
> v=$row.dept_ids}&..{code} executes a subquery {code}{!terms f=id}2,3{code}. 
> When omitted  it's a comma. 
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> However, it doesn't work on cloud setup (and will let you know), but it's 
> proposed to use regular params ({{collection}}, {{shards}} - whatever, with 
> subquery prefix as below ) to issue subquery to a collection
> {code}
> q=name_s:dave&indent=true&fl=*,depts:[subquery]&rows=20&
> depts.q={!terms f=dept_id_s v=$row.dept_ss_dv}&depts.fl=text_t&
> depts.indent=true&
> depts.collection=departments&
> depts.rows=10&depts.logParamsList=q,fl,rows,row.dept_ss_dv
> {code}
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



--
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: [VOTE] Release Lucene/Solr 5.5.1

[Joel Bernstein]

3 bugs fixes in Lucene! We should preface this with Lucene is riddled with
bugs!

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, May 4, 2016 at 4:04 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> Oh sorry I thought there were 0 changes ;)
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, May 4, 2016 at 3:16 PM, Anshum Gupta 
> wrote:
>
>> Mike, there were 3 bug fixes as per the change log. Also, no fixes != no
>> bugs :).
>>
>> On Wed, May 4, 2016 at 11:50 AM, Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> I think there were no Lucene changes in this release vs 5.5.0?
>>>
>>> So maybe the release notes should simply say:
>>>
>>>   Lucene is perfect and has no bugs.
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>> On Wed, May 4, 2016 at 1:39 PM, Anshum Gupta 
>>> wrote:
>>>
 Here is a draft of the release notes. Feel free to edit and fix
 something that I missed,

 Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
 Solr: https://wiki.apache.org/solr/ReleaseNote551

 On Wed, May 4, 2016 at 12:06 AM, Adrien Grand 
 wrote:

> +1 SUCCESS! [0:57:52.080980]
>
> Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
> écrit :
>
>> FYI, we generally don't consider weekends for the 72 hour window so
>> we'd be waiting until Wednesday to close this one out.
>> Thought I'd let everyone who's waiting know about this.
>>
>> On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta > > wrote:
>>
>>> Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.
>>>
>>> Artifacts:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>>
>>> Smoke tester:
>>>
>>>   python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>>
>>>
>>> Here's my +1:
>>>
>>> SUCCESS! [0:26:44.452268]
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
>


 --
 Anshum Gupta

>>>
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9014:


bq. Ideally, stateFormat=1, bootstrapping, predefined cores, legacyCloudMode 
would have all gone away completely in 6x.

+1 to that!  numShards as a System property is evil.

> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-6993:


Thanks for persisting Mike.  

I (and other JFlex community members) still haven't made any progress on the 
JFlex release blockers, so it's probably best to move forward using the current 
JFlex release rather than waiting for JFlex 1.7 to be released.

I'll try to review your work on this issue this week.

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.x
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.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-9045) configurable RecoveryStrategy support

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9045:


bq. How about renaming RecoveryStrategy to RecoveryImplementation (or something 
like it)

Might it have _what_ is being recovered?  Or say something like 
SolrCloudRecoveryImpl to at least give a sense of scope that it has to do with 
SolrCloud stuff?  Just a thought.  But then it's in the "cloud" package so 
perhaps nevermind.  My very first reaction was wondering if it was some sort of 
connection recovery thing.

> configurable RecoveryStrategy support 
> --
>
> Key: SOLR-9045
> URL: https://issues.apache.org/jira/browse/SOLR-9045
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
>
> objectives:
> * To allow users to change RecoveryStrategy settings such as maxRetries and 
> startingRecoveryDelay.
> * To support configuration of a custom recovery strategy.
> illustrative solrconfig.xml snippet:
> {code}
> 
>   250 
>   
> 
> {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-6993) Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all JFlex-based tokenizers to support Unicode 8.0

[Mike Drob (JIRA)]

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

Mike Drob commented on LUCENE-6993:
---

[~steve_rowe] - I see no movement coming from the JFlex community. How would 
you feel most comfortable proceeding?

> Update UAX29URLEmailTokenizer TLDs to latest list, and upgrade all 
> JFlex-based tokenizers to support Unicode 8.0
> 
>
> Key: LUCENE-6993
> URL: https://issues.apache.org/jira/browse/LUCENE-6993
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Mike Drob
>Assignee: Robert Muir
> Fix For: 6.x
>
> Attachments: LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, LUCENE-6993.patch, 
> LUCENE-6993.patch
>
>
> We did this once before in LUCENE-5357, but it might be time to update the 
> list of TLDs again. Comparing our old list with a new list indicates 800+ new 
> domains, so it would be nice to include them.
> Also the JFlex tokenizer grammars should be upgraded to support Unicode 8.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

Re: lucene-solr:master: added a couple of extra methods

[David Smiley]

LOL  we need javadocs on more methods (and classes) indeed.

On Wed, May 4, 2016 at 2:29 PM Chris Hostetter 
wrote:

>
> Or maybe methodWithFuckingJavadocsExplainingItsExistence() and
>
> otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()
>
> how do those method names sound?
>
>
> : Date: Wed, 4 May 2016 14:26:41 -0400
> : From: Scott Blum 
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : Subject: Re: lucene-solr:master: added a couple of extra methods
> :
> : Or left() and right()
> :
> : On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
> : ichattopadhy...@gmail.com> wrote:
> :
> : > Another option to consider could be: first() and second()
> : >
> : > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
> : >
> : > On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
> wrote:
> : >
> : >> The names getKey() and getValue() are not always relevant for a pair
> : >> object. it's not necessarily a key and value. In that case, it makes
> sense
> : >> to use the index .
> : >>
> : >>
> : >> This is a convention followed Scala. Tuple2 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
> : >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
> : >>
> : >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
> hossman_luc...@fucit.org
> : >> > wrote:
> : >>
> : >>>
> : >>> WTF is this?
> : >>>
> : >>> why are these (poorly named) alternatives for getKey and getValue
> useful?
> : >>>
> : >>>
> : >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
> : >>> : From: no...@apache.org
> : >>> : Reply-To: dev@lucene.apache.org
> : >>> : To: comm...@lucene.apache.org
> : >>> : Subject: lucene-solr:master: added a couple of extra methods
> : >>> :
> : >>> : Repository: lucene-solr
> : >>> : Updated Branches:
> : >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
> : >>> :
> : >>> :
> : >>> : added a couple of extra methods
> : >>> :
> : >>> :
> : >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : >>> : Commit:
> : >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
> : >>> : Tree:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
> : >>> : Diff:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
> : >>> :
> : >>> : Branch: refs/heads/master
> : >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
> : >>> : Parents: 0ebe6b0
> : >>> : Author: Noble Paul 
> : >>> : Authored: Tue May 3 20:34:36 2016 +0530
> : >>> : Committer: Noble Paul 
> : >>> : Committed: Tue May 3 20:34:36 2016 +0530
> : >>> :
> : >>> :
> --
> : >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
> 
> : >>> :  1 file changed, 8 insertions(+)
> : >>> :
> --
> : >>> :
> : >>> :
> : >>> :
> : >>>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> :
> --
> : >>> : diff --git
> a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : index 423f94c..f87323c 100644
> : >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : >>> : @@ -27,6 +27,14 @@ public class Pair implements Serializable
> {
> : >>> :
> : >>> :private V value;
> : >>> :
> : >>> : +  public K _1() {
> : >>> : +return key;
> : >>> : +  }
> : >>> : +
> : >>> : +  public V _2() {
> : >>> : +return value;
> : >>> : +  }
> : >>> : +
> : >>> :public V getValue() {
> : >>> :  return value;
> : >>> :}
> : >>> :
> : >>> :
> : >>>
> : >>> -Hoss
> : >>> http://www.lucidworks.com/
> : >>>
> : >>> -
> : >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> : >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> : >>>
> : >>>
> : >>
> : >>
> : >> --
> : >> -
> : >> Noble Paul
> : >>
> : >
> : >
> :
>
> -Hoss
> http://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-9053) Upgrade fileupload-commons to 1.3.1

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-9053:
-

[~janhoy] - I can understand wanting to keep the change minimal. Taking 
advantage of the generic types newly provided by the API seemed like a natural 
fit when updating the version, but I can file a new JIRA and submit patch there 
if you think it's still worthwhile.

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-5750) Backup/Restore API for SolrCloud

[ASF subversion and git services (JIRA)]

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

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

Commit 0a20dd47d1abbf0036896fac03dc7d801ebcd5bd in lucene-solr's branch 
refs/heads/master from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0a20dd4 ]

SOLR-5750: Fix test to specify the collection on commit


> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 6.1
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



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

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

Re: [VOTE] Release Lucene/Solr 5.5.1

[Michael McCandless]

Oh sorry I thought there were 0 changes ;)

Mike McCandless

http://blog.mikemccandless.com

On Wed, May 4, 2016 at 3:16 PM, Anshum Gupta  wrote:

> Mike, there were 3 bug fixes as per the change log. Also, no fixes != no
> bugs :).
>
> On Wed, May 4, 2016 at 11:50 AM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I think there were no Lucene changes in this release vs 5.5.0?
>>
>> So maybe the release notes should simply say:
>>
>>   Lucene is perfect and has no bugs.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Wed, May 4, 2016 at 1:39 PM, Anshum Gupta 
>> wrote:
>>
>>> Here is a draft of the release notes. Feel free to edit and fix
>>> something that I missed,
>>>
>>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
>>> Solr: https://wiki.apache.org/solr/ReleaseNote551
>>>
>>> On Wed, May 4, 2016 at 12:06 AM, Adrien Grand  wrote:
>>>
 +1 SUCCESS! [0:57:52.080980]

 Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
 écrit :

> FYI, we generally don't consider weekends for the 72 hour window so
> we'd be waiting until Wednesday to close this one out.
> Thought I'd let everyone who's waiting know about this.
>
> On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta 
> wrote:
>
>> Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.
>>
>> Artifacts:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>
>> Smoke tester:
>>
>>   python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>
>>
>> Here's my +1:
>>
>> SUCCESS! [0:26:44.452268]
>>
>> --
>> Anshum Gupta
>>
>
>
>
> --
> Anshum Gupta
>

>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>
>
> --
> Anshum Gupta
>

[jira] [Commented] (SOLR-5750) Backup/Restore API for SolrCloud

[ASF subversion and git services (JIRA)]

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

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

Commit 13832b4f857bc6f726a4764aa446a487b847bfee in lucene-solr's branch 
refs/heads/branch_6x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=13832b4 ]

SOLR-5750: Fix test to specify the collection on commit
(cherry picked from commit 0a20dd4)


> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 6.1
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



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

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

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

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9055:


bq. Yes I think it is possible to use Lucene Directory implementation without 
requiring a different "Repository" interface. Currently we don't have Directory 
implementation available for S3 though. Should we do that?

OK. I will update the patch to use Directory interface (and remove Repository 
interface). But still I would like to understand how should we proceed with 
integration with different file-systems? It occurs to me that the 
"DirectoryFactory" configuration in solrconfig.xml can be exposed at a higher 
level so that it would be useful for both both index management and 
backup/restore. e.g. consider how HDFS configuration is done today,
https://github.com/cloudera/lucene-solr/blob/25d722e35238cca776abbe3a621e0c5b733e762d/cloudera/solrconfig.xml#L119

If this is exposed via a separate "Repository" API, then solrconfig.xml can 
also refer to it via user-configurable "name". (Please note that some care 
needs to be taken to allow "block-cache" to be configured selectively as 
backup/restore solution does not need it). This way users can register multiple 
repositories (e.g. local file-system, HDFS etc.) and choose one of index 
management and other for backup/restore without duplicate configuration (e.g. 
one in solrconfig.xml and other as part of "Repository" API).

It seems like a major change though it is a "correct" solution. So any feedback 
on this would be great.


> 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] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[JIRA]

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

Jan Høydahl commented on SOLR-9053:
---

Sorry, [~mdrob], I intended to credit you but copied the name from issue 
creator. I'll fix it. Also I kept this fix simple, did not commit your Iterator 
-> foreach code refactor.

[~markrmil...@gmail.com], I don't think that a single one of my GIT commits 
have ever been tagged by the tag bot... It does not like me :(

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-8972) Add GraphHandler and GraphMLResponseWriter to support graph visualizations

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8972 at 5/4/16 7:44 PM:
--

Added some error handling to the GraphMLResponseWriter. Now it prints a stack 
trace to the client if it sees a error coming from the GraphHandler. The 
GraphHandler will log the error before passing the error over to the 
GraphResponseWriter.

It's using a DummyErrorStream to wrap the error in a TupleStream. This is to 
keep things consistent with the StreamHandler and also in case future graph 
writers export in a json graph format and can use the DummyErrorStream to send 
a json error to the client.


was (Author: joel.bernstein):
Added some error handling the GraphMLResponseWriter. Now it prints a stack 
trace to the client if it sees a error coming from the GraphHandler. The 
GraphHandler will log the error before passing the error over to the 
GraphResponseWriter.

It's using a DummyErrorStream to wrap the error in a TupleStream. This is to 
keep things consistent with the StreamHandler and also in case future graph 
writers export in a json graph format and can use the DummyErrorStream to send 
a json error to the client.

> Add GraphHandler and GraphMLResponseWriter to support graph visualizations
> --
>
> Key: SOLR-8972
> URL: https://issues.apache.org/jira/browse/SOLR-8972
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: GraphHandler.java, GraphMLResponseWriter.java, 
> SOLR-8972.patch, SOLR-8972.patch, SOLR-8972.patch
>
>
> SOLR-8925 is shaping up nicely. It would be great if Solr could support 
> outputting graphs in GraphML. This will allow users to visualize their graphs 
> in a number of graph visualization tools (NodeXL, Gephi, Tulip etc...). This 
> ticket will create a new Graph handler which will take a Streaming Expression 
> graph traversal and output GraphML. A new GraphMLResponseWriter will handle 
> the GraphML formatting. In future releases we can consider supporting other 
> graph formats.



--
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-8972) Add GraphHandler and GraphMLResponseWriter to support graph visualizations

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-8972 at 5/4/16 7:43 PM:
--

Added some error handling the GraphMLResponseWriter. Now it prints a stack 
trace to the client if it sees a error coming from the GraphHandler. The 
GraphHandler will log the error before passing the error over to the 
GraphResponseWriter.

It's using a DummyErrorStream to wrap the error in a TupleStream. This is to 
keep things consistent with the StreamHandler and also in case future graph 
writers export in a json graph format and can use the DummyErrorStream to send 
a json error to the client.


was (Author: joel.bernstein):
Added some error handling the GraphMLResponseWriter. Now it prints a stack 
trace to the client if it sees a error coming from the GraphHandler. The 
GraphHandler will log the error before passing the error over to the 
GraphResponseWriter.

It's using a DummyErrorStream to wrap the error in a TupleStream. This is to 
keep things consistent with the StreamHandler and also incase future graph 
writers export in a json graph format and can use the DummyErrorStream to send 
a json error to the client.

> Add GraphHandler and GraphMLResponseWriter to support graph visualizations
> --
>
> Key: SOLR-8972
> URL: https://issues.apache.org/jira/browse/SOLR-8972
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: GraphHandler.java, GraphMLResponseWriter.java, 
> SOLR-8972.patch, SOLR-8972.patch, SOLR-8972.patch
>
>
> SOLR-8925 is shaping up nicely. It would be great if Solr could support 
> outputting graphs in GraphML. This will allow users to visualize their graphs 
> in a number of graph visualization tools (NodeXL, Gephi, Tulip etc...). This 
> ticket will create a new Graph handler which will take a Streaming Expression 
> graph traversal and output GraphML. A new GraphMLResponseWriter will handle 
> the GraphML formatting. In future releases we can consider supporting other 
> graph formats.



--
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-8972) Add GraphHandler and GraphMLResponseWriter to support graph visualizations

[Joel Bernstein (JIRA)]

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

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

Added some error handling the GraphMLResponseWriter. Now it prints a stack 
trace to the client if it sees a error coming from the GraphHandler. The 
GraphHandler will log the error before passing the error over to the 
GraphResponseWriter.

It's using a DummyErrorStream to wrap the error in a TupleStream. This is to 
keep things consistent with the StreamHandler and also incase future graph 
writers export in a json graph format and can use the DummyErrorStream to send 
a json error to the client.

> Add GraphHandler and GraphMLResponseWriter to support graph visualizations
> --
>
> Key: SOLR-8972
> URL: https://issues.apache.org/jira/browse/SOLR-8972
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: GraphHandler.java, GraphMLResponseWriter.java, 
> SOLR-8972.patch, SOLR-8972.patch, SOLR-8972.patch
>
>
> SOLR-8925 is shaping up nicely. It would be great if Solr could support 
> outputting graphs in GraphML. This will allow users to visualize their graphs 
> in a number of graph visualization tools (NodeXL, Gephi, Tulip etc...). This 
> ticket will create a new Graph handler which will take a Streaming Expression 
> graph traversal and output GraphML. A new GraphMLResponseWriter will handle 
> the GraphML formatting. In future releases we can consider supporting other 
> graph formats.



--
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-8972) Add GraphHandler and GraphMLResponseWriter to support graph visualizations

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-8972:
--

Pre-commit is passing with the latest patch. I need to do some looking into the 
error handling with this and then I think it's getting pretty close to 
committable.

> Add GraphHandler and GraphMLResponseWriter to support graph visualizations
> --
>
> Key: SOLR-8972
> URL: https://issues.apache.org/jira/browse/SOLR-8972
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: GraphHandler.java, GraphMLResponseWriter.java, 
> SOLR-8972.patch, SOLR-8972.patch
>
>
> SOLR-8925 is shaping up nicely. It would be great if Solr could support 
> outputting graphs in GraphML. This will allow users to visualize their graphs 
> in a number of graph visualization tools (NodeXL, Gephi, Tulip etc...). This 
> ticket will create a new Graph handler which will take a Streaming Expression 
> graph traversal and output GraphML. A new GraphMLResponseWriter will handle 
> the GraphML formatting. In future releases we can consider supporting other 
> graph formats.



--
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: lucene-solr:master: added a couple of extra methods

[Anshum Gupta]

As I understand, Hoss just pointed out that the method that was added
creates confusion in the mind of the users as to why they were added, what
do they do, and how are they different from the previous methods in terms
of usage.
If we have that documented, we'd at least have a clear understanding of
when to use what method. Also, if the thought was that getKey and getValue
don't make sense for Pair, it would have made sense to deprecate them with
documentation instead of having more methods that do the exact same thing.

I don't think there's an argument here, just a mail thread.

On Wed, May 4, 2016 at 12:00 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I think for a "Pair" class, getKey and getValue has no meaning. A pair
> need not be a key/value pair. A key and a value are required for a map
> entry.
> first()/second() or left()/right(), both make sense to me. Perhaps
> removing getKey() and getValue() methods should be removed.
>
> On Thu, May 5, 2016 at 12:18 AM, Chris Hostetter  > wrote:
>
>>
>> : There is no harm in having multiple 'getter' names. getKey() and
>> getValue()
>> : doesn't offer enough explanation  in many cases where it is used
>>
>> getKey and getValue are fundementaly descriptive names -- particularly
>> when they are the only methods in a class named "Pair".
>>
>> As soon as you start adding more methods, with names that are in no way
>> descriptive, *alongs side of* the exsting getKey and getValue methods, you
>> not only add methods that are confusing, but you increase the confusion as
>> to the meanining behind the other names.
>>
>> the fact that these methods do *exactly* the same thing should be a big
>> fucking red flag that people looking at the API (w/o looking at hte
>> implementation) will wonder "what do i use each of these methods for? how
>> is getKey() diff from _1()?"
>>
>> *THAT* is why you need javadocs.
>>
>> If the entirety of the class was...
>>
>> class Pair {
>>   K _1();
>>   V _2();
>> }
>>
>> ...then no one would bat an eye, but as soon as you start adding redundent
>> methods, you raise questions about how they are diff and why they exist.
>>
>> Imagine for a moment that the "Closable" interface looked like this...
>>
>> interface Closable {
>>   void close();
>>   void close_1();
>> }
>>
>>
>> ...wouldn't you wnat some fucking javadocs on those methods so you'd have
>> some clue what the point of them where?
>>
>>
>> :
>> : On Wed, May 4, 2016 at 11:56 PM, Scott Blum 
>> wrote:
>> :
>> : > Or left() and right()
>> : >
>> : > On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
>> : > ichattopadhy...@gmail.com> wrote:
>> : >
>> : >> Another option to consider could be: first() and second()
>> : >>
>> : >> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>> : >>
>> : >> On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
>> wrote:
>> : >>
>> : >>> The names getKey() and getValue() are not always relevant for a pair
>> : >>> object. it's not necessarily a key and value. In that case, it
>> makes sense
>> : >>> to use the index .
>> : >>>
>> : >>>
>> : >>> This is a convention followed Scala. Tuple2 (
>> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>> : >>>
>> : >>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
>> : >>> hossman_luc...@fucit.org> wrote:
>> : >>>
>> : 
>> :  WTF is this?
>> : 
>> :  why are these (poorly named) alternatives for getKey and getValue
>> :  useful?
>> : 
>> : 
>> :  : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>> :  : From: no...@apache.org
>> :  : Reply-To: dev@lucene.apache.org
>> :  : To: comm...@lucene.apache.org
>> :  : Subject: lucene-solr:master: added a couple of extra methods
>> :  :
>> :  : Repository: lucene-solr
>> :  : Updated Branches:
>> :  :   refs/heads/master 0ebe6b0f7 -> 184da9982
>> :  :
>> :  :
>> :  : added a couple of extra methods
>> :  :
>> :  :
>> :  : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> :  : Commit:
>> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>> :  : Tree:
>> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>> :  : Diff:
>> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>> :  :
>> :  : Branch: refs/heads/master
>> :  : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>> :  : Parents: 0ebe6b0
>> :  : Author: Noble Paul 
>> :  : Authored: Tue May 3 20:34:36 2016 +0530
>> :  : Committer: Noble Paul 
>> :  : Committed: Tue May 3 20:34:36 2016 +0530
>> :  :
>> :  :
>> --
>> :  :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
>> :  
>> :  :  1 file changed, 8 insertions(+)
>> :  :
>> 

[jira] [Resolved] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Alan Woodward (JIRA)]

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

Alan Woodward resolved SOLR-9065.
-
Resolution: Fixed

Thanks Hoss

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
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-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9065: Migrate SolrJ tests to SolrCloudTestCase


> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
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 # 155 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, TransactionLog, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper, MDCAwareThreadPoolExecutor]
at __randomizedtesting.SeedInfo.seed([B4924C0CAA9395B2]: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:256)
at sun.reflect.GeneratedMethodAccessor22.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)




Build Log:
[...truncated 11176 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_B4924C0CAA9395B2-001\init-core-data-001
   [junit4]   2> 1072931 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false)
   [junit4]   2> 1072943 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1072944 INFO  (Thread-2880) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1072944 INFO  (Thread-2880) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1073044 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:62969
   [junit4]   2> 1073044 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1073045 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1073049 INFO  (zkCallback-1216-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@1071071 name:ZooKeeperConnection 
Watcher:127.0.0.1:62969 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1073049 INFO  
(SUITE-TestManagedSchemaAPI-seed#[B4924C0CAA9395B2]-worker) [] 
o.

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[ASF subversion and git services (JIRA)]

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

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

Commit 630a8c950d89064b7f2e8dbe865f964a21f9f501 in lucene-solr's branch 
refs/heads/master from [~romseygeek]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=630a8c9 ]

SOLR-9065: Migrate SolrJ tests to SolrCloudTestCase


> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.1, master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
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-8972) Add GraphHandler and GraphMLResponseWriter to support graph visualizations

[Joel Bernstein (JIRA)]

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

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

Added simple test for the GraphHandler

> Add GraphHandler and GraphMLResponseWriter to support graph visualizations
> --
>
> Key: SOLR-8972
> URL: https://issues.apache.org/jira/browse/SOLR-8972
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.1
>
> Attachments: GraphHandler.java, GraphMLResponseWriter.java, 
> SOLR-8972.patch, SOLR-8972.patch
>
>
> SOLR-8925 is shaping up nicely. It would be great if Solr could support 
> outputting graphs in GraphML. This will allow users to visualize their graphs 
> in a number of graph visualization tools (NodeXL, Gephi, Tulip etc...). This 
> ticket will create a new Graph handler which will take a Streaming Expression 
> graph traversal and output GraphML. A new GraphMLResponseWriter will handle 
> the GraphML formatting. In future releases we can consider supporting other 
> graph formats.



--
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: [VOTE] Release Lucene/Solr 5.5.1

[Anshum Gupta]

Mike, there were 3 bug fixes as per the change log. Also, no fixes != no
bugs :).

On Wed, May 4, 2016 at 11:50 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:

> I think there were no Lucene changes in this release vs 5.5.0?
>
> So maybe the release notes should simply say:
>
>   Lucene is perfect and has no bugs.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Wed, May 4, 2016 at 1:39 PM, Anshum Gupta 
> wrote:
>
>> Here is a draft of the release notes. Feel free to edit and fix something
>> that I missed,
>>
>> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
>> Solr: https://wiki.apache.org/solr/ReleaseNote551
>>
>> On Wed, May 4, 2016 at 12:06 AM, Adrien Grand  wrote:
>>
>>> +1 SUCCESS! [0:57:52.080980]
>>>
>>> Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
>>> écrit :
>>>
 FYI, we generally don't consider weekends for the 72 hour window so
 we'd be waiting until Wednesday to close this one out.
 Thought I'd let everyone who's waiting know about this.

 On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta 
 wrote:

> Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.
>
> Artifacts:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>
> Smoke tester:
>
>   python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>
>
> Here's my +1:
>
> SUCCESS! [0:26:44.452268]
>
> --
> Anshum Gupta
>



 --
 Anshum Gupta

>>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>


-- 
Anshum Gupta

Re: lucene-solr:master: added a couple of extra methods

[Ishan Chattopadhyaya]

I think for a "Pair" class, getKey and getValue has no meaning. A pair need
not be a key/value pair. A key and a value are required for a map entry.
first()/second() or left()/right(), both make sense to me. Perhaps removing
getKey() and getValue() methods should be removed.

On Thu, May 5, 2016 at 12:18 AM, Chris Hostetter 
wrote:

>
> : There is no harm in having multiple 'getter' names. getKey() and
> getValue()
> : doesn't offer enough explanation  in many cases where it is used
>
> getKey and getValue are fundementaly descriptive names -- particularly
> when they are the only methods in a class named "Pair".
>
> As soon as you start adding more methods, with names that are in no way
> descriptive, *alongs side of* the exsting getKey and getValue methods, you
> not only add methods that are confusing, but you increase the confusion as
> to the meanining behind the other names.
>
> the fact that these methods do *exactly* the same thing should be a big
> fucking red flag that people looking at the API (w/o looking at hte
> implementation) will wonder "what do i use each of these methods for? how
> is getKey() diff from _1()?"
>
> *THAT* is why you need javadocs.
>
> If the entirety of the class was...
>
> class Pair {
>   K _1();
>   V _2();
> }
>
> ...then no one would bat an eye, but as soon as you start adding redundent
> methods, you raise questions about how they are diff and why they exist.
>
> Imagine for a moment that the "Closable" interface looked like this...
>
> interface Closable {
>   void close();
>   void close_1();
> }
>
>
> ...wouldn't you wnat some fucking javadocs on those methods so you'd have
> some clue what the point of them where?
>
>
> :
> : On Wed, May 4, 2016 at 11:56 PM, Scott Blum 
> wrote:
> :
> : > Or left() and right()
> : >
> : > On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
> : > ichattopadhy...@gmail.com> wrote:
> : >
> : >> Another option to consider could be: first() and second()
> : >>
> : >> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
> : >>
> : >> On Wed, May 4, 2016 at 11:44 PM, Noble Paul 
> wrote:
> : >>
> : >>> The names getKey() and getValue() are not always relevant for a pair
> : >>> object. it's not necessarily a key and value. In that case, it makes
> sense
> : >>> to use the index .
> : >>>
> : >>>
> : >>> This is a convention followed Scala. Tuple2 (
> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
> : >>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
> : >>>
> : >>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
> : >>> hossman_luc...@fucit.org> wrote:
> : >>>
> : 
> :  WTF is this?
> : 
> :  why are these (poorly named) alternatives for getKey and getValue
> :  useful?
> : 
> : 
> :  : Date: Tue,  3 May 2016 15:09:08 + (UTC)
> :  : From: no...@apache.org
> :  : Reply-To: dev@lucene.apache.org
> :  : To: comm...@lucene.apache.org
> :  : Subject: lucene-solr:master: added a couple of extra methods
> :  :
> :  : Repository: lucene-solr
> :  : Updated Branches:
> :  :   refs/heads/master 0ebe6b0f7 -> 184da9982
> :  :
> :  :
> :  : added a couple of extra methods
> :  :
> :  :
> :  : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> :  : Commit:
> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
> :  : Tree:
> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
> :  : Diff:
> :  http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
> :  :
> :  : Branch: refs/heads/master
> :  : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
> :  : Parents: 0ebe6b0
> :  : Author: Noble Paul 
> :  : Authored: Tue May 3 20:34:36 2016 +0530
> :  : Committer: Noble Paul 
> :  : Committed: Tue May 3 20:34:36 2016 +0530
> :  :
> :  :
> --
> :  :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
> :  
> :  :  1 file changed, 8 insertions(+)
> :  :
> --
> :  :
> :  :
> :  :
> : 
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> :  :
> --
> :  : diff --git
> :  a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> :  b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> :  : index 423f94c..f87323c 100644
> :  : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> :  : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> :  : @@ -27,6 +27,14 @@ public class Pair implements
> Serializable {
> :  :
> :  :private V value;
> :  :
> :  : +  public K _1() {
> :  : +return key;
> 

Re: [VOTE] Release Lucene/Solr 5.5.1

[Walter Underwood]

> On May 4, 2016, at 11:50 AM, Michael McCandless  
> wrote:
> 
>   Lucene is perfect and has no bugs.

The correct form of that statement is “the Lucene test suite is inadequate.” :-)

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

Re: [VOTE] Release Lucene/Solr 5.5.1

[Michael McCandless]

I think there were no Lucene changes in this release vs 5.5.0?

So maybe the release notes should simply say:

  Lucene is perfect and has no bugs.

Mike McCandless

http://blog.mikemccandless.com

On Wed, May 4, 2016 at 1:39 PM, Anshum Gupta  wrote:

> Here is a draft of the release notes. Feel free to edit and fix something
> that I missed,
>
> Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
> Solr: https://wiki.apache.org/solr/ReleaseNote551
>
> On Wed, May 4, 2016 at 12:06 AM, Adrien Grand  wrote:
>
>> +1 SUCCESS! [0:57:52.080980]
>>
>> Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
>> écrit :
>>
>>> FYI, we generally don't consider weekends for the 72 hour window so we'd
>>> be waiting until Wednesday to close this one out.
>>> Thought I'd let everyone who's waiting know about this.
>>>
>>> On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta 
>>> wrote:
>>>
 Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.

 Artifacts:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58

 Smoke tester:

   python3 -u dev-tools/scripts/smokeTestRelease.py
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58


 Here's my +1:

 SUCCESS! [0:26:44.452268]

 --
 Anshum Gupta

>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>
>
> --
> Anshum Gupta
>

Re: lucene-solr:master: added a couple of extra methods

[Chris Hostetter]

: There is no harm in having multiple 'getter' names. getKey() and getValue()
: doesn't offer enough explanation  in many cases where it is used

getKey and getValue are fundementaly descriptive names -- particularly 
when they are the only methods in a class named "Pair".

As soon as you start adding more methods, with names that are in no way 
descriptive, *alongs side of* the exsting getKey and getValue methods, you 
not only add methods that are confusing, but you increase the confusion as 
to the meanining behind the other names.

the fact that these methods do *exactly* the same thing should be a big 
fucking red flag that people looking at the API (w/o looking at hte 
implementation) will wonder "what do i use each of these methods for? how 
is getKey() diff from _1()?"

*THAT* is why you need javadocs.

If the entirety of the class was...

class Pair {
  K _1();
  V _2();
}

...then no one would bat an eye, but as soon as you start adding redundent 
methods, you raise questions about how they are diff and why they exist.

Imagine for a moment that the "Closable" interface looked like this...

interface Closable {
  void close();
  void close_1();
}


...wouldn't you wnat some fucking javadocs on those methods so you'd have 
some clue what the point of them where?


: 
: On Wed, May 4, 2016 at 11:56 PM, Scott Blum  wrote:
: 
: > Or left() and right()
: >
: > On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
: > ichattopadhy...@gmail.com> wrote:
: >
: >> Another option to consider could be: first() and second()
: >>
: >> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
: >>
: >> On Wed, May 4, 2016 at 11:44 PM, Noble Paul  wrote:
: >>
: >>> The names getKey() and getValue() are not always relevant for a pair
: >>> object. it's not necessarily a key and value. In that case, it makes sense
: >>> to use the index .
: >>>
: >>>
: >>> This is a convention followed Scala. Tuple2 (
: >>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
: >>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
: >>>
: >>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
: >>> hossman_luc...@fucit.org> wrote:
: >>>
: 
:  WTF is this?
: 
:  why are these (poorly named) alternatives for getKey and getValue
:  useful?
: 
: 
:  : Date: Tue,  3 May 2016 15:09:08 + (UTC)
:  : From: no...@apache.org
:  : Reply-To: dev@lucene.apache.org
:  : To: comm...@lucene.apache.org
:  : Subject: lucene-solr:master: added a couple of extra methods
:  :
:  : Repository: lucene-solr
:  : Updated Branches:
:  :   refs/heads/master 0ebe6b0f7 -> 184da9982
:  :
:  :
:  : added a couple of extra methods
:  :
:  :
:  : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
:  : Commit:
:  http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
:  : Tree:
:  http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
:  : Diff:
:  http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
:  :
:  : Branch: refs/heads/master
:  : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
:  : Parents: 0ebe6b0
:  : Author: Noble Paul 
:  : Authored: Tue May 3 20:34:36 2016 +0530
:  : Committer: Noble Paul 
:  : Committed: Tue May 3 20:34:36 2016 +0530
:  :
:  : --
:  :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
:  
:  :  1 file changed, 8 insertions(+)
:  : --
:  :
:  :
:  :
:  
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
:  : --
:  : diff --git
:  a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
:  b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
:  : index 423f94c..f87323c 100644
:  : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
:  : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
:  : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
:  :
:  :private V value;
:  :
:  : +  public K _1() {
:  : +return key;
:  : +  }
:  : +
:  : +  public V _2() {
:  : +return value;
:  : +  }
:  : +
:  :public V getValue() {
:  :  return value;
:  :}
:  :
:  :
: 
:  -Hoss
:  http://www.lucidworks.com/
: 
:  -
:  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
:  For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 
: >>>
: >>>
: >>> --
: >>> -
: >>> Noble Paul

[jira] [Commented] (SOLR-5750) Backup/Restore API for SolrCloud

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-5750:


Thanks for reporting; I'll dig.

> Backup/Restore API for SolrCloud
> 
>
> Key: SOLR-5750
> URL: https://issues.apache.org/jira/browse/SOLR-5750
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Varun Thacker
> Fix For: 6.1
>
> Attachments: SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, 
> SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch, SOLR-5750.patch
>
>
> We should have an easy way to do backups and restores in SolrCloud. The 
> ReplicationHandler supports a backup command which can create snapshots of 
> the index but that is too little.
> The command should be able to backup:
> # Snapshots of all indexes or indexes from the leader or the shards
> # Config set
> # Cluster state
> # Cluster properties
> # Aliases
> # Overseer work queue?
> A restore should be able to completely restore the cloud i.e. no manual steps 
> required other than bringing nodes back up or setting up a new cloud cluster.
> SOLR-5340 will be a part of this issue.



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

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

[jira] [Commented] (SOLR-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9069:


That sounds great actually.  I temporarily forgot about that beauty because I 
was fixated on one improving one of our existing tests that descend from 
AbstractFullDistribZkTestBase.

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



--
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-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9069:


Some other confusion is that some fields/methods are only intended for use with 
the default collection (which can be configured).  Like sliceCount -- doesn't 
apply to tests that create their own collections using whatever settings they 
please.

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



--
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-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-9069:
-

My suggestion: nuke BaseDistributedSearchTestCase entirely and migrate 
everything to SolrCloudTestCase.  I'm going to be working on that this week...

> Cleanup/rename confusion of shardCount in tests actually being serverCount
> --
>
> Key: SOLR-9069
> URL: https://issues.apache.org/jira/browse/SOLR-9069
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: David Smiley
>
> BaseDistributedSearchTestCase has a shardCount field, which can be set 
> directly or via the {{\@ShardsFixed}} annotation.  For some (esp. older) 
> tests, this is in fact the number of "shards" (disjoint slices of your 
> overall data), but it's also the number of Solr/Jetty servers/nodes.  
> Subclasses like AbstractFullDistribZkTestBase define sliceCount, adding to 
> the confusion, and define however many shards (slices) they want -- 
> separately from the number of servers (which is configured confusingly, as 
> stated, via ShardsFixed).  This is confusing!  I'm not 100% sure what the 
> solution is, I'll suggest some ideas, but we should discuss.
> Of course we got to this situation historically before SolrCloud existed; no 
> excuses needed.  Now we should fix it.



--
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: lucene-solr:master: added a couple of extra methods

[Noble Paul]

There is no harm in having multiple 'getter' names. getKey() and getValue()
doesn't offer enough explanation  in many cases where it is used

On Wed, May 4, 2016 at 11:56 PM, Scott Blum  wrote:

> Or left() and right()
>
> On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Another option to consider could be: first() and second()
>>
>> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>>
>> On Wed, May 4, 2016 at 11:44 PM, Noble Paul  wrote:
>>
>>> The names getKey() and getValue() are not always relevant for a pair
>>> object. it's not necessarily a key and value. In that case, it makes sense
>>> to use the index .
>>>
>>>
>>> This is a convention followed Scala. Tuple2 (
>>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>>>
>>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter <
>>> hossman_luc...@fucit.org> wrote:
>>>

 WTF is this?

 why are these (poorly named) alternatives for getKey and getValue
 useful?


 : Date: Tue,  3 May 2016 15:09:08 + (UTC)
 : From: no...@apache.org
 : Reply-To: dev@lucene.apache.org
 : To: comm...@lucene.apache.org
 : Subject: lucene-solr:master: added a couple of extra methods
 :
 : Repository: lucene-solr
 : Updated Branches:
 :   refs/heads/master 0ebe6b0f7 -> 184da9982
 :
 :
 : added a couple of extra methods
 :
 :
 : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
 : Commit:
 http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
 : Tree:
 http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
 : Diff:
 http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
 :
 : Branch: refs/heads/master
 : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
 : Parents: 0ebe6b0
 : Author: Noble Paul 
 : Authored: Tue May 3 20:34:36 2016 +0530
 : Committer: Noble Paul 
 : Committed: Tue May 3 20:34:36 2016 +0530
 :
 : --
 :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8
 
 :  1 file changed, 8 insertions(+)
 : --
 :
 :
 :
 http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
 : --
 : diff --git
 a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
 b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
 : index 423f94c..f87323c 100644
 : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
 : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
 : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
 :
 :private V value;
 :
 : +  public K _1() {
 : +return key;
 : +  }
 : +
 : +  public V _2() {
 : +return value;
 : +  }
 : +
 :public V getValue() {
 :  return value;
 :}
 :
 :

 -Hoss
 http://www.lucidworks.com/

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


>>>
>>>
>>> --
>>> -
>>> Noble Paul
>>>
>>
>>
>


-- 
-
Noble Paul

Re: lucene-solr:master: added a couple of extra methods

[Chris Hostetter]

Or maybe methodWithFuckingJavadocsExplainingItsExistence() and 
otherMethodWIthJavadocsSoUsersDontHaveToGuessIfThereIsADiffBetweenGetKeyAnd_1()

how do those method names sound?


: Date: Wed, 4 May 2016 14:26:41 -0400
: From: Scott Blum 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Re: lucene-solr:master: added a couple of extra methods
: 
: Or left() and right()
: 
: On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
: ichattopadhy...@gmail.com> wrote:
: 
: > Another option to consider could be: first() and second()
: >
: > C++ uses it: http://www.cplusplus.com/reference/utility/pair/
: >
: > On Wed, May 4, 2016 at 11:44 PM, Noble Paul  wrote:
: >
: >> The names getKey() and getValue() are not always relevant for a pair
: >> object. it's not necessarily a key and value. In that case, it makes sense
: >> to use the index .
: >>
: >>
: >> This is a convention followed Scala. Tuple2 (
: >> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
: >> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
: >>
: >> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter > > wrote:
: >>
: >>>
: >>> WTF is this?
: >>>
: >>> why are these (poorly named) alternatives for getKey and getValue useful?
: >>>
: >>>
: >>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
: >>> : From: no...@apache.org
: >>> : Reply-To: dev@lucene.apache.org
: >>> : To: comm...@lucene.apache.org
: >>> : Subject: lucene-solr:master: added a couple of extra methods
: >>> :
: >>> : Repository: lucene-solr
: >>> : Updated Branches:
: >>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
: >>> :
: >>> :
: >>> : added a couple of extra methods
: >>> :
: >>> :
: >>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
: >>> : Commit:
: >>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
: >>> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
: >>> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
: >>> :
: >>> : Branch: refs/heads/master
: >>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
: >>> : Parents: 0ebe6b0
: >>> : Author: Noble Paul 
: >>> : Authored: Tue May 3 20:34:36 2016 +0530
: >>> : Committer: Noble Paul 
: >>> : Committed: Tue May 3 20:34:36 2016 +0530
: >>> :
: >>> : --
: >>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8 
: >>> :  1 file changed, 8 insertions(+)
: >>> : --
: >>> :
: >>> :
: >>> :
: >>> 
http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
: >>> : --
: >>> : diff --git a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
: >>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
: >>> : index 423f94c..f87323c 100644
: >>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
: >>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
: >>> : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
: >>> :
: >>> :private V value;
: >>> :
: >>> : +  public K _1() {
: >>> : +return key;
: >>> : +  }
: >>> : +
: >>> : +  public V _2() {
: >>> : +return value;
: >>> : +  }
: >>> : +
: >>> :public V getValue() {
: >>> :  return value;
: >>> :}
: >>> :
: >>> :
: >>>
: >>> -Hoss
: >>> http://www.lucidworks.com/
: >>>
: >>> -
: >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: >>> For additional commands, e-mail: dev-h...@lucene.apache.org
: >>>
: >>>
: >>
: >>
: >> --
: >> -
: >> Noble Paul
: >>
: >
: >
: 

-Hoss
http://www.lucidworks.com/

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

Re: lucene-solr:master: added a couple of extra methods

[Scott Blum]

Or left() and right()

On Wed, May 4, 2016 at 2:18 PM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Another option to consider could be: first() and second()
>
> C++ uses it: http://www.cplusplus.com/reference/utility/pair/
>
> On Wed, May 4, 2016 at 11:44 PM, Noble Paul  wrote:
>
>> The names getKey() and getValue() are not always relevant for a pair
>> object. it's not necessarily a key and value. In that case, it makes sense
>> to use the index .
>>
>>
>> This is a convention followed Scala. Tuple2 (
>> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
>> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>>
>> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter > > wrote:
>>
>>>
>>> WTF is this?
>>>
>>> why are these (poorly named) alternatives for getKey and getValue useful?
>>>
>>>
>>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>>> : From: no...@apache.org
>>> : Reply-To: dev@lucene.apache.org
>>> : To: comm...@lucene.apache.org
>>> : Subject: lucene-solr:master: added a couple of extra methods
>>> :
>>> : Repository: lucene-solr
>>> : Updated Branches:
>>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>>> :
>>> :
>>> : added a couple of extra methods
>>> :
>>> :
>>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>>> : Commit:
>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>>> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>>> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>>> :
>>> : Branch: refs/heads/master
>>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>>> : Parents: 0ebe6b0
>>> : Author: Noble Paul 
>>> : Authored: Tue May 3 20:34:36 2016 +0530
>>> : Committer: Noble Paul 
>>> : Committed: Tue May 3 20:34:36 2016 +0530
>>> :
>>> : --
>>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8 
>>> :  1 file changed, 8 insertions(+)
>>> : --
>>> :
>>> :
>>> :
>>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : --
>>> : diff --git a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : index 423f94c..f87323c 100644
>>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>>> : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
>>> :
>>> :private V value;
>>> :
>>> : +  public K _1() {
>>> : +return key;
>>> : +  }
>>> : +
>>> : +  public V _2() {
>>> : +return value;
>>> : +  }
>>> : +
>>> :public V getValue() {
>>> :  return value;
>>> :}
>>> :
>>> :
>>>
>>> -Hoss
>>> http://www.lucidworks.com/
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>
>

[jira] [Created] (SOLR-9069) Cleanup/rename confusion of shardCount in tests actually being serverCount

[David Smiley (JIRA)]

David Smiley created SOLR-9069:
--

 Summary: Cleanup/rename confusion of shardCount in tests actually 
being serverCount
 Key: SOLR-9069
 URL: https://issues.apache.org/jira/browse/SOLR-9069
 Project: Solr
  Issue Type: Test
  Components: Tests
Reporter: David Smiley


BaseDistributedSearchTestCase has a shardCount field, which can be set directly 
or via the {{\@ShardsFixed}} annotation.  For some (esp. older) tests, this is 
in fact the number of "shards" (disjoint slices of your overall data), but it's 
also the number of Solr/Jetty servers/nodes.  Subclasses like 
AbstractFullDistribZkTestBase define sliceCount, adding to the confusion, and 
define however many shards (slices) they want -- separately from the number of 
servers (which is configured confusingly, as stated, via ShardsFixed).  This is 
confusing!  I'm not 100% sure what the solution is, I'll suggest some ideas, 
but we should discuss.

Of course we got to this situation historically before SolrCloud existed; no 
excuses needed.  Now we should fix it.



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

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

Re: [JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 110 - Still Failing!

[Chris Hostetter]

Interesting SSL failures coming solely from Solaris since adding 
NullSecureRandom to our SSL tests, tracking here...

https://issues.apache.org/jira/browse/SOLR-9068



: Date: Wed, 4 May 2016 08:20:59 + (UTC)
: From: Policeman Jenkins Server 
: To: sar...@gmail.com, jpou...@gmail.com, daddy...@gmail.com,
: hoss...@apache.org, dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 110 -
: Still Failing!
: 
: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/110/
: Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
: 
: 1 tests failed.
: FAILED:  
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth
: 
: Error Message:
: Could not find collection:second_collection
: 
: Stack Trace:
: java.lang.AssertionError: Could not find collection:second_collection
:   at 
__randomizedtesting.SeedInfo.seed([6015035BB56AE7B1:9CAFD76F4D4A567B]:0)
:   at org.junit.Assert.fail(Assert.java:93)
:   at org.junit.Assert.assertTrue(Assert.java:43)
:   at org.junit.Assert.assertNotNull(Assert.java:526)
:   at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:150)
:   at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkCreateCollection(TestMiniSolrCloudClusterSSL.java:215)
:   at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithCollectionCreations(TestMiniSolrCloudClusterSSL.java:200)
:   at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.checkClusterWithNodeReplacement(TestMiniSolrCloudClusterSSL.java:148)
:   at 
org.apache.solr.cloud.TestMiniSolrCloudClusterSSL.testSslAndNoClientAuth(TestMiniSolrCloudClusterSSL.java:120)
:   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 
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(State

[jira] [Updated] (SOLR-9068) Solaris SSL test failures when using NullSecureRandom?

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-9068:
---
Attachment: SOLR-9068.Lucene-Solr-master-Solaris_558.log
SOLR-9068.Lucene-Solr-6.x-Solaris_110.log

Attaching Jenkins failure logs...

http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/558/consoleText
http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/110/consoleText

Interesting bits...

{noformat}
   [junit4]   2> 1664862 ERROR 
(OverseerThreadFactory-5652-thread-2-processing-n:127.0.0.1:55264_solr) 
[n:127.0.0.1:55264_solr] o.a.s.c.OverseerCollectionMessageHandler Error 
from shard: https://127.0.0.1:55219/solr
   [junit4]   2> org.apache.solr.client.solrj.SolrServerException: IOException 
occured when talking to server at: https://127.0.0.1:55219/solr
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:259)
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:248)
   [junit4]   2>at 
org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
   [junit4]   2>at 
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:195)
   [junit4]   2>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]   2>at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
   [junit4]   2>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]   2>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
   [junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]   2>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]   2>at java.lang.Thread.run(Thread.java:745)
   [junit4]   2> Caused by: javax.net.ssl.SSLHandshakeException: Invalid TLS 
padding data
   [junit4]   2>at 
sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1020)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
   [junit4]   2>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
   [junit4]   2>at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
   [junit4]   2>at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
   [junit4]   2>at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
   [junit4]   2>at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
   [junit4]   2>at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
   [junit4]   2>at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
   [junit4]   2>at 
org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
   [junit4]   2>at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
   [junit4]   2>at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
   [junit4]   2>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
   [junit4]   2>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
   [junit4]   2>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:511)
   [junit4]   2>... 11 more
   [junit4]   2> Caused by: javax.crypto.BadPaddingException: Invalid TLS 
padding data
   [junit4]   2>at 
sun.security.ssl.CipherBox.removePadding(CipherBox.java:751)
   [junit4]   2>at 
sun.security.ssl.CipherBox.decrypt(CipherBox.java:491)
   [junit4]   2>at 
sun.security.ssl.InputRecord.decrypt(InputRecord.java:172)
   [junit4]   2>at 
sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1015)
   [junit4]   2>... 27 more
{noformat}

And...

{noformat}
   [junit4]   2> 1655925 ERROR 
(OverseerThreadFactory-3737-thread-2-processing-n:127.0.0.1:34220_solr) 
[n:127.0.0.1:34220_solr

Re: lucene-solr:master: added a couple of extra methods

[Ishan Chattopadhyaya]

Another option to consider could be: first() and second()

C++ uses it: http://www.cplusplus.com/reference/utility/pair/

On Wed, May 4, 2016 at 11:44 PM, Noble Paul  wrote:

> The names getKey() and getValue() are not always relevant for a pair
> object. it's not necessarily a key and value. In that case, it makes sense
> to use the index .
>
>
> This is a convention followed Scala. Tuple2 (
> http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
> http://www.scala-lang.org/api/rc2/scala/Tuple10.html)
>
> On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter 
> wrote:
>
>>
>> WTF is this?
>>
>> why are these (poorly named) alternatives for getKey and getValue useful?
>>
>>
>> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
>> : From: no...@apache.org
>> : Reply-To: dev@lucene.apache.org
>> : To: comm...@lucene.apache.org
>> : Subject: lucene-solr:master: added a couple of extra methods
>> :
>> : Repository: lucene-solr
>> : Updated Branches:
>> :   refs/heads/master 0ebe6b0f7 -> 184da9982
>> :
>> :
>> : added a couple of extra methods
>> :
>> :
>> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> : Commit:
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
>> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
>> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
>> :
>> : Branch: refs/heads/master
>> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
>> : Parents: 0ebe6b0
>> : Author: Noble Paul 
>> : Authored: Tue May 3 20:34:36 2016 +0530
>> : Committer: Noble Paul 
>> : Committed: Tue May 3 20:34:36 2016 +0530
>> :
>> : --
>> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8 
>> :  1 file changed, 8 insertions(+)
>> : --
>> :
>> :
>> :
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : --
>> : diff --git a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : index 423f94c..f87323c 100644
>> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
>> : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
>> :
>> :private V value;
>> :
>> : +  public K _1() {
>> : +return key;
>> : +  }
>> : +
>> : +  public V _2() {
>> : +return value;
>> : +  }
>> : +
>> :public V getValue() {
>> :  return value;
>> :}
>> :
>> :
>>
>> -Hoss
>> http://www.lucidworks.com/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> -
> Noble Paul
>

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

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5776:


Note: create a subtask to look into some (apparently solarais specific) 
failures since NullSecureRandom was committed: SOLR-9068

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

[Hoss Man (JIRA)]

Hoss Man created SOLR-9068:
--

 Summary: 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


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

Re: lucene-solr:master: added a couple of extra methods

[Noble Paul]

The names getKey() and getValue() are not always relevant for a pair
object. it's not necessarily a key and value. In that case, it makes sense
to use the index .


This is a convention followed Scala. Tuple2 (
http://www.scala-lang.org/api/rc2/scala/Tuple2.html ) to Tuple10 (
http://www.scala-lang.org/api/rc2/scala/Tuple10.html)

On Wed, May 4, 2016 at 4:32 AM, Chris Hostetter 
wrote:

>
> WTF is this?
>
> why are these (poorly named) alternatives for getKey and getValue useful?
>
>
> : Date: Tue,  3 May 2016 15:09:08 + (UTC)
> : From: no...@apache.org
> : Reply-To: dev@lucene.apache.org
> : To: comm...@lucene.apache.org
> : Subject: lucene-solr:master: added a couple of extra methods
> :
> : Repository: lucene-solr
> : Updated Branches:
> :   refs/heads/master 0ebe6b0f7 -> 184da9982
> :
> :
> : added a couple of extra methods
> :
> :
> : Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> : Commit:
> http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/184da998
> : Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/184da998
> : Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/184da998
> :
> : Branch: refs/heads/master
> : Commit: 184da9982c55fac4735abf01607e4f8f70eb5749
> : Parents: 0ebe6b0
> : Author: Noble Paul 
> : Authored: Tue May 3 20:34:36 2016 +0530
> : Committer: Noble Paul 
> : Committed: Tue May 3 20:34:36 2016 +0530
> :
> : --
> :  solr/solrj/src/java/org/apache/solr/common/util/Pair.java | 8 
> :  1 file changed, 8 insertions(+)
> : --
> :
> :
> :
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/184da998/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : --
> : diff --git a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : index 423f94c..f87323c 100644
> : --- a/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : +++ b/solr/solrj/src/java/org/apache/solr/common/util/Pair.java
> : @@ -27,6 +27,14 @@ public class Pair implements Serializable {
> :
> :private V value;
> :
> : +  public K _1() {
> : +return key;
> : +  }
> : +
> : +  public V _2() {
> : +return value;
> : +  }
> : +
> :public V getValue() {
> :  return value;
> :}
> :
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
-
Noble Paul

[jira] [Commented] (SOLR-9053) Upgrade fileupload-commons to 1.3.1

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9053:
---

bq. * SOLR-9053: Upgrade commons-fileupload to 1.3.1, fixing a potential 
vulnerability (Jeff Field, janhoy)

[~janhoy], you forgot to give Mike Drob credit in CHANGES for this. Jeff Field 
filed the issue, but Mike Drob wrote the patch.

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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-9053) Upgrade fileupload-commons to 1.3.1

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9053:
---

Hmm...I wonder why this was not commit tagged.

> Upgrade fileupload-commons to 1.3.1
> ---
>
> Key: SOLR-9053
> URL: https://issues.apache.org/jira/browse/SOLR-9053
> Project: Solr
>  Issue Type: Improvement
>  Components: security
>Affects Versions: 4.6, 5.5, master
>Reporter: Jeff Field
>Assignee: Jan Høydahl
>  Labels: commons-file-upload
> Fix For: 6.1
>
> Attachments: SOLR-9053.patch
>
>
> The project appears to pull in FileUpload 1.2.1. According to CVE-2014-0050:
> "MultipartStream.java in Apache Commons FileUpload before 1.3.1, as used in 
> Apache Tomcat, JBoss Web, and other products, allows remote attackers to 
> cause a denial of service (infinite loop and CPU consumption) via a crafted 
> Content-Type header that bypasses a loop's intended exit conditions."
> [Source|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0050]



--
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: [VOTE] Release Lucene/Solr 5.5.1

[Anshum Gupta]

Here is a draft of the release notes. Feel free to edit and fix something
that I missed,

Lucene: https://wiki.apache.org/lucene-java/ReleaseNote551
Solr: https://wiki.apache.org/solr/ReleaseNote551

On Wed, May 4, 2016 at 12:06 AM, Adrien Grand  wrote:

> +1 SUCCESS! [0:57:52.080980]
>
> Le mar. 3 mai 2016 à 19:36, Anshum Gupta  a
> écrit :
>
>> FYI, we generally don't consider weekends for the 72 hour window so we'd
>> be waiting until Wednesday to close this one out.
>> Thought I'd let everyone who's waiting know about this.
>>
>> On Sat, Apr 30, 2016 at 2:25 PM, Anshum Gupta 
>> wrote:
>>
>>> Please vote for the RC1 release candidate for Lucene/Solr 5.5.1.
>>>
>>> Artifacts:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>>
>>> Smoke tester:
>>>
>>>   python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.1-RC1-revc08f17bca0d9cbf516874d13d221ab100e5b7d58
>>>
>>>
>>> Here's my +1:
>>>
>>> SUCCESS! [0:26:44.452268]
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
>


-- 
Anshum Gupta

[jira] [Commented] (SOLR-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9014:
---

bq. bootstrapping mode may need to go away,

Ideally, stateFormat=1, bootstrapping, predefined cores, legacyCloudMode would 
have all gone away completely in 6x.

Tests have been what makes it sticky to do though. Hopefully we can do it for 
7x.

> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-8323) Add CollectionWatcher API to ZkStateReader

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-8323:
--

Github user romseygeek commented on the pull request:

https://github.com/apache/lucene-solr/pull/32#issuecomment-216941787
  
Last push exposes CollectionStateWatcher directly again, and moves 
notification calls into an Executor.


> Add CollectionWatcher API to ZkStateReader
> --
>
> Key: SOLR-8323
> URL: https://issues.apache.org/jira/browse/SOLR-8323
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-8323.patch, SOLR-8323.patch, SOLR-8323.patch, 
> SOLR-8323.patch
>
>
> An API to watch for changes to collection state would be a generally useful 
> thing, both internally and for client use.



--
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: SOLR-8323

[romseygeek]

Github user romseygeek commented on the pull request:

https://github.com/apache/lucene-solr/pull/32#issuecomment-216941787
  
Last push exposes CollectionStateWatcher directly again, and moves 
notification calls into an Executor.


---
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-9014) Deprecate and reduce usage of ClusterState methods which may make calls to ZK via the lazy collection reference

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9014:
---

You have bootstrapping because SolrCloud did not even have a Collections API in 
4.0.

> Deprecate and reduce usage of ClusterState methods which may make calls to ZK 
> via the lazy collection reference
> ---
>
> Key: SOLR-9014
> URL: https://issues.apache.org/jira/browse/SOLR-9014
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
> Fix For: 6.1, master
>
> Attachments: SOLR-9014.patch
>
>
> ClusterState has a bunch of methods such as getSlice and getReplica which 
> internally call getCollectionOrNull that ends up making a call to ZK via the 
> lazy collection reference. Many classes use these methods even though a 
> DocCollection object is available. In such cases, multiple redundant calls to 
> ZooKeeper can happen if the collection is not watched locally. This is 
> especially true for Overseer classes which operate on all collections.
> We should audit all usages of these methods and replace them with calls to 
> appropriate DocCollection methods.



--
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-9067) solrj CloudSolrClient's updatesToLeaders flag is never used

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-9067:
---

This is discussed in SOLR-6312.

> solrj CloudSolrClient's updatesToLeaders flag is never used
> ---
>
> Key: SOLR-9067
> URL: https://issues.apache.org/jira/browse/SOLR-9067
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>
> [CloudSolrClient.java|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java]
>  has an {{updatesToLeaders}} boolean flag that is never actually used.
> Options:
> #1 Consider this a bug and put the flag to use, changing existing behaviour. 
> Could behaviour be changed on branch_6x and branch_5x or only in master?
> #2 Consider this (intended or unintended) existing behaviour, deprecate the 
> flag and add a new similar flag ({{updatesToLeadersOnly}}?) with the default 
> value of the new flag preserving existing behaviour.
> #3 



--
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-9067) solrj CloudSolrClient's updatesToLeaders flag is never used

[Christine Poerschke (JIRA)]

Christine Poerschke created SOLR-9067:
-

 Summary: solrj CloudSolrClient's updatesToLeaders flag is never 
used
 Key: SOLR-9067
 URL: https://issues.apache.org/jira/browse/SOLR-9067
 Project: Solr
  Issue Type: Task
Reporter: Christine Poerschke
Assignee: Christine Poerschke


[CloudSolrClient.java|https://github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/client/solrj/impl/CloudSolrClient.java]
 has an {{updatesToLeaders}} boolean flag that is never actually used.

Options:

#1 Consider this a bug and put the flag to use, changing existing behaviour. 
Could behaviour be changed on branch_6x and branch_5x or only in master?

#2 Consider this (intended or unintended) existing behaviour, deprecate the 
flag and add a new similar flag ({{updatesToLeadersOnly}}?) with the default 
value of the new flag preserving existing behaviour.

#3 



--
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