[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_121) - Build # 19509 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19509/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
This doc was supposed to have been deleted, but was: SolrDocument{id=1, 
inplace_updatable_float=2.0, _version_=1565984547784359936, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0}

Stack Trace:
java.lang.AssertionError: This doc was supposed to have been deleted, but was: 
SolrDocument{id=1, inplace_updatable_float=2.0, _version_=1565984547784359936, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0}
at 
__randomizedtesting.SeedInfo.seed([7172EB767F334941:F926D4ACD1CF24B9]: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.update.TestInPlaceUpdatesDistrib.delayedReorderingFetchesMissingUpdateFromLeaderTest(TestInPlaceUpdatesDistrib.java:951)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
   

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 861 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/861/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestBagOfPostings

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001\bagofpostings-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001\bagofpostings-001

C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001\bagofpostings-001:
 java.nio.file.AccessDeniedException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001\bagofpostings-001
   
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build\core\test\J0\temp\lucene.index.TestBagOfPostings_184350056BC96B4B-001

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


FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"https://127.0.0.1:50221/solr;,   
"node_name":"127.0.0.1:50221_solr",   "state":"active",   
"leader":"true"}, "core_node2":{   
"core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"https://127.0.0.1:50226/solr;,   
"node_name":"127.0.0.1:50226_solr",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/7)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"https://127.0.0.1:50221/solr;,
  "node_name":"127.0.0.1:50221_solr",
  "state":"active",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"https://127.0.0.1:50226/solr;,
  "node_name":"127.0.0.1:50226_solr",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([B0A675409B087673:E0F3ED43C229C06E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 

[jira] [Commented] (SOLR-10583) Add 'join' as a new type of domain change in JSON Facets

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10583:
-

bq. get to the bottom of the cache issue 

I tracked this down to LUCENE-7810.

As i noted in that issue...


# At present, due to some code I don't really understand in how Solr only 
leverages JoinUtils in _rewritten_ queries, it appears that this bug does not 
impact current Solr usecases.  ...
# i discovered this bug purely by fluke because in my originally POC code for 
SOLR-10583 I used {{JoinUtils.createJoinQuery(...)}} directly instead of 
refactoring Solr's {{JoinQParserPlugin}} code so i could re-use it -- doing 
that refactoring is my nextstep for that issue ...

...so once i refactor this patch to use the existing code in JoinQParser, this 
bug shouldn't impact this patch (fingers crossed)



> Add 'join' as a new type of domain change in JSON Facets
> 
>
> Key: SOLR-10583
> URL: https://issues.apache.org/jira/browse/SOLR-10583
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10583.patch
>
>
> Add support for a new (query) {{join}} option when specifying a {{domain}} 
> for a JSON Facet.
> Suggested syntax...
> {code}
> ...
> domain : { join : { from : field_foo,
> to : field_bar
> }
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7810) false equals() result for distinctly diff join queries

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7810:
-
Attachment: LUCENE-7810.patch


The attached patch includes a trivial test case demonstraing the bug I found -- 
but this only executes one code path of {{JoinUtils.createJoinQuery(...)}} -- 
there are almost certainly other code paths with similar bugs that should also 
be tested. (see nocommit comments in test)

A few NOTEs:

# At present, due to some code I don't really understand in how Solr only 
leverages JoinUtils in _rewritten_ queries, it appears that this bug does not 
impact current Solr usecases.  The patch also includes a trivial test showing 
that the "wrapper" queries solr creates around {{JoinUtils}} don't have this 
same equality problem
# i discovered this bug purely by fluke because in my originally POC code for 
SOLR-10583 I used {{JoinUtils.createJoinQuery(...)}} directly instead of 
refactoring Solr's {{JoinQParserPlugin}} code so i could re-use it -- doing 
that refactoring is my nextstep for that issue, so I won't personally be 
pursuing fixing this bug (particularly since i'm not really sure what a good 
fix should look like)



> false equals() result for distinctly diff join queries
> --
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Attachments: LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7810) false equals() result for distinctly diff join queries

[Hoss Man (JIRA)]

Hoss Man created LUCENE-7810:


 Summary: false equals() result for distinctly diff join queries
 Key: LUCENE-7810
 URL: https://issues.apache.org/jira/browse/LUCENE-7810
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Hoss Man



While working on SOLR-10583 I was getting some odd test failures that seemed to 
suggest we were getting false cache hits for Join queries that should have been 
unique.

tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used to 
identify set of documents we "join from") and uses it in the equals calculation 
-- but the information about the join _field_ is never passed directly to 
{{TermsQuery}} and the BytesRefs that are passed in can't be compared 
efficiently (AFAICT), so 2 completely diff calls to 
{{JoinUtils.createJoinQuery(...)}} can result in Query objects that think they 
are {{equal()}} even when they most certainly are not.

At a brief glance, it appears that similar bugs exist in 
{{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
but i didn't look into that class at all)




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10559) Add let and get Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10559:


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

SOLR-10559: Updates TupStream and enhances evaluators to work over values in 
the SteamContext


> Add let and get Streaming Expressions
> -
>
> Key: SOLR-10559
> URL: https://issues.apache.org/jira/browse/SOLR-10559
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10559.patch, SOLR-10559.patch, SOLR-10559.patch, 
> SOLR-10559.patch
>
>
> The *let* and *get* Streaming Expressions allows the tuples in a stream to be 
> assigned to a variable so it can be used more then once during an expression.
> This builds on the *list* and *cell* expressions (SOLR-10551) 
> Here is the sample syntax:
> {code}
> let(cell(a, expr), 
> cell(b, expr), 
> list(cell(a, get(a)),
>  cell(b, get(b)),
>  cell(correlation, correlate(get(a), fielda, get(b), fieldb)))
> {code}
> In the example above the *let* expression is saving the contents of two 
> *cell* expressions (a, b). The *get* expression is retrieving the tuples and 
> using them later in the expression.
> So for example two facet expressions could be stored in the *let*, and then 
> displayed and correlated later in the expression.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-8440 at 4/29/17 1:12 AM:
-

WIP patch.

# Introduces the "auth" command, e.g. {{bin/solr auth -enable -type basic 
-adminuser solr -adminpassword SolrRocks}}
# Support for optional blocksUnknown (false by default)
# -TODO: Put the hash of the password. Currently hardcoded to hash of 
"SolrRocks"-
# -TODO: Introduce a separate file and put the admin username/password there 
for use by the script. If user wants, the bin/solr.in.sh can be used to 
override this user/pw.- Added auth.overlay.sh file, which is applied after 
solr.in.sh has been applied. This file is created during -enable, and deleted 
during -disable.
# TODO: Do pre-checks before enabling; don't do anything if already enabled.
# Uploads the following security.json by default (apart from the user/password 
hash variant.
# TODO: Windows script (bin/solr.cmd)

{code}
{
  "authentication":{
   "blockUnknown": $blockUnknown
   "class":"solr.BasicAuthPlugin",
   "credentials":{$user:$saltedhash_of_password}
  },
  "authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[
{"name":"security-edit", "role":"admin"},
{"name":"collection-admin-edit", "role":"admin"},
{"name":"core-admin-edit", "role":"admin"}
   ],
   "user-role":{"$user":"admin"}
  }
}
{code}

With just this in place (after fixing TODOs and nocommits), one can enable 
basicauth with typical authz configuration. After this, the user can use the 
REST API for authc/authz, or we can build further support for adding users, 
roles etc. to the script.


was (Author: ichattopadhyaya):
WIP patch.

# Introduces the "auth" command, e.g. {{bin/solr auth -enable -type basic 
-adminuser solr -adminpassword SolrRocks}}
# Support for optional blocksUnknown (false by default)
# TODO: Put the hash of the password. Currently hardcoded to hash of "SolrRocks"
# TODO: Introduce a separate file and put the admin username/password there for 
use by the script. If user wants, the bin/solr.in.sh can be used to override 
this user/pw.
# TODO: Do pre-checks before enabling; don't do anything if already enabled.
# Uploads the following security.json by default (apart from the user/password 
hash variant.

{code}
{
  "authentication":{
   "blockUnknown": $blockUnknown
   "class":"solr.BasicAuthPlugin",
   "credentials":{"$user":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
  },
  "authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[
{"name":"security-edit", "role":"admin"},
{"name":"collection-admin-edit", "role":"admin"},
{"name":"core-admin-edit", "role":"admin"}
   ],
   "user-role":{"$user":"admin"}
  }
}
{code}

With just this in place (after fixing TODOs and nocommits), one can enable 
basicauth with typical authz configuration. After this, the user can use the 
REST API for authc/authz, or we can build further support for adding users, 
roles etc. to the script.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Attachments: SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8440:
---
Attachment: SOLR-8440.patch

Another WIP patch. This is functionally complete: -enable and -disable both 
work. Updating the TODO items in the previous comment.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Attachments: SOLR-8440.patch, SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7807) Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures

[Steve Rowe (JIRA)]

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

Steve Rowe updated LUCENE-7807:
---
Summary: Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() 
failures  (was: Test*RangeFieldQueries.testRandomBig() failures)

> Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures
> -
>
> Key: LUCENE-7807
> URL: https://issues.apache.org/jira/browse/LUCENE-7807
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>
> My Jenkins found a failing master seed for {{testRandomBig()}} in all the 
> {{Test\*RangeFieldQueries}} suites:
> {noformat}
> Checking out Revision 2f6101b2ab9e93173a9764450b5f71935495802e 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIntRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=es-VE -Dtests.timezone=US/Hawaii -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  116s J2  | TestIntRangeFieldQueries.testRandomBig <<<
>[junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
> possibly more):
>[junit4]> FAIL (iter 28): id=973300 should not match but did
>[junit4]>  queryRange=Box(-2147483648 TO 2147483647)
>[junit4]>  box=Box(-1240758905 TO 1326270659)
>[junit4]>  queryType=CONTAINS
>[junit4]>  deleted?=false
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([90CE64A8F1BFDF78:1799192760E6A3F8]:0)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:73)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id=Lucene50(blocksize=128)}, docValues:{id=DocValuesFormat(name=Memory), 
> intRangeField=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=805, 
> maxMBSortInHeap=6.031593684373835, sim=RandomSimilarity(queryNorm=true): {}, 
> locale=es-VE, timezone=US/Hawaii
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=238346048,total=532152320
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestFloatRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=no-NO -Dtests.timezone=America/Lima -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  117s J9  | TestFloatRangeFieldQueries.testRandomBig <<<
>[junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
> possibly more):
>[junit4]> FAIL (iter 28): id=973300 should not match but did
>[junit4]>  queryRange=Box(-Infinity TO Infinity)
>[junit4]>  box=Box(-7.845437E37 TO 1.6013746E38)
>[junit4]>  queryType=CONTAINS
>[junit4]>  deleted?=false
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([90CE64A8F1BFDF78:1799192760E6A3F8]:0)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:73)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id=PostingsFormat(name=Asserting)}, 
> docValues:{floatRangeField=DocValuesFormat(name=Memory), 
> id=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=7.5037451812250175, sim=RandomSimilarity(queryNorm=true): {}, 
> locale=no-NO, timezone=America/Lima
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestDoubleRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=th-TH -Dtests.timezone=America/Argentina/Tucuman 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 99.0s J3  | TestDoubleRangeFieldQueries.testRandomBig <<<
>[junit4]> 

[jira] [Commented] (LUCENE-7807) Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7807:


My Jenkins found a reproducing seed for {{testRandomTiny()}} for all 4 
{{Test\*RangeFieldQueries}} suites (I did not run {{git bisect}} to find the 
first failing commit for these):

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestLongRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=CA203E745CDBBB7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=ar-JO -Dtests.timezone=Pacific/Pago_Pago -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.02s J4  | TestLongRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 12): id=0 should not match but did
   [junit4]>  queryRange=Box(-9223372036854775808 TO 9223372036854775807)
   [junit4]>  box=Box(-7801183850520246677 TO -4964726929345376585)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CA203E745CDBBB7B:8367E03202FA83D7]:0)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomTiny(BaseRangeFieldQueryTestCase.java:64)
[...]
   [junit4]   2> NOTE: test params are: codec=Lucene70, 
sim=RandomSimilarity(queryNorm=true): {}, locale=ar-JO, 
timezone=Pacific/Pago_Pago
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=287973992,total=455081984
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestDoubleRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=CA203E745CDBBB7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=ko -Dtests.timezone=Europe/Samara -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.01s J8  | TestDoubleRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 12): id=0 should not match but did
   [junit4]>  queryRange=Box(-Infinity TO Infinity)
   [junit4]>  box=Box(-4.322208110367465E307 TO -2.940099941534568E307)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CA203E745CDBBB7B:8367E03202FA83D7]:0)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomTiny(BaseRangeFieldQueryTestCase.java:64)
[...]
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
{id=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, 
docValues:{doubleRangeField=DocValuesFormat(name=Direct), 
id=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=857, 
maxMBSortInHeap=5.262063554817104, sim=RandomSimilarity(queryNorm=true): {}, 
locale=ko, timezone=Europe/Samara
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=213636832,total=418906112
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestFloatRangeFieldQueries -Dtests.method=testRandomTiny 
-Dtests.seed=CA203E745CDBBB7B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=es-MX -Dtests.timezone=America/Manaus -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] FAILURE 0.01s J6  | TestFloatRangeFieldQueries.testRandomTiny <<<
   [junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
possibly more):
   [junit4]> FAIL (iter 12): id=0 should not match but did
   [junit4]>  queryRange=Box(-Infinity TO Infinity)
   [junit4]>  box=Box(-8.078581E37 TO 3.0421576E37)
   [junit4]>  queryType=CONTAINS
   [junit4]>  deleted?=false
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CA203E745CDBBB7B:8367E03202FA83D7]:0)
   [junit4]>at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
   [junit4]>at 

[jira] [Commented] (SOLR-10233) Add support for different replica types in Solr

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10233:
--

I didn't know if Github mirror was going to allow me to create the PR from the 
official branch, but apparently it does :-) Feel free to review and comment 
there. 
Code is not ready, but it's getting close:
* Added new ChaosMonkey tests ("SafeLeader" and "NothingIsSafe"). I've been 
running them and the "SafeLeader" is doing great. "NothingIsSafe" found some 
shard inconsistencies, I'm looking at those now.
* Cleaned some TODOs/nocommits, there are a couple missing.
* Added a test to validate some connection error handling for passive replicas
* Made replica types work with "legacyCloud"

TODOs:
* Passive replicas to forward RTG requests to leader
* More tests (in particular, If anyone has an idea of a way to track replica 
state changes reliable to validate them, I tried it 
[here|https://github.com/apache/lucene-solr/blob/e7c8cec61c5b27bd9ce40eaa29a2f621a0bf2640/solr/core/src/test/org/apache/solr/cloud/TestPassiveReplica.java#L262-L290],
 but the collection state watcher can see repeated states or miss states)
* un-deprecate replication factor, at least for the user APIs
* Define better names, at least for "REALTIME"

> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, 
> SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's  distributed indexing is 
> great. There is a subset of use cases for which the legacy Master/Slave 
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their 
> transaction log. This Jira is to extend that idea and provide the following 
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas 
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica 
> can become a leader. This is the only type supported in SolrCloud at this 
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication. 
> Any _append_ replica can become leader (by first applying all local 
> transaction log elements). If a replica is of type _append_ but is also the 
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is 
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from 
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders 
> (i.e., if there are only passive replicas in the collection at some point, 
> updates will fail same as if there is no leaders, queries continue to work), 
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute 
> it to all _realtime_ and _append_ replicas, the same as it does today. It 
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an 
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with 
> most of its benefits, including high availability of writes. 
> h2. API (v1 style)
> {{/admin/collections?action=CREATE…&*realtimeReplicas=X=Y=Z*}}
> {{/admin/collections?action=ADDREPLICA…&*type=\[realtime/append/passive\]*}}
> * “replicationFactor=” will translate to “realtime=“ for back compatibility
> * if _passive_ > 0, _append_ or _realtime_ need to be >= 1 (can’t be all 
> passives)
> h2. Placement Strategies
> By using replica placement rules, one should be able to dedicate nodes to 
> search-only and write-only workloads. For example:
> {code}
> shard:*,replica:*,type:passive,fleet:slaves
> {code}
> where “type” is a new condition supported by the rule engine, and 
> “fleet:slaves” is a regular tag. Note that rules are only applied when the 
> replicas are created, so a later change in tags won't affect existing 
> replicas. Also, rules are per collection, so each collection could contain 
> it's own different rules.
> Note that on the server side Solr also needs to know how to distribute the 
> shard requests (maybe ShardHandler?) if we want to hit only a subset of 
> replicas (i.e. *passive *replicas only, or similar rules)
> h2. SolrJ
> 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1271/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting

Error Message:
Should have exactly 4 documents returned expected:<4> but was:<2>

Stack Trace:
java.lang.AssertionError: Should have exactly 4 documents returned expected:<4> 
but was:<2>
at 
__randomizedtesting.SeedInfo.seed([66A7E47D52B1159E:789FEC752E1AAF1E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.checkSortOrder(DocValuesNotIndexedTest.java:259)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting(DocValuesNotIndexedTest.java:244)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Commented] (SOLR-10233) Add support for different replica types in Solr

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-10233:
---

GitHub user tflobbe opened a pull request:

https://github.com/apache/lucene-solr/pull/196

SOLR-10233: Add support for different replica types

Code is not done yet (although getting close). Opening the PR to make it 
easier to review.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/lucene-solr jira/solr-10233

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/196.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #196


commit 3d149074e143ec685a3d079e9acf33bd9e0e6b40
Author: Tomas Fernandez Lobbe 
Date:   2017-04-25T23:37:08Z

Moved patch to (new) branch. Updated to master

commit a217dfaaf43950fb229b088745d6207ce5106b6e
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T00:10:41Z

Added error handling tests for Passive Replicas

commit 0330b4abe5785e509b29d3bc7f461c4e57d153f7
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T23:21:40Z

Sometimes use legacyCloud in tests

commit 304add6f631494d28d952431055e89b8357c6a5a
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T23:28:25Z

Added ChaosMonkey tests with safe leader for passive replicas

commit 2c133d4cfb533900dcb72784c12b3829e8277c65
Author: Tomas Fernandez Lobbe 
Date:   2017-04-27T23:27:46Z

Added ChaosMonkey test without safe leader for passive replicas

commit a342edd9eee95c30eabd00824a7c69f1d36ba33a
Author: Tomas Fernandez Lobbe 
Date:   2017-04-27T23:38:24Z

Fix ChaosMonkey expire connection and connection loss properties

commit e7d54fa0b1e31b01be05c479975da36c53259a96
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T00:51:52Z

Added logging to ChaosMonkey

commit 0f9baa4919840e406122bba4ef87897121be0649
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T21:26:26Z

Minor improvements to ChaosMonkey tests

commit e7c8cec61c5b27bd9ce40eaa29a2f621a0bf2640
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T22:53:12Z

Some code cleanup




> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, 
> SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's  distributed indexing is 
> great. There is a subset of use cases for which the legacy Master/Slave 
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their 
> transaction log. This Jira is to extend that idea and provide the following 
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas 
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica 
> can become a leader. This is the only type supported in SolrCloud at this 
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication. 
> Any _append_ replica can become leader (by first applying all local 
> transaction log elements). If a replica is of type _append_ but is also the 
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is 
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from 
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders 
> (i.e., if there are only passive replicas in the collection at some point, 
> updates will fail same as if there is no leaders, queries continue to work), 
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute 
> it to all _realtime_ and _append_ replicas, the same as it does today. It 
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an 
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with 
> most of its benefits, including 

[GitHub] lucene-solr pull request #196: SOLR-10233: Add support for different replica...

[tflobbe]

GitHub user tflobbe opened a pull request:

https://github.com/apache/lucene-solr/pull/196

SOLR-10233: Add support for different replica types

Code is not done yet (although getting close). Opening the PR to make it 
easier to review.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/lucene-solr jira/solr-10233

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/196.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #196


commit 3d149074e143ec685a3d079e9acf33bd9e0e6b40
Author: Tomas Fernandez Lobbe 
Date:   2017-04-25T23:37:08Z

Moved patch to (new) branch. Updated to master

commit a217dfaaf43950fb229b088745d6207ce5106b6e
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T00:10:41Z

Added error handling tests for Passive Replicas

commit 0330b4abe5785e509b29d3bc7f461c4e57d153f7
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T23:21:40Z

Sometimes use legacyCloud in tests

commit 304add6f631494d28d952431055e89b8357c6a5a
Author: Tomas Fernandez Lobbe 
Date:   2017-04-26T23:28:25Z

Added ChaosMonkey tests with safe leader for passive replicas

commit 2c133d4cfb533900dcb72784c12b3829e8277c65
Author: Tomas Fernandez Lobbe 
Date:   2017-04-27T23:27:46Z

Added ChaosMonkey test without safe leader for passive replicas

commit a342edd9eee95c30eabd00824a7c69f1d36ba33a
Author: Tomas Fernandez Lobbe 
Date:   2017-04-27T23:38:24Z

Fix ChaosMonkey expire connection and connection loss properties

commit e7d54fa0b1e31b01be05c479975da36c53259a96
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T00:51:52Z

Added logging to ChaosMonkey

commit 0f9baa4919840e406122bba4ef87897121be0649
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T21:26:26Z

Minor improvements to ChaosMonkey tests

commit e7c8cec61c5b27bd9ce40eaa29a2f621a0bf2640
Author: Tomas Fernandez Lobbe 
Date:   2017-04-28T22:53:12Z

Some code cleanup




---
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-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9867:


{code}
diff --git a/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java 
b/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java
index 39ccadc..ab46f19 100644
--- a/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java
+++ b/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java
@@ -96,6 +96,8 @@
   private Boolean testMode = null;
   private boolean isV2Enabled = 
!"true".equals(System.getProperty("disable.v2.api", "false"));
 
+  private volatile boolean initIsDone;
+
   /**
* Enum to define action that needs to be processed.
* PASSTHROUGH: Pass through to Restlet via webapp.
@@ -182,6 +184,7 @@
 }
 
 log.trace("SolrDispatchFilter.init() done");
+initIsDone = true;
   }
 
   private void setupJvmMetrics()  {
@@ -307,6 +310,7 @@
   }
   
   public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain chain, boolean retry) throws IOException, ServletException {
+assert initIsDone:"I swear";
 if (!(request instanceof HttpServletRequest)) return;
 try {
{code}

{code}
305  INFO  (Thread-1) [] o.a.s.s.SolrDispatchFilter  ___  _   
Welcome to Apache Solr™ version 7.0.0
305  INFO  (Thread-1) [] o.a.s.s.SolrDispatchFilter / __| ___| |_ _   
Starting in standalone mode on port 52215
305  INFO  (Thread-1) [] o.a.s.s.SolrDispatchFilter \__ \/ _ \ | '_|  
Install dir: null
321  INFO  (Thread-1) [] o.a.s.s.SolrDispatchFilter |___/\___/_|_|Start 
time: 2017-04-28T22:25:03.738Z
335  INFO  (Thread-1) [] o.a.s.c.SolrResourceLoader solr home defaulted to 
'solr/' (could not find system property or JNDI)
341  INFO  (Thread-1) [] o.a.s.c.SolrXmlConfig Loading container 
configuration from 
/private/var/folders/rg/fr1t3mx9391f1_g0xs8wtq2d1xv078/T/solr.util.TestSolrCLIRunExample_E157FC17061E2B1D-001/tempDir-001/schemaless/solr/solr.xml
465  WARN  (qtp15120-21) [] o.e.j.s.ServletHandler Error for 
/solr/admin/info/system
java.lang.AssertionError: I swear
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:313)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:309)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:462)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
{code}
So, what we gonna do, then... 

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1288 - Failure

[Apache Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.lucene.search.TestDoubleRangeFieldQueries.testRandomTiny

Error Message:
wrong hit (first of possibly more):  FAIL (iter 87): id=0 should not match but 
did  queryRange=Box(-Infinity TO Infinity)  box=Box(4.992828343822847E307 TO 
7.931369402719117E307)  queryType=CONTAINS  deleted?=false

Stack Trace:
java.lang.AssertionError: wrong hit (first of possibly more):

FAIL (iter 87): id=0 should not match but did
 queryRange=Box(-Infinity TO Infinity)
 box=Box(4.992828343822847E307 TO 7.931369402719117E307)
 queryType=CONTAINS
 deleted?=false
at 
__randomizedtesting.SeedInfo.seed([69A0759E7B6AFB0B:20E7ABD8254BC3A7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
at 
org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomTiny(BaseRangeFieldQueryTestCase.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.lucene.search.TestFloatRangeFieldQueries.testRandomTiny

Error Message:
wrong hit (first of possibly more):  FAIL (iter 87): id=0 

[jira] [Comment Edited] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-9867 at 4/28/17 9:17 PM:
-

[^SOLR-9867-test.patch] enabling existing test (Thank's to [~thelabdude], it's 
was an enormous effort, Tim!).
Ok. {{CoreAdminOperation.getCoreStatus(CoreContainer, String, boolean)}} is 
completely ignorant to {{CoreContainer.isCoreLoading(String)}}, I can explain 
this. It's ok. 


was (Author: mkhludnev):
[^SOLR-9867-test,patch] enabling existing test (Thank's to [~thelabdude], it's 
was an enormous effort, Tim!), I'm sorry for the comma.
Ok. {{CoreAdminOperation.getCoreStatus(CoreContainer, String, boolean)}} is 
completely ignorant to {{CoreContainer.isCoreLoading(String)}}, I can explain 
this. It's ok. 

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9867:
---
Attachment: (was: SOLR-9867-test,patch)

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9867:
---
Attachment: SOLR-9867-test.patch

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867-test,patch, SOLR-9867-test.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5405) Cloud graph view not usable by color-blind users - request small tweak

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5405:


I did notice the stoplight theme ... but in my opinion yellow is a TERRIBLE 
color for any web-based text on typical background colors, so I don't think it 
works very well.


> Cloud graph view not usable by color-blind users - request small tweak
> --
>
> Key: SOLR-5405
> URL: https://issues.apache.org/jira/browse/SOLR-5405
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.5
>Reporter: Nathan Neulinger
>Assignee: Stefan Matheis (steffkes)
>  Labels: accessibility
> Attachments: 
> SOLR-5405-circle-triangleUp-triangleDown-diamond-square-dashedSquare.png, 
> SOLR-5405.patch
>
>
> Currently, the cloud view status is impossible to see easily on the graph 
> screen if you are color blind. (On of my coworkers.)
> Would it be possible to put " (X)" after the IP of the node where X is 
> [LARDFG] for the states?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Why no composite primary-key in lucene ?

[Shawn Heisey]

On 4/28/2017 6:16 AM, Dorian Hoxha wrote:
> I searched for this on mailing-list,issues etc, but couldn't find any
> post.
>
> So, why not have the possibility of  ?
> Or nobody cared enough to implement it ? Or no gains ?

To my knowledge, and I hope someone can correct me if I'm wrong, Lucene
generally has absolutely no concept of a primary key at all, much less
one that's composite.  At its core, Lucene won't complain if you index
the same document twice -- both copies will be present.

Solr (and probably a LOT of user-written Lucene code before that)
introduced the concept of a uniqueKey field.  When a duplicate document
is indexed to Solr, it is Solr that finds/deletes the original, not
Lucene.  I feel quite confident in saying that ES has the same
functionality, though I have not confirmed it.

Thanks,
Shawn


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

Re: JIRA Status - Finding Patch Submissions

[Shawn Heisey]

On 4/28/2017 9:42 AM, Mike Drob wrote:
> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
> project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are
> out there.
>
> I did a spot check, thinking that a lot of these might be bug reports
> with error logs or screen shots attached, but nope. These are mostly
> patches. I'm going to try starting with the oldest ones to see if they
> can be rebase, have already been committed, or generally try to triage
> them. Would appreciate any volunteers that want to help.

This doesn't surprise me at all.  Many users submit patches for issues
they encounter, but for one reason or another, no committer action ever
happens.  There are many possible reasons.

1) The patch has bugs or some other problem that makes it unacceptable.
2) When the issue/patch is reviewed, one of these situations exists:
 a) Committers don't think it's worth pursuing.
 b) The code is behaving as designed.
 c) The committer cannot reproduce the problem.
 d) The committer doesn't understand the problem.
 e) The committer doesn't think it's actually a problem.
 f) A workaround exists that is just as effective as the patch.
3) Nobody has had time to review the issue/patch.

In some of these situations, the reviewing committer should probably
close the issue with an appropriate reason ... but issue triage is a
difficult and unrewarding job.  Sometimes it just doesn't happen.

Thanks,
Shawn


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

[jira] [Updated] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9867:
---
Attachment: SDF init and doFilter in parallel.png

[^SDF init and doFilter in parallel.png] here is what I can't explain. 
SolrDispatchFilter.init() and doFilter() is running in parallel. How is it 
possible? It's the same SolrDispatchFilter instance. Can it be caused just by 
JettyRunner usage in test?   

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SDF init and doFilter in parallel.png, SOLR-9867.patch, 
> SOLR-9867.patch, SOLR-9867-test,patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-7041) Nuke defaultSearchField and solrQueryParser from schema

[JIRA]

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

Jan Høydahl updated SOLR-7041:
--
Attachment: SOLR-7041-defaultOperator.patch

This patch SOLR-7041-defaultOperator.patch removes all use of 
{{defaultOperator}} in test schemas as well as a lot of unnecessary 
{{defaultSearchField}} usage.

I'm going to commit this as the first step to get some progress.

Converting test files from using {{}} in schemas into using 
{{df}} in solrconfig is harder, since the same config is used by many test 
schemas with many different default fields. So either we fork more configs with 
the only difference being df, or we instrument the {{beforeClass()}} method of 
the tests in question that do not use "text" as df to redefine the {{/select}} 
handler using config API.

> Nuke defaultSearchField and solrQueryParser from schema
> ---
>
> Key: SOLR-7041
> URL: https://issues.apache.org/jira/browse/SOLR-7041
> Project: Solr
>  Issue Type: Improvement
>  Components: Schema and Analysis
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.0
>
> Attachments: SOLR-7041-defaultOperator.patch, SOLR-7041.patch
>
>
> The two tags {{}} and {{solrQueryParser}} were deprecated 
> in Solr3.6 (SOLR-2724). Time to nuke them from code and {{schema.xml}} in 5.0?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9867) The Solr examples can not always be started after being stopped due to race with loading core.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9867:
---
Attachment: SOLR-9867-test,patch

[^SOLR-9867-test,patch] enabling existing test (Thank's to [~thelabdude], it's 
was an enormous effort, Tim!), I'm sorry for the comma.
Ok. {{CoreAdminOperation.getCoreStatus(CoreContainer, String, boolean)}} is 
completely ignorant to {{CoreContainer.isCoreLoading(String)}}, I can explain 
this. It's ok. 

> The Solr examples can not always be started after being stopped due to race 
> with loading core.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mark Miller
>Priority: Critical
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9867.patch, SOLR-9867.patch, SOLR-9867-test,patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an 
> error when it tries to create the SolrCore (again, it already exists) and so 
> it deletes the cores instance dir which leads to tlog and index lock errors 
> in Solr.
> The reason it seems to be trying to create the core when it already exists is 
> that the run example tool uses a core status call to check existence and 
> because the core is loading, we don't consider it as existing. I added a 
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core 
> was still loading. It appears CoreContainer#getCore  is supposed to be 
> blocking so you don't have this problem, but there must be an issue, because 
> it is not blocking.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10582) Add Correlation Evaluator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10582:


Commit 7f6f68c7f49298654b5db430e8b7525adac2723f in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f6f68c ]

SOLR-10582: Add Correlation Evaluator


> Add Correlation Evaluator
> -
>
> Key: SOLR-10582
> URL: https://issues.apache.org/jira/browse/SOLR-10582
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10582.patch, SOLR-10582.patch
>
>
> The Correlation Evaluator computes the Pearson's product-moment correlation 
> of two columns of data.
> Syntax:
> {code}
> let(a=expr, 
> b=expr, 
> c=col(a, fieldName), 
> d=col(b, fieldName), 
> tuple(corr=corr(c,d)))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_121) - Build # 19506 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19506/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MDCAwareThreadPoolExecutor, MockDirectoryWrapper, 
TransactionLog, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:92)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:752)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:947)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:959)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:894)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:378)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:388)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:178)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:747)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:728)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:509)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:355)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:647)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184)  at 
org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)  at 
org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
  at java.lang.Thread.run(Thread.java:745)  

[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9386:
--

bq. Steve Rowe, could we completely remove that parseProperties method from 
Solr code and just let ZK handle it? I see that there's still some excedption 
handling code there after your change, but IMHO we should let ZK handle any 
problems or throw relevant exceptions.

The exception handling is for the case that there is a missing {{myid}} file, 
which I think is the ordinary case for embedded ZK.  That's why I left it in.

I'll add some logging in the exception handling code and run a manual test to 
see if it gets invoked in that case.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9596) stopped working in Solr 6.2

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9596: Add Solr support for SimpleTextCodec, via  in solrconfig.xml (per-field specification 
in the schema is not possible).


>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9596.patch, SOLR-9596.patch, SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9596) stopped working in Solr 6.2

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9596: Add Solr support for SimpleTextCodec, via  in solrconfig.xml (per-field specification 
in the schema is not possible).


>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9596.patch, SOLR-9596.patch, SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-9596) stopped working in Solr 6.2

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9596.
--
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9596.patch, SOLR-9596.patch, SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9596) stopped working in Solr 6.2

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9596:
-
Attachment: SOLR-9596.patch

Slightly modified test: added test of basic retrieval.

>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-9596.patch, SOLR-9596.patch, SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/3974/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([5D4ED86C95420D67:D51AE7B63BBE609F]: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:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:861)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:620)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (SOLR-9596) stopped working in Solr 6.2

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9596:
-
Attachment: SOLR-9596.patch

Patch with test and a required IntelliJ config change.

I'll commit once precommit passes for me.

>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-9596.patch, SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-1550) statistics for request handlers should report std dev

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-1550.
-
Resolution: Duplicate

> statistics for request handlers should report std dev
> -
>
> Key: SOLR-1550
> URL: https://issues.apache.org/jira/browse/SOLR-1550
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Anderson
>Priority: Trivial
> Attachments: SOLR-1550.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10582) Add Correlation Evaluator

[Joel Bernstein (JIRA)]

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

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

Made the test case more robust

> Add Correlation Evaluator
> -
>
> Key: SOLR-10582
> URL: https://issues.apache.org/jira/browse/SOLR-10582
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10582.patch, SOLR-10582.patch
>
>
> The Correlation Evaluator computes the Pearson's product-moment correlation 
> of two columns of data.
> Syntax:
> {code}
> let(a=expr, 
> b=expr, 
> c=col(a, fieldName), 
> d=col(b, fieldName), 
> tuple(corr=corr(c,d)))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10583) Add 'join' as a new type of domain change in JSON Facets

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10583:

Attachment: SOLR-10583.patch


A while back someone asked me about the "domain change" idea in the JSON Facet 
code.  They had seen some blogs from yonik about use blockParent and 
blockChildren domain changes to facet on parent/child fields, and were 
wondering if the same sort of thing could work for a _query join_.

I wasn't too familiar with any of this code, but poking around it seemed fairly 
straight forward.  (Except that my randomized test case ran into an interesting 
bug when the same join query was used in two diff facets: I hacked around this 
by forcing a non-caching wrapper around the queries, but still haven't gotten 
to the root cause)


The attached patch includes:

* complete code implementing this new domain change option
* Modifications to {{TestJsonFacets}} to test the new {{join}} option w/similar 
data as the existing {{blockChildren}} and {{blockParent}} tests
* a fairly robust {{TestCloudJSONFacetJoinDomain}} that does randomized facet 
queries w/these {{join}} (sometimes + {{filter}}) domain changes and then 
verifies the result counts against test queries w/equivilent {{fq}} params
** currently only uses one shard...
** ...and always requests a facet limit greater then the cardinality of the 
fields so that refinement is not an issue even if/when the test starts using 
multiple shards
* a very similar but greatly simplified {{TestCloudJSONFacet}} that does 
similar checks but only using {{filter}} domain changes
** i hacked this off of {{TestCloudJSONFacetJoinDomain}} when i first started 
getting weird test failures to try see if i could reproduce any weird failures 
with just the existing domain change code

Still TODO (all pretty well captured in nocommits)...

# get to the bottom of the cache issue
#* need to do this first before improving the test to ensure nothing else 
"breaks" our garunteed failure in testBespoke
#* see nocommits in the code for ideas about possible root causes
# generate better errors if the {{join}} is malformed (ie: not a map, doesn't 
have both {{from}} and {{to}} specified
#* or maybe: support the syntax {{join : "field_name"}} as syntax sugar 
for...{code}
join : { from : "field_name", to : "field_name" }
{code}
# add code+tests to ensure joining on numeric fields works
# fix the {{multipleValuesPerDocument}} logic and enhance the test so some 
fields are always single valued
# cleanup & refactor some of the code that uses {{JoinUtil}}
#* is it as efficient as it can be?
#* is there stuff we can share with ScoreJoinQParserPlugin?
# refactor the {{TestCloudJSONFacet}} & {{TestCloudJSONFacetJoinDomain}} 
duplication and make them use multi-shards
#* FWIW: join queries might seem like an odd thing to worry about testing with 
multiple shards -- but the usecases I have in mind can all leverage doc routing 
to ensure that all docs with identical values in the join field are co-located
# investigate the recent work/tests yonik's been doing on supporting refinement 
(single level?), and add {{join}} to those tests as well.


> Add 'join' as a new type of domain change in JSON Facets
> 
>
> Key: SOLR-10583
> URL: https://issues.apache.org/jira/browse/SOLR-10583
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-10583.patch
>
>
> Add support for a new (query) {{join}} option when specifying a {{domain}} 
> for a JSON Facet.
> Suggested syntax...
> {code}
> ...
> domain : { join : { from : field_foo,
> to : field_bar
> }
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-8440) Script support for enabling basic auth

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-8440:
---
Attachment: SOLR-8440.patch

WIP patch.

# Introduces the "auth" command, e.g. {{bin/solr auth -enable -type basic 
-adminuser solr -adminpassword SolrRocks}}
# Support for optional blocksUnknown (false by default)
# TODO: Put the hash of the password. Currently hardcoded to hash of "SolrRocks"
# TODO: Introduce a separate file and put the admin username/password there for 
use by the script. If user wants, the bin/solr.in.sh can be used to override 
this user/pw.
# TODO: Do pre-checks before enabling; don't do anything if already enabled.
# Uploads the following security.json by default (apart from the user/password 
hash variant.

{code}
{
  "authentication":{
   "blockUnknown": $blockUnknown
   "class":"solr.BasicAuthPlugin",
   "credentials":{"$user":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= 
Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}
  },
  "authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[
{"name":"security-edit", "role":"admin"},
{"name":"collection-admin-edit", "role":"admin"},
{"name":"core-admin-edit", "role":"admin"}
   ],
   "user-role":{"$user":"admin"}
  }
}
{code}

With just this in place (after fixing TODOs and nocommits), one can enable 
basicauth with typical authz configuration. After this, the user can use the 
REST API for authc/authz, or we can build further support for adding users, 
roles etc. to the script.

> Script support for enabling basic auth
> --
>
> Key: SOLR-8440
> URL: https://issues.apache.org/jira/browse/SOLR-8440
> Project: Solr
>  Issue Type: New Feature
>  Components: scripts and tools
>Reporter: Jan Høydahl
>Assignee: Ishan Chattopadhyaya
>  Labels: authentication, security
> Attachments: SOLR-8440.patch
>
>
> Now that BasicAuthPlugin will be able to work without an AuthorizationPlugin 
> (SOLR-8429), it would be sweet to provide a super simple way to "Password 
> protect Solr"™ right from the command line:
> {noformat}
> bin/solr basicAuth -adduser -user solr -pass SolrRocks
> {noformat}
> It would take the mystery out of enabling one single password across the 
> board. The command would do something like this
> # Check if HTTPS is enabled, and if not, print a friendly warning
> # Check if {{/security.json}} already exists
> ## NO => create one with only plugin class defined
> ## YES => Abort if exists but plugin is not {{BasicAuthPlugin}}
> # Using security REST API, add the new user



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10583) Add 'join' as a new type of domain change in JSON Facets

[Hoss Man (JIRA)]

Hoss Man created SOLR-10583:
---

 Summary: Add 'join' as a new type of domain change in JSON Facets
 Key: SOLR-10583
 URL: https://issues.apache.org/jira/browse/SOLR-10583
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


Add support for a new (query) {{join}} option when specifying a {{domain}} for 
a JSON Facet.

Suggested syntax...

{code}
...
domain : { join : { from : field_foo,
  to : field_bar
  }
 }
{code}







--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10582) Add Correlation Evaluator

[Joel Bernstein (JIRA)]

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

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

> Add Correlation Evaluator
> -
>
> Key: SOLR-10582
> URL: https://issues.apache.org/jira/browse/SOLR-10582
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-10582.patch
>
>
> The Correlation Evaluator computes the Pearson's product-moment correlation 
> of two columns of data.
> Syntax:
> {code}
> let(a=expr, 
> b=expr, 
> c=col(a, fieldName), 
> d=col(b, fieldName), 
> tuple(corr=corr(c,d)))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10582) Add Correlation Evaluator

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-10582:
--
Description: 
The Correlation Evaluator computes the Pearson's product-moment correlation of 
two columns of data.

Syntax:
{code}
let(a=expr, 
b=expr, 
c=col(a, fieldName), 
d=col(b, fieldName), 
tuple(corr=corr(c,d)))
{code}



  was:
The Correlation Evaluator computes the Pearson's product-moment correlation of 
two columns of data.

Syntax:
{code}
let(a=expr, b=expr, c=col(a, fieldName), d=col(b, fieldName), 
   tuple(corr=corr(c,d)))
{code}




> Add Correlation Evaluator
> -
>
> Key: SOLR-10582
> URL: https://issues.apache.org/jira/browse/SOLR-10582
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> The Correlation Evaluator computes the Pearson's product-moment correlation 
> of two columns of data.
> Syntax:
> {code}
> let(a=expr, 
> b=expr, 
> c=col(a, fieldName), 
> d=col(b, fieldName), 
> tuple(corr=corr(c,d)))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10582) Add Correlation Evaluator

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-10582:
-

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


The Correlation Evaluator computes the Pearson's product-moment correlation of 
two columns of data.

Syntax:
{code}
let(a=expr, b=expr, c=col(a, fieldName), d=col(b, fieldName), 
   tuple(corr=corr(c,d)))
{code}





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5405) Cloud graph view not usable by color-blind users - request small tweak

[Curtis Schneider (JIRA)]

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

Curtis Schneider commented on SOLR-5405:


[~cpoerschke] I like your suggested shape mappings (especially with the added 
modification from Shawn) as they feel like they _flow_ from one state to the 
next.  One minor note, reusing the same shape in a different orientation (and I 
like your suggested use of triangles) may not work as well for the Cloud Graph 
(Radial) page.  I consider this a minor note as the radial graph has always 
appeared (to me) to be about aesthetics, rather than readability.

[~janhoy] Thank you for the image from the upcoming release, I hadn't thought 
of font formatting.  These changes look awesome, between the contrast in the 
colors and the added formatting changes this improves accessibility for me, 
greatly.

[~elyograg] Not at all.  I would mention that the Green->Yellow->Orange->Red 
color flow seems to be following a stoplight theme.

> Cloud graph view not usable by color-blind users - request small tweak
> --
>
> Key: SOLR-5405
> URL: https://issues.apache.org/jira/browse/SOLR-5405
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.5
>Reporter: Nathan Neulinger
>Assignee: Stefan Matheis (steffkes)
>  Labels: accessibility
> Attachments: 
> SOLR-5405-circle-triangleUp-triangleDown-diamond-square-dashedSquare.png, 
> SOLR-5405.patch
>
>
> Currently, the cloud view status is impossible to see easily on the graph 
> screen if you are color blind. (On of my coworkers.)
> Would it be possible to put " (X)" after the IP of the node where X is 
> [LARDFG] for the states?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (LUCENE-7809) spatial-extras module is not present under IntelliJ 2017.1

[Steve Rowe (JIRA)]

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

Steve Rowe closed LUCENE-7809.
--
Resolution: Not A Problem
  Assignee: Steve Rowe

I can't reproduce this problem in a different local repo - I'm guessing 
something weird happened when I switched to an older branch, ran {{ant 
clean-idea idea}}, then switched back to a newer branch and did the same thing.

I fixed the problem in IntelliJ in the original repo by "importing" the missing 
module using its own existing .iml file.

> spatial-extras module is not present under IntelliJ 2017.1
> --
>
> Key: LUCENE-7809
> URL: https://issues.apache.org/jira/browse/LUCENE-7809
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> When I run {{ant clean-idea idea}}, project compilation fails because modules 
> that depend on {{spatial-extras}} can't find it, because it is not defined.
> The issue appears to be that IntelliJ 2017.1 has dropped support for some 
> vestigial markup present in spatial-extras' {{.iml}} file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8762) DIH entity child=true should respond nested documents on debug

[gopikannan venugopalsamy (JIRA)]

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

gopikannan venugopalsamy commented on SOLR-8762:


[~mkhludnev] Is the patch ok?

> DIH entity child=true should respond nested documents on debug
> --
>
> Key: SOLR-8762
> URL: https://issues.apache.org/jira/browse/SOLR-8762
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Reporter: Mikhail Khludnev
>Priority: Minor
>  Labels: newbie, newdev
> Attachments: SOLR-8762.patch, SOLR-8762.patch
>
>
> Problem is described in 
> [comment|https://issues.apache.org/jira/browse/SOLR-5147?focusedCommentId=14744852=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14744852]
>  of SOLR-5147 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1784 - Still Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica

Error Message:
Error from server at https://127.0.0.1:50074/solr: deletereplica the collection 
time out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:50074/solr: deletereplica the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([D6F8636B618FD768:38481A3E6643C0D2]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:627)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:451)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:392)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testAddAndDeleteReplica(CollectionsAPISolrJTest.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_121) - Build # 860 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/860/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

Error Message:
expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([E85F0AF041EB5D07:1112995F7D9E108D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Created] (LUCENE-7809) spatial-extras module is not present under IntelliJ 2017.1

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7809:
--

 Summary: spatial-extras module is not present under IntelliJ 2017.1
 Key: LUCENE-7809
 URL: https://issues.apache.org/jira/browse/LUCENE-7809
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Steve Rowe


When I run {{ant clean-idea idea}}, project compilation fails because modules 
that depend on {{spatial-extras}} can't find it, because it is not defined.

The issue appears to be that IntelliJ 2017.1 has dropped support for some 
vestigial markup present in spatial-extras' {{.iml}} file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7987) Exception when timeallowed is exceed

[Dan Brown (JIRA)]

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

Dan Brown commented on SOLR-7987:
-

We're experiencing the same issue with 6.4.2 and 6.5.1.   Our default 
timeAllowed is set to 100.  Increasing the timeAllowed value to, say, 1200, on 
the same query returns results instead of an NPE.

> Exception when timeallowed is exceed 
> -
>
> Key: SOLR-7987
> URL: https://issues.apache.org/jira/browse/SOLR-7987
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 5.0
> Environment: java version "1.7.0_85"
> OpenJDK Runtime Environment (amzn-2.6.1.3.61.amzn1-x86_64 u85-b01)
> OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)
> Centos   3.14.26-24.46.amzn1.x86_64
>Reporter: fengqinglei
>  Labels: patch
>   Original Estimate: 12h
>  Remaining Estimate: 12h
>
> we set up a SolrCloud with 8 shards , and insert about 1+ documents  
> into it ,  and set the timeallowed=11000  for the searchHandler and when the 
> query have a lot of wildcard search ,  the timeallowed  is exceed of course , 
> but this is an unexcepted exception on some shards  , here is the detail   
> exception :
>  ERROR - 2015-08-13 10:45:39.574; org.apache.solr.common.SolrException; 
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1159)
> at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:1019)
> at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:743)
> at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:722)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:350)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2006)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:204)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:368)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
> at 
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
> at 
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
> at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at 
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
> at 
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: JIRA Status - Finding Patch Submissions

[Mike Drob]

So I started going through old JIRAs, and realized I don't have permission
to close duplicates. Could I have more JIRA permissions to complete this
task? I know some projects have given non-committers additional JIRA roles
for those willing to do JIRA maintenance as a contribution.

Alternatively, I can leave notes on them and somebody with more JIRA karma
can do a second pass to handle the cleanup.

Thanks,
Mike

On Fri, Apr 28, 2017 at 10:42 AM, Mike Drob  wrote:

> Thanks for this hint, Alex.
>
> I ran the following JQL to get some idea of our current status:
> project in (lucene, solr) and "Attachment count" > 0 and status = Open
>
> There were 1500 results.
>
> 1500. I couldn't believe it. This is a huge number of patches that are out
> there.
>
> I did a spot check, thinking that a lot of these might be bug reports with
> error logs or screen shots attached, but nope. These are mostly patches.
> I'm going to try starting with the oldest ones to see if they can be
> rebase, have already been committed, or generally try to triage them. Would
> appreciate any volunteers that want to help.
>
> Mike
>
> On Thu, Apr 27, 2017 at 3:21 PM, Alexandre Rafalovitch  > wrote:
>
>> There is an "Attachment count" filter, you can say it to be 1+. Not
>> everything will be a patch, but it is a good first pass. It is under
>> "More" dropdown.
>>
>> We also have some Github Integration fields in there, but they don't
>> seem to be actually doing anything for Solr project.
>>
>> Regards,
>>Alex.
>> 
>> http://www.solr-start.com/ - Resources for Solr users, new and
>> experienced
>>
>>
>> On 27 April 2017 at 16:15, Mike Drob  wrote:
>> > Devs,
>> >
>> > Does anybody have good JIRA filters or processes for finding issues with
>> > patches available and attached, or maybe with open pull requests for
>> them? I
>> > was talking to a few folks and we remarked how patches can sometimes
>> sit on
>> > issues for a long time, and this seems like a wasted opportunity when it
>> > happens.
>> >
>> > If the patch sits for too long, it can be discouraging to new
>> contributors.
>> > But it is also undesirable for us to let code rot happen like this,
>> since
>> > they may be fixes for bugs that we haven't run into ourselves yet.
>> >
>> > Other projects use a Jira "patch available" status, or rely mostly on
>> GitHub
>> > PRs, or have other mechanisms for improving visibility of pending
>> > contributions. I don't know which method is best, and am curious what
>> the
>> > rest of the community thinks. Maybe this is already a solved issue.
>> >
>> > Mike
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Commented] (SOLR-1550) statistics for request handlers should report std dev

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-1550:
-

Looks like this feature was added in SOLR-9854 via the codahale metrics.

> statistics for request handlers should report std dev
> -
>
> Key: SOLR-1550
> URL: https://issues.apache.org/jira/browse/SOLR-1550
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mike Anderson
>Priority: Trivial
> Attachments: SOLR-1550.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9635) Implement Solr as two java processes -- one process to manage the other.

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9635:


Been a while since I thought about this issue.  I've had some new ideas.

What if we move the admin UI from the main Solr process to the manager process, 
on a different port than Solr itself?  In standalone mode, the UI would manage 
the Solr process that the manager is controlling, but in cloud mode, it could 
manage the entire cloud.

This manager code could also manage a standalone ZooKeeper process independent 
of any Solr process it was also managing.

Thinking about the "master node" idea mentioned by [~otis] on the solr-user 
list, I'm also imagining a situation where someone could deploy one node with 
the manager, managing a ZK process (and maybe a Solr process), then deploy 
additional nodes, pointing them at the host/port of the first manager process, 
to fully automate the process of setting up multi-node SolrCloud and ZK.  Once 
that first node were set up, the admin UI could be used to change what runs on 
each node that's in the cloud, change the cluster and ZK configuration, etc.  
We would need to think about upgrades, for the manager process itself, Solr, 
and ZK.


> Implement Solr as two java processes -- one process to manage the other.
> 
>
> Key: SOLR-9635
> URL: https://issues.apache.org/jira/browse/SOLR-9635
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Shawn Heisey
>
> One idea that Mark Miller mentioned some time ago that I really like is the 
> idea of implementing Solr as two java processes, with one managing the other.
> When I think about this idea, what I imagine is a manager process with a 
> *very* small heap (I'm thinking single-digit megabytes) that is responsible 
> for starting a separate Solr process with configured values for many 
> different options, which would include the heap size.
> Basically, the manager process would replace most of bin/solr as we know it, 
> would be able to restart a crashed Solr, and the admin UI could have options 
> for changing heap size, restarting Solr, and other things that are currently 
> impossible.  It is likely that this idea would absorb or replace the SolrCLI 
> class.
> Initially, I intend this issue for discussion, and if the idea looks 
> workable, then we can work towards implementation.  There are plenty of 
> bikesheds to paint as we work the details.  I have some preliminary ideas 
> about some parts of it, which I will discuss in comments.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-9386:


[~steve_rowe], could we completely remove that parseProperties method from Solr 
code and just let ZK handle it?  I see that there's still some excedption 
handling code there after your change, but IMHO we should let ZK handle any 
problems or throw relevant exceptions.

There's another issue where somebody wanted to use a config option in the 
embedded zookeeper supported by 3.4 but not the the 3.2 version the 
parseProperties method was copied from ... so it didn't work. I can't seem to 
locate that issue now.  I'm pretty sure that in the patch for that issue, I 
completely removed the method and didn't have any problems.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: JIRA Status - Finding Patch Submissions

[Mike Drob]

Thanks for this hint, Alex.

I ran the following JQL to get some idea of our current status:
project in (lucene, solr) and "Attachment count" > 0 and status = Open

There were 1500 results.

1500. I couldn't believe it. This is a huge number of patches that are out
there.

I did a spot check, thinking that a lot of these might be bug reports with
error logs or screen shots attached, but nope. These are mostly patches.
I'm going to try starting with the oldest ones to see if they can be
rebase, have already been committed, or generally try to triage them. Would
appreciate any volunteers that want to help.

Mike

On Thu, Apr 27, 2017 at 3:21 PM, Alexandre Rafalovitch 
wrote:

> There is an "Attachment count" filter, you can say it to be 1+. Not
> everything will be a patch, but it is a good first pass. It is under
> "More" dropdown.
>
> We also have some Github Integration fields in there, but they don't
> seem to be actually doing anything for Solr project.
>
> Regards,
>Alex.
> 
> http://www.solr-start.com/ - Resources for Solr users, new and experienced
>
>
> On 27 April 2017 at 16:15, Mike Drob  wrote:
> > Devs,
> >
> > Does anybody have good JIRA filters or processes for finding issues with
> > patches available and attached, or maybe with open pull requests for
> them? I
> > was talking to a few folks and we remarked how patches can sometimes sit
> on
> > issues for a long time, and this seems like a wasted opportunity when it
> > happens.
> >
> > If the patch sits for too long, it can be discouraging to new
> contributors.
> > But it is also undesirable for us to let code rot happen like this, since
> > they may be fixes for bugs that we haven't run into ourselves yet.
> >
> > Other projects use a Jira "patch available" status, or rely mostly on
> GitHub
> > PRs, or have other mechanisms for improving visibility of pending
> > contributions. I don't know which method is best, and am curious what the
> > rest of the community thinks. Maybe this is already a solved issue.
> >
> > Mike
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-10479) support HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction) options

[Christine Poerschke (JIRA)]

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

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

Attaching complete proposed patch. Feedback, code reviews, comments, etc. 
welcome as usual. Thank you.

> support 
> HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction) 
> options
> -
>
> Key: SOLR-10479
> URL: https://issues.apache.org/jira/browse/SOLR-10479
> Project: Solr
>  Issue Type: New Feature
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10479.patch, SOLR-10479.patch
>
>
> If a request sends no {{timeAllowed}} threshold (or if it sends a very 
> generous threshold) then that request can potentially be retried on 'very 
> many' servers in the cloud.
> Via the 
> {{HttpShardHandlerFactory.loadBalancerRequests(MinimumAbsolute|MaximumFraction)}}
>  options the number of servers tried can be restricted via configuration e.g.
> {code}
>  class="solr.HttpShardHandlerFactory">
>   2
>   0.50
> 
> {code}
> would on a six-replica-and-all-replicas-active collection/shard restrict 
> sending to three replicas i.e. max(2, 0.50 x 6) and if the collection/shard 
> temporarily becomes 
> three-replicas-active-and-three-replicas-recovering-or-down then sending is 
> restricted to two replicas i.e. max(2, 0.50 x 3) temporarily.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-9596) stopped working in Solr 6.2

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-9596:


Assignee: Steve Rowe

>  stopped working in 
> Solr 6.2
> ---
>
> Key: SOLR-9596
> URL: https://issues.apache.org/jira/browse/SOLR-9596
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-9596.patch
>
>
> As a result of changes introduced in Lucene 6.2 by LUCENE-7323, 
> SimpleTextCodec's postings and doc values formats can only be used from 
> SimpleTextCodec.  That means that Solr's default codecFactory 
> SchemaCodecFactory, which enables per-field specification of postings and doc 
> values formats by extending LuceneXXCodec to pull per-field specification 
> from the schema, can't be used with SimpleText postings and doc values 
> formats.
> What Solr could instead do is provide a non-schema-aware 
> SimpleTextCodecFactory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-9386.
--
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.6

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9386: Upgrade Zookeeper to 3.4.10


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9386: Upgrade Zookeeper to 3.4.10


> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10568:
---

bq. Tomorrow I'll set it up to email the dev list if the build has a problem - 
currently no email is sent.

Failure emails will now be sent to the dev list.

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-9386:


Assignee: Steve Rowe

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9386:
-
Attachment: SOLR-9386.patch

precommit noticed I hadn't refreshed the zk jar's .sha1 file; this patch fixes 
the problem.

With this version of the patch, precommit and all Solr tests pass.

Committing shortly.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-9386.patch, SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10568:
--

Nice work, Steve - thanks!

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9386) Upgrade Zookeeper to 3.4.10

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9386:
-
Attachment: SOLR-9386.patch

Updated patch, upping ZK dep to 3.4.10.

Compilation succeeds, and I looked at 3.4.10's sample zoo.cfg to see if there 
were changes we should include (there weren't any new ones).

I'm going to run all tests and precommit.  Assuming nothing goes wrong, I want 
to commit this so it gets included in Solr 6.6.

> Upgrade Zookeeper to 3.4.10
> ---
>
> Key: SOLR-9386
> URL: https://issues.apache.org/jira/browse/SOLR-9386
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-9386.patch, SOLR-9386.patch, 
> zookeeper-3.4.8-upgrade-tests-pass.patch, 
> zookeeper-3.4.9-upgrade-tests-fail.patch
>
>
> Zookeeper 3.4.10 release should be happening fairly soon, and the ZK issue 
> blocking incorporation into Solr (ZOOKEEPER-2383) has a 3.4.10-targetted 
> patch that fixes the test failures problem noted on SOLR-8724.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5405) Cloud graph view not usable by color-blind users - request small tweak

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5405:


If we have highly effective visual cues that don't rely on color, like good 
shapes and font styles, then I believe we can do just about anything when it 
comes to the color choices we make, and we can get rid of that terrible light 
grey.

I hope you aren't perturbed by that, [~SchneiderCurtis].  I very much want you 
to be comfortable with the interface, but I fear that choosing colors that work 
for you would make the interface less appealing for others.

With that in mind, I suggest purple for Recovery Failed and red for Gone.  We 
could use blue for Recovering -- yellow is almost as hard to read as light 
grey.  I'm ambivalent about orange for Down.  Brown might be a better choice, 
but I don't actually have a problem with orange.


> Cloud graph view not usable by color-blind users - request small tweak
> --
>
> Key: SOLR-5405
> URL: https://issues.apache.org/jira/browse/SOLR-5405
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.5
>Reporter: Nathan Neulinger
>Assignee: Stefan Matheis (steffkes)
>  Labels: accessibility
> Attachments: 
> SOLR-5405-circle-triangleUp-triangleDown-diamond-square-dashedSquare.png, 
> SOLR-5405.patch
>
>
> Currently, the cloud view status is impossible to see easily on the graph 
> screen if you are color blind. (On of my coworkers.)
> Would it be possible to put " (X)" after the IP of the node where X is 
> [LARDFG] for the states?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 844 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([2A97499035A7B6AA:F2DA64C7C27A130A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Resolved] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-7794.

   Resolution: Fixed
 Assignee: Steve Rowe
Fix Version/s: 6.5.2
   6.6
   6.4.3
   5.5.5
   6.3.1
   6.2.2
   5.6
   6.1.1
   6.0.2
   master (7.0)

> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.0.2, 6.1.1, 5.6, 6.2.2, 6.3.1, 5.5.5, 
> 6.4.3, 6.6, 6.5.2
>
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 5513de33b513874d4569ae42951e575f5aac085e in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5513de3 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 8aed049aee3ee4fe37c782c07666f4af806d014c in lucene-solr's branch 
refs/heads/branch_6_3 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8aed049 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 72319115a4ed5a3deb1a887b5b126a2e9ce12f87 in lucene-solr's branch 
refs/heads/branch_6_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7231911 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 3b2bbb9bb9ca35de6bbd1289491dde5ee2d626ff in lucene-solr's branch 
refs/heads/branch_6_4 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3b2bbb9 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit e9094e59f2116d84e2a0eb44ac3b64029eba39c1 in lucene-solr's branch 
refs/heads/branch_6_2 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e9094e5 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 6b8fec656361e37492e137ac61fd37c0e60b070d in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b8fec6 ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit 03d24fcdf2fc456285c7d19679754bab2b7774f0 in lucene-solr's branch 
refs/heads/branch_6_1 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=03d24fc ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[ASF subversion and git services (JIRA)]

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

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

Commit dece98f74d8c7dd0d554e6b7060d70a83164bebc in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dece98f ]

LUCENE-7794: buildAndPushRelease.py should run validate and documentation-lint


> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[Steve Rowe (JIRA)]

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

Steve Rowe resolved LUCENE-7793.

   Resolution: Fixed
Fix Version/s: 6.5.2
   6.6
   6.4.3
   5.5.5
   6.3.1
   6.2.2
   5.6
   6.1.1
   6.0.2
   master (7.0)

> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master (7.0), 6.0.2, 6.1.1, 5.6, 6.2.2, 6.3.1, 5.5.5, 
> 6.4.3, 6.6, 6.5.2
>
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit 78190815fa45f3442795ac7112af47f61e2d59d3 in lucene-solr's branch 
refs/heads/branch_6_4 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7819081 ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit 7cbd99b4d843b708eab7d02a277a1e230bb0e5bc in lucene-solr's branch 
refs/heads/branch_6_2 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7cbd99b ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit 2cf5b3442530e845fc5e0d554788173f61af746e in lucene-solr's branch 
refs/heads/branch_6_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2cf5b34 ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit 7e3580e95164fa6e07866f60a7b61ed4d356d36a in lucene-solr's branch 
refs/heads/branch_6_1 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7e3580e ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit b7d5c73c16f93354191a1d4b95ba3ff802da8624 in lucene-solr's branch 
refs/heads/branch_5_5 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b7d5c73 ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit daa52a2f5137aa8514ad9986920ba423d23ff6b1 in lucene-solr's branch 
refs/heads/branch_6_3 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=daa52a2 ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit fdf81cfcbea4d28d68e377b11e03a79f1ae115f3 in lucene-solr's branch 
refs/heads/branch_5x from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fdf81cf ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[ASF subversion and git services (JIRA)]

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

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

Commit 33af0511254c36b984b492b5ebdfa54f233f9569 in lucene-solr's branch 
refs/heads/branch_6_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=33af051 ]

LUCENE-7793: smokeTestRelease.py should run documentation-lint


> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7794) buildAndPushRelease.py should run precommit (or the equivalent)

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7794:


Committing shortly.

> buildAndPushRelease.py should run precommit (or the equivalent)
> ---
>
> Key: LUCENE-7794
> URL: https://issues.apache.org/jira/browse/LUCENE-7794
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7794.patch
>
>
> {{buildAndPushRelease.py}} runs {{ant clean test}} before building a release, 
> but does not run {{precommit}}.  As a result, it's possible to build releases 
> with source code that fails {{precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7793) smokeTestRelease.py should run documentation-lint

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7793:


Committing shortly.

> smokeTestRelease.py should run documentation-lint
> -
>
> Key: LUCENE-7793
> URL: https://issues.apache.org/jira/browse/LUCENE-7793
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Attachments: LUCENE-7793.patch, LUCENE-7793.patch
>
>
> {{smokeTestRelease.py}} runs {{ant validate}} on source releases, but this 
> doesn't include the {{documentation-lint}} target, which is part of {{ant 
> precommit}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-5405) Cloud graph view not usable by color-blind users - request small tweak

[JIRA]

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

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

Feel free to use this JIRA to add further accessability improvements, like the 
ones you propose, and/or the different shapes etc :-)

> Cloud graph view not usable by color-blind users - request small tweak
> --
>
> Key: SOLR-5405
> URL: https://issues.apache.org/jira/browse/SOLR-5405
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 4.5
>Reporter: Nathan Neulinger
>Assignee: Stefan Matheis (steffkes)
>  Labels: accessibility
> Attachments: 
> SOLR-5405-circle-triangleUp-triangleDown-diamond-square-dashedSquare.png, 
> SOLR-5405.patch
>
>
> Currently, the cloud view status is impossible to see easily on the graph 
> screen if you are color blind. (On of my coworkers.)
> Would it be possible to put " (X)" after the IP of the node where X is 
> [LARDFG] for the states?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10535) identify and remove unused test files

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10535:


Thanks Jason!

> identify and remove unused test files
> -
>
> Key: SOLR-10535
> URL: https://issues.apache.org/jira/browse/SOLR-10535
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10535.patch
>
>
> It appears that a number of test files are unused and hence could/should be 
> removed.
> Step 1:
> * identify potentially unused files e.g.
> {code}
> for ff in `find ./solr/core/src/test-files -name "*.xml"`
> do
>   file=`basename $ff`
>   git grep -l $file >/dev/null
>   rcode=$?
>   if [[ $rcode -ne 0 ]]
>   then
> echo $ff
>   fi
> done
> {code}
> Step 2:
> * remove the files concerned
> * run {{ant test}} to check if tests still pass
> * create patch or pull request
> Step 3:
> * optionally share any scripts or commands used in steps 1 and 2



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10535) identify and remove unused test files

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-10535:
--

Assignee: Christine Poerschke

> identify and remove unused test files
> -
>
> Key: SOLR-10535
> URL: https://issues.apache.org/jira/browse/SOLR-10535
> Project: Solr
>  Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10535.patch
>
>
> It appears that a number of test files are unused and hence could/should be 
> removed.
> Step 1:
> * identify potentially unused files e.g.
> {code}
> for ff in `find ./solr/core/src/test-files -name "*.xml"`
> do
>   file=`basename $ff`
>   git grep -l $file >/dev/null
>   rcode=$?
>   if [[ $rcode -ne 0 ]]
>   then
> echo $ff
>   fi
> done
> {code}
> Step 2:
> * remove the files concerned
> * run {{ant test}} to check if tests still pass
> * create patch or pull request
> Step 3:
> * optionally share any scripts or commands used in steps 1 and 2



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Requires subscription

[Christine Poerschke (BLOOMBERG/ LONDON)]

Hi Adeppa,

Thanks for your interest and welcome!

As Dorian mentioned https://wiki.apache.org/solr/HowToContribute has lots of 
information on how to get involved.

I saw Learning-to-Rank on your profile and so perhaps 
https://issues.apache.org/jira/browse/SOLR-10174 might be of interest as a 
(hopefully) not too difficult first issue to get started with.

You could also browse issues in JIRA to see if anything particularly matches 
your interests, browse generally or search-and-browse e.g. with these search 
criteria: project=SOLR AND status not in (Resolved,Closed) AND labels=newbie

Hope that helps.

Regards,

Christine

From: dev@lucene.apache.org At: 04/28/17 13:03:37
To: dev@lucene.apache.org
Subject: Re: Requires subscription

What do you mean subscription ?

Have you seen: https://wiki.apache.org/solr/HowToContribute?

On Fri, Apr 28, 2017 at 1:01 PM, Adi  wrote:

Hi Team,

I would interest in contribution of solr development ,please provide 
subscription and instructions

Thanks in advance. 

For details about me please look my LinkedIn profile 

https://www.linkedin.com/in/adeppa-thondur-b2605286/


Thanks
Adeppa
+91-7411548006  

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1270 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:132)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:159)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:116)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:107)
  at sun.reflect.GeneratedConstructorAccessor217.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:784)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:846)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1101)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:971)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:854)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:959)  at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:594)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:132)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:159)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:116)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:107)
at sun.reflect.GeneratedConstructorAccessor217.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:784)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:846)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1101)
at org.apache.solr.core.SolrCore.(SolrCore.java:971)
at org.apache.solr.core.SolrCore.(SolrCore.java:854)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:959)
at 
org.apache.solr.core.CoreContainer.lambda$load$7(CoreContainer.java:594)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([83F659404B0CB1E2]: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.teardownTestCases(SolrTestCaseJ4.java:302)
at sun.reflect.GeneratedMethodAccessor16.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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 

[jira] [Commented] (SOLR-10174) fix 3x in @Ignore TestLTRReRankingPipeline and TestMultipleAdditiveTreesModel

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-10174:


Some more details on the steps involved here:
{code}
# optional: add a note to this ticket just to say that you plan to work on 
this, so as to collaborate with anyone else who might also plan to do the same.

# checkout master branch and probably create a working branch e.g. 'git 
checkout -b master-solr-10174'
# baseline compile e.g. 'ant compile'

# run all the ltr tests e.g.
cd solr/contrib/ltr
ant test

# remove the @Ignore annotation(s)

# re-run the changed test(s) individually

# once
ant test -Dtestcase=TestLTRReRankingPipeline

# or multiple times e.g.
ant beast -Dbeast.iters=10 -Dtestcase=TestLTRReRankingPipeline

# now the fun part, investigate any test failures
# make changes
# re-run test(s)

# share findings on this ticket and/or changes e.g. via patch or github pull 
request
{code}

And of course throughout, feel free to ask questions :-)

> fix 3x in @Ignore TestLTRReRankingPipeline and TestMultipleAdditiveTreesModel
> -
>
> Key: SOLR-10174
> URL: https://issues.apache.org/jira/browse/SOLR-10174
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>
> https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/TestLTRReRankingPipeline.java#L105
> https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/TestLTRReRankingPipeline.java#L162
> https://github.com/apache/lucene-solr/blob/master/solr/contrib/ltr/src/test/org/apache/solr/ltr/model/TestMultipleAdditiveTreesModel.java#L82



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Why no composite primary-key in lucene ?

[Dorian Hoxha]

Hi friends,

I searched for this on mailing-list,issues etc, but couldn't find any post.

So, why not have the possibility of  ?
Or nobody cared enough to implement it ? Or no gains ?

Cause I've had many cases (on es/solr) that the 'id' was a
"tenant_id:project_id:item_id" and I still had those values as separate
fields, so duplicating. And in many cases values were numbers so also lower
storage compared to one big string.

Am I missing something(s) ?

Regards,
Dorian

Re: Requires subscription

[Dorian Hoxha]

What do you mean subscription ?

Have you seen: https://wiki.apache.org/solr/HowToContribute?

On Fri, Apr 28, 2017 at 1:01 PM, Adi  wrote:

> Hi Team,
>
> I would interest in contribution of solr development ,please provide
> subscription and instructions
>
> Thanks in advance.
>
> For details about me please look my LinkedIn profile
>
> https://www.linkedin.com/in/adeppa-thondur-b2605286/
>
>
> Thanks
> Adeppa
> +91-7411548006 <+91%2074115%2048006>
>

Requires subscription

[Adi]

Hi Team,

I would interest in contribution of solr development ,please provide
subscription and instructions

Thanks in advance.

For details about me please look my LinkedIn profile

https://www.linkedin.com/in/adeppa-thondur-b2605286/


Thanks
Adeppa
+91-7411548006

[JENKINS] Lucene-Solr-Tests-6.5 - Build # 32 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.5/32/

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

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [HdfsTransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)  
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)  at 
org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)  at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
  at sun.reflect.GeneratedConstructorAccessor206.newInstance(Unknown Source)  
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:423)  at 
org.apache.solr.core.SolrCore.createInstance(SolrCore.java:761)  at 
org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:823)  at 
org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1071)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:936)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:831)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)  at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [HdfsTransactionLog]
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.HdfsTransactionLog
at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
at 
org.apache.solr.update.HdfsTransactionLog.(HdfsTransactionLog.java:130)
at org.apache.solr.update.HdfsUpdateLog.init(HdfsUpdateLog.java:203)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:137)
at org.apache.solr.update.UpdateHandler.(UpdateHandler.java:94)
at 
org.apache.solr.update.DirectUpdateHandler2.(DirectUpdateHandler2.java:108)
at sun.reflect.GeneratedConstructorAccessor206.newInstance(Unknown 
Source)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:761)
at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:823)
at org.apache.solr.core.SolrCore.initUpdateHandler(SolrCore.java:1071)
at org.apache.solr.core.SolrCore.(SolrCore.java:936)
at org.apache.solr.core.SolrCore.(SolrCore.java:831)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:918)
at 
org.apache.solr.core.CoreContainer.lambda$load$5(CoreContainer.java:553)
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)


at __randomizedtesting.SeedInfo.seed([DF7EBD06E0E4A3DB]: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.teardownTestCases(SolrTestCaseJ4.java:301)
at sun.reflect.GeneratedMethodAccessor31.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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:870)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at