[jira] [Commented] (SOLR-8711) Upgrade Carrot2 clustering dependency to 3.12.0

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on SOLR-8711:
---

Interesting... I ran precommit before committing and it passed (?). Looking 
into it.

> Upgrade Carrot2 clustering dependency to 3.12.0
> ---
>
> Key: SOLR-8711
> URL: https://issues.apache.org/jira/browse/SOLR-8711
> Project: Solr
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master
>
>




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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.lucene.search.TestPointQueries.testRandomBinaryTiny

Error Message:
maxMBSortInHeap=3.226682828407023 only allows for maxPointsSortInHeap=1601, but 
this is less than maxPointsInLeafNode=1935; either increase maxMBSortInHeap or 
decrease maxPointsInLeafNode

Stack Trace:
java.lang.IllegalArgumentException: maxMBSortInHeap=3.226682828407023 only 
allows for maxPointsSortInHeap=1601, but this is less than 
maxPointsInLeafNode=1935; either increase maxMBSortInHeap or decrease 
maxPointsInLeafNode
at 
__randomizedtesting.SeedInfo.seed([87BD74BE71C4C012:290419FD9916B9AB]:0)
at org.apache.lucene.util.bkd.BKDWriter.(BKDWriter.java:167)
at 
org.apache.lucene.codecs.lucene60.Lucene60PointWriter.writeField(Lucene60PointWriter.java:88)
at 
org.apache.lucene.index.PointValuesWriter.flush(PointValuesWriter.java:64)
at 
org.apache.lucene.index.DefaultIndexingChain.writePoints(DefaultIndexingChain.java:172)
at 
org.apache.lucene.index.DefaultIndexingChain.flush(DefaultIndexingChain.java:107)
at 
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:423)
at 
org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
at 
org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:614)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2815)
at 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:366)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:305)
at 
org.apache.lucene.search.TestPointQueries.verifyBinary(TestPointQueries.java:513)
at 
org.apache.lucene.search.TestPointQueries.doTestRandomBinary(TestPointQueries.java:422)
at 
org.apache.lucene.search.TestPointQueries.testRandomBinaryTiny(TestPointQueries.java:378)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
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 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 861 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val modified' for path 'response/params/y/c' 
full output: {   "responseHeader":{ "status":0, "QTime":0},   
"response":{ "znodeVersion":0, "params":{"x":{ "a":"A val", 
"b":"B val", "":{"v":0}

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val modified' for 
path 'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0}
at 
__randomizedtesting.SeedInfo.seed([3D51E2C3AC58DFEA:B505DD1902A4B212]: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:456)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:200)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-6227) Add BooleanClause.Occur.FILTER

[yuejianjun (JIRA)]

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

yuejianjun commented on LUCENE-6227:


 [~jpountz] 

 Declarationorg.apache.lucene.search.QueryWrapperFilter
@Deprecated
Deprecated. You can use Query objects directly for filtering by using 
BooleanClause.Occur.FILTER clauses in a BooleanQuery.

BooleanClause.Occur.FILTER is a BooleanClause.Occur.MUST of no score 

QueryWrapperFilter is a OR query
BooleanClause.Occur.FILTER  is a AND query

why QueryWrapperFilter is replaced with the BooleanClause.Occur.FILTER ?







> Add BooleanClause.Occur.FILTER
> --
>
> Key: LUCENE-6227
> URL: https://issues.apache.org/jira/browse/LUCENE-6227
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.1, master
>
> Attachments: LUCENE-6227.patch, LUCENE-6227.patch, LUCENE-6227.patch, 
> LUCENE-6227.patch, LUCENE-6227.patch
>
>
> Now that we have weight-level control of whether scoring is needed or not, we 
> could add a new clause type to BooleanQuery. It would behave like MUST exept 
> that it would not participate in scoring.
> Why do we need it given that we already have FilteredQuery? The idea is that 
> by having a single query that performs conjunctions, we could potentially 
> take better decisions. It's not ready to replace FilteredQuery yet as 
> FilteredQuery has handling of random-access filters that BooleanQuery 
> doesn't, but it's a first step towards that direction and eventually 
> FilteredQuery would just rewrite to a BooleanQuery.
> I've been calling this new clause type FILTER so far, but feel free to 
> propose a better name.



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

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

org.apache.lucene.index.sorting.Sorter

[Hu Thomas Pan]

Hi,

In Lucene 4.x, there is the class org.apache.lucene.index.sorting.Sorter.
In Lucene 5, however, the class seems to be disappeared. Do we know how to
migrate existing Sorter classes from Lucene 4 to Lucene 5?


Best,
Thomas


--
The journey of a thousand miles begins with one step. -- Lao Tzu
Do not go where the path may lead, go instead where there is no path and
leave a trail. -- Ralph Waldo Emerson

[jira] [Commented] (SOLR-8698) params.json should have a way to specify appends and invariants

[ASF subversion and git services (JIRA)]

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

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

Commit 9ce2d0d25df7d619ef9ea16a8b5e7f5341d3fc71 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ce2d0d ]

SOLR-8698: params.json can now have appends and invariants as well. 'useParams' 
specified in the requestHandler is always applied


> params.json should have a way to specify appends and invariants
> ---
>
> Key: SOLR-8698
> URL: https://issues.apache.org/jira/browse/SOLR-8698
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8698.patch
>
>
> params.json only supports defaults today. It should be possible to add 
> {{appends}} and {{invariants}}
> for example
> {code}
> {
> "params":{
> "my_param_set" : {
> "a":"A",
> "b" :"B",
> "_appends_" : {
> "c": "C"
> },
> "_invariants_":{
> "d" : "D"
> }}
> }
> {code}
> In this case variables {{a}} and {{b}} are defaults, {{c}} is appends and 
> {{d}} is invariants
> The fact that we can have invariants and appends means that if a useParam is 
> specified with the component, it should not be overridable from the request
> So, this introduces a back incompat change



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

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

Commit c0b91afb94387b59eaca699831fedf015879c96b in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0b91af ]

SOLR-8029: Merging changes from master


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: master
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



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

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[ASF subversion and git services (JIRA)]

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

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

Commit ddeb53dd91cb9370f0f22a4ccdcf33f1e267bf79 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ddeb53d ]

SOLR-8029: Merging changes from master


> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: master
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: master
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



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

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

[jira] [Commented] (SOLR-8719) Rename the Jar loading classes to load any blobs

[ASF subversion and git services (JIRA)]

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

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

Commit 4d9d0c0011de8653fbe404af702e822883e8fb13 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4d9d0c0 ]

SOLR-8719 renamed classes to make their usage generic


> Rename the Jar loading classes to load any  blobs
> -
>
> Key: SOLR-8719
> URL: https://issues.apache.org/jira/browse/SOLR-8719
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8719.patch
>
>
> The classes used to load jars from blob store can be used for loading any 
> blobs. 
> * JarRepository ->BlobRepository
> * JarContentRef -> BlobContentRef
> * JarContent -> BlobContent



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

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

[jira] [Commented] (SOLR-8718) Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8718: Corrects location for note for SOLR-8666 in solr/CHANGES.txt


> Note for SOLR-8666 in solr/CHANGES.txt was put in the wrong location
> 
>
> Key: SOLR-8718
> URL: https://issues.apache.org/jira/browse/SOLR-8718
> Project: Solr
>  Issue Type: Task
>Reporter: Dennis Gove
>Assignee: Dennis Gove
>Priority: Trivial
> Fix For: master
>
> Attachments: SOLR-8718.patch
>
>
> The note for SOLR-8666
> {code}
> * SOLR-8666: Adds header 'zkConnected' to response of SearchHandler and 
> PingRequestHandler to notify the client when a connection to zookeeper has 
> been lost and there is a possibility of stale data on the node the request is 
> coming from. (Keith Laban, Dennis Gove)
> {code}
> was put under bug fixes but it should have been put under improvements. This 
> ticket is to track the move of that note.



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

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

[jira] [Commented] (SOLR-7362) TestReqParamsAPI failing in jenkins

[ASF subversion and git services (JIRA)]

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

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

Commit e069d31086116fa293f40155f9e96e0da9912c8f in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e069d31 ]

SOLR-7362


> TestReqParamsAPI failing in jenkins
> ---
>
> Key: SOLR-7362
> URL: https://issues.apache.org/jira/browse/SOLR-7362
> Project: Solr
>  Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>
> {noformat}
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4645/
> Java: 32bit/jdk1.8.0_40 -server -XX:+UseSerialGC
> 1 tests failed.
> FAILED:  org.apache.solr.handler.TestReqParamsAPI.test
> Error Message:
> Could not get expected value  'null' for path 'response/params/y/p' full 
> output: {   "responseHeader":{ "status":0, "QTime":1},   "response":{ 
> "znodeVersion":3, "params":{   "x":{ "a":"A val", 
> "b":"B val", "":{"v":0}},   "y":{ "p":"P val", 
> "q":"Q val", "":{"v":0}
> Stack Trace:
> java.lang.AssertionError: Could not get expected value  'null' for path 
> 'response/params/y/p' full output: {
>   "responseHeader":{
> "status":0,
> "QTime":1},
>   "response":{
> "znodeVersion":3,
> "params":{
>   "x":{
> "a":"A val",
> "b":"B val",
> "":{"v":0}},
>   "y":{
> "p":"P val",
> "q":"Q val",
> "":{"v":0}
> at 
> __randomizedtesting.SeedInfo.seed([D0DB18ECE165C505:588F27364F99A8FD]: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:405)
> at 
> org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:236)
> at 
> org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:71)
> {noformat}



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

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

[jira] [Commented] (SOLR-8666) Add header to SearchHandler to indicate whether solr is connection to zk

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8718: Corrects location for note for SOLR-8666 in solr/CHANGES.txt


> Add header to SearchHandler to indicate whether solr is connection to zk
> 
>
> Key: SOLR-8666
> URL: https://issues.apache.org/jira/browse/SOLR-8666
> Project: Solr
>  Issue Type: Improvement
>Reporter: Keith Laban
>Assignee: Dennis Gove
> Attachments: SOLR-8666.patch
>
>
> Currently solr update requests error out if a zookeeper check fails, however 
> SearchHandler does not do these checks. As a result, if a request is sent to 
> a node which should be part of a SolrCloud but is not connected to zookeeper 
> and thinks that its Active, it's possible the response is composed of stale 
> data. 
> The purpose of this header is to allow the client to decide whether or not 
> the result data should be considered valid.
> This patch also returns the {{zkConnected}} header in the ping handler to 
> allow external health checks to use this information. 
> See [SOLR-8599] for an example of when this situation can arise. 



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

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

[jira] [Commented] (SOLR-8711) Upgrade Carrot2 clustering dependency to 3.12.0

[ASF subversion and git services (JIRA)]

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

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

Commit a77d67a926ea16b90b39c959099e27c1b749ba7f in lucene-solr's branch 
refs/heads/apiv2 from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a77d67a ]

SOLR-8711: follow-up removal of dependencies no longer used.


> Upgrade Carrot2 clustering dependency to 3.12.0
> ---
>
> Key: SOLR-8711
> URL: https://issues.apache.org/jira/browse/SOLR-8711
> Project: Solr
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master
>
>




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

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

[jira] [Commented] (SOLR-8522) ImplicitSnitch to support IPv4 fragment tags

[ASF subversion and git services (JIRA)]

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

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

Commit cf964326309feb7a5a41a3e4f22cad073807a097 in lucene-solr's branch 
refs/heads/apiv2 from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf96432 ]

SOLR-8522: Make it possible to use ip fragments in replica placement rules , 
such as ip_1, ip_2 etc


> ImplicitSnitch to support IPv4 fragment tags
> 
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15980 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15980/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Could not register as the leader because creating the ephemeral registration 
node in ZooKeeper failed

Stack Trace:
org.apache.solr.common.SolrException: Could not register as the leader because 
creating the ephemeral registration node in ZooKeeper failed
at 
__randomizedtesting.SeedInfo.seed([2232E005137F7870:FC6167F209E78D81]:0)
at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:212)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:173)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:310)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:219)
at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:181)
at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:841)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

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

[Apache Jenkins Server]

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

143 tests failed.
FAILED:  org.apache.solr.client.solrj.SolrExampleBinaryTest.testExampleConfig

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:54341/solr/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:54341/solr/collection1
at 
__randomizedtesting.SeedInfo.seed([11656E8AC2FFD59B:A6487A1205F83342]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.client.solrj.SolrExampleTests.testExampleConfig(SolrExampleTests.java:98)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

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

[Policeman Jenkins Server]

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

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([37C722B5967B6657:ABA16D54DB7385F2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:51526/u_/rh/collection1: Carrot2 
clustering failed

Stack Trace:

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+106) - Build # 15979 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15979/
Java: 64bit/jdk-9-ea+106 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.lucene.search.TestRegexpQuery.testRegexComplement

Error Message:
8

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 8
at 
__randomizedtesting.SeedInfo.seed([D3815EEB4B018CAD:3D00FCA50E5DEA50]:0)
at 
org.apache.lucene.util.automaton.MinimizationOperations.minimize(MinimizationOperations.java:235)
at 
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:524)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
at org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
at org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:109)
at org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:79)
at org.apache.lucene.search.RegexpQuery.(RegexpQuery.java:69)
at 
org.apache.lucene.search.TestRegexpQuery.regexQueryNrHits(TestRegexpQuery.java:72)
at 
org.apache.lucene.search.TestRegexpQuery.testRegexComplement(TestRegexpQuery.java:94)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)




Build Log:
[...truncated 1109 lines...]
   [junit4] Suite: org.apache.lucene.search.TestRegexpQuery
   [junit4]   2> NOTE: 

[jira] [Updated] (LUCENE-7046) Remove PointInRectQuery

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7046:

Attachment: LUCENE-7046.patch

A couple more cleanups:
* Add TestLatLonPoint with some basic stuff
* Add LatLonPoint.toString() so it doesn't print gibberish bytes.

> Remove PointInRectQuery
> ---
>
> Key: LUCENE-7046
> URL: https://issues.apache.org/jira/browse/LUCENE-7046
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7046.patch, LUCENE-7046.patch
>
>
> This query is the same as a 2D PointRangeQuery, only slower, since it needs 
> to do a bunch of decoding.
> Instead we should just form PointRangeQuery's for bounding boxes for 
> LatLonPoints: that just works on byte ranges.



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

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

[jira] [Updated] (LUCENE-7046) Remove PointInRectQuery

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7046:

Attachment: LUCENE-7046.patch

Here's a patch. I tried to do some cleanups (more iteration here is needed!!!) 
to LatLonPoint in general as well.


> Remove PointInRectQuery
> ---
>
> Key: LUCENE-7046
> URL: https://issues.apache.org/jira/browse/LUCENE-7046
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7046.patch
>
>
> This query is the same as a 2D PointRangeQuery, only slower, since it needs 
> to do a bunch of decoding.
> Instead we should just form PointRangeQuery's for bounding boxes for 
> LatLonPoints: that just works on byte ranges.



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

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

[jira] [Created] (LUCENE-7046) Remove PointInRectQuery

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7046:
---

 Summary: Remove PointInRectQuery
 Key: LUCENE-7046
 URL: https://issues.apache.org/jira/browse/LUCENE-7046
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This query is the same as a 2D PointRangeQuery, only slower, since it needs to 
do a bunch of decoding.

Instead we should just form PointRangeQuery's for bounding boxes for 
LatLonPoints: that just works on byte ranges.





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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15978 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15978/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Exactly one shard should have changed, instead: [shard2, shard1] 
nodes=([core_node3(shard2), core_node2(shard1), core_node1(shard2), 
core_node4(shard1)]) expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: Exactly one shard should have changed, instead: 
[shard2, shard1] nodes=([core_node3(shard2), core_node2(shard1), 
core_node1(shard2), core_node4(shard1)]) expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([13B26F4D9DD81124:9BE6509733247CDC]: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.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 860 - Still Failing

[Apache Jenkins Server]

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

39 tests failed.
FAILED:  org.apache.solr.TestDistributedGrouping.test

Error Message:
IOException occured when talking to server at: 
https://127.0.0.1:53079/pj_/zc/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:53079/pj_/zc/collection1
at 
__randomizedtesting.SeedInfo.seed([98CEAF1CC3C598FA:109A90C66D39F502]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:591)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:895)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:858)
at 
org.apache.solr.client.solrj.SolrClient.deleteByQuery(SolrClient.java:873)
at 
org.apache.solr.BaseDistributedSearchTestCase.del(BaseDistributedSearchTestCase.java:544)
at 
org.apache.solr.TestDistributedGrouping.test(TestDistributedGrouping.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:990)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_72) - Build # 5640 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5640/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseParallelGC

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([72FC5EE795B4B08B:EE9A1106D8BC532E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:65331/rfa/dd/collection1: Carrot2 
clustering failed

Stack Trace:

[jira] [Updated] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski updated SOLR-8110:
--
Attachment: SOLR-8110.patch

Not ready for review yet.  Just putting it up here as backup (or in case I'm 
going down a path that's completely wrong).  A few notes:

- added verification checks in {{IndexSchema}} and {{DocumentBuilder}}.  These 
depend on the luceneMatchVersion being >= 6.0.  Easy to change if we want this 
to be configured differently.
- no tests yet.  Plan on adding them shortly.

Hope to resume work on this tomorrow.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
> Attachments: SOLR-8110.patch
>
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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

Re: Rolling upgrades from 5.x to 6.0

[Mark Miller]

Of course there is nothing saying a new discussion changes all that and we
choose to try and support rolling upgrades over major releases until we
decide to have a *break* release or something. I'm just saying what is.

Rolling upgrades forever puts us in a tight spot like Lucene was in with
API and runtime behavior previously.

At the same time, we probably will often go a couple release without doing
things that require major breaks.

- Mark
On Tue, Feb 23, 2016 at 8:20 PM Mark Miller  wrote:

> I'm not confident it won't work. I'm confident that it's not tested and
> any dev in any change someone is not paying attention to can make it not
> work. So to say it will work or to even count on it working is silly. The
> are tons of behavior changes beyond what's in ZK that could mess with
> rolling upgrades. We find issues doing non rolling upgrades on *point*
> releases in my experience.
>
> The only way you will ever know is to test it out when the release
> happens, and even then, not every issue is easily caught by a simple test.
> Commands can come in during the rolling upgrade, certain features can be
> broken, etc, etc.
>
> I would like to support rolling updates on point releases, that's def a
> goal, even that is still a bit of prayer as it's not properly tested and it
> can depend on what version you coming from and going to.
>
> - Mark
>
>
> On Tue, Feb 23, 2016 at 1:54 PM Shai Erera  wrote:
>
>> Mark, I understand that we currently don't have any other promises :). I
>> asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to
>> refer to /solr_collections instead of /collections" (I wish it would be
>> *that* trivial :)).
>>
>> If you don't have a list that's fine. You just sounded really confident
>> that 5.x -> 6.0 won't work, so I hoped you also can tell why.
>>
>> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0)
>> can read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat
>> it as a thing we want to support. That's just my opinion though.
>>
>> Shai
>>
>> On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta 
>> wrote:
>>
>>> For that, we provide an index upgrade tool with 6.0, like we did in 5.0.
>>>
>>> On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob  wrote:
>>>
 A 5.x Solr could have indices that are still in a 4.x format, right?
 That would be one point where it's not "fully back compatible."

 On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  wrote:

> Wait, what do you mean by Lucene not supporting back-compat? Lucene
> 6.0 will be able to read Lucene 5.0 indexes. The only thing that we don't
> guarantee support for is API, which isn't the case here.
>
> So what's in 6.0 that can't read a 5.x Solr. It can't be the index
> format since that's supported by Lucene. Is it the ZK format? If so, 
> should
> we try to "version" it so that a 6.0 code can read a 5.x version? Is it
> something else / additionally?
>
> Shai
>
> On Tue, Feb 23, 2016 at 7:06 PM Mark Miller 
> wrote:
>
>> Yes, we are allowed wide berth to break backcompat across major
>> versions and we cannot support rolling updates for the same reason Lucene
>> stopped trying to do full back compat across major versions. Without, we
>> can't properly innovate in the code or fix past mistakes and would also
>> burn lots of cycles we don't have on crazy, "sophisticated" back compat
>> layers.
>>
>> We don't even really support rolling updates between major versions.
>> We make a simple best effort. Until we have tests, it's going to be a 
>> shaky
>> affair. There is a JIRA open now working on some testing I believe.
>>
>> - Mark
>>
>> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:
>>
>>> Hi
>>>
>>> I read in few emails/issue comments that rolling upgrades from 5.x
>>> to 6.0 isn't supported. Is it really the case? Does it mean that anyone 
>>> who
>>> has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>>>
>>> If this is really the case, can someone list the known
>>> issues/reasons for that?Can we do something about it, e.g. in a 
>>> subsequent
>>> 5.6 release that will allow rolling upgrades (like the 5.4.1 fix that
>>> allowed rolling upgrades from pre-5.4 to 5.4)?
>>>
>>> I feel it's odd (and may not be taken well) if we force users to
>>> take down their entire cluster if they want to upgrade to 6.0. 
>>> Definitely
>>> feels like it will also slow down 6.0 adoption.
>>>
>>> And if nothing can be done, what's the recommended way then to
>>> upgrade to 6.0?
>>>
>>> Shai
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
>

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

Re: Rolling upgrades from 5.x to 6.0

[Mark Miller]

I'm not confident it won't work. I'm confident that it's not tested and any
dev in any change someone is not paying attention to can make it not work.
So to say it will work or to even count on it working is silly. The are
tons of behavior changes beyond what's in ZK that could mess with rolling
upgrades. We find issues doing non rolling upgrades on *point* releases in
my experience.

The only way you will ever know is to test it out when the release happens,
and even then, not every issue is easily caught by a simple test. Commands
can come in during the rolling upgrade, certain features can be broken,
etc, etc.

I would like to support rolling updates on point releases, that's def a
goal, even that is still a bit of prayer as it's not properly tested and it
can depend on what version you coming from and going to.

- Mark

On Tue, Feb 23, 2016 at 1:54 PM Shai Erera  wrote:

> Mark, I understand that we currently don't have any other promises :). I
> asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to
> refer to /solr_collections instead of /collections" (I wish it would be
> *that* trivial :)).
>
> If you don't have a list that's fine. You just sounded really confident
> that 5.x -> 6.0 won't work, so I hoped you also can tell why.
>
> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can
> read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as
> a thing we want to support. That's just my opinion though.
>
> Shai
>
> On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta 
> wrote:
>
>> For that, we provide an index upgrade tool with 6.0, like we did in 5.0.
>>
>> On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob  wrote:
>>
>>> A 5.x Solr could have indices that are still in a 4.x format, right?
>>> That would be one point where it's not "fully back compatible."
>>>
>>> On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  wrote:
>>>
 Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
 will be able to read Lucene 5.0 indexes. The only thing that we don't
 guarantee support for is API, which isn't the case here.

 So what's in 6.0 that can't read a 5.x Solr. It can't be the index
 format since that's supported by Lucene. Is it the ZK format? If so, should
 we try to "version" it so that a 6.0 code can read a 5.x version? Is it
 something else / additionally?

 Shai

 On Tue, Feb 23, 2016 at 7:06 PM Mark Miller 
 wrote:

> Yes, we are allowed wide berth to break backcompat across major
> versions and we cannot support rolling updates for the same reason Lucene
> stopped trying to do full back compat across major versions. Without, we
> can't properly innovate in the code or fix past mistakes and would also
> burn lots of cycles we don't have on crazy, "sophisticated" back compat
> layers.
>
> We don't even really support rolling updates between major versions.
> We make a simple best effort. Until we have tests, it's going to be a 
> shaky
> affair. There is a JIRA open now working on some testing I believe.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:
>
>> Hi
>>
>> I read in few emails/issue comments that rolling upgrades from 5.x to
>> 6.0 isn't supported. Is it really the case? Does it mean that anyone who
>> has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>>
>> If this is really the case, can someone list the known issues/reasons
>> for that?Can we do something about it, e.g. in a subsequent 5.6 release
>> that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling
>> upgrades from pre-5.4 to 5.4)?
>>
>> I feel it's odd (and may not be taken well) if we force users to take
>> down their entire cluster if they want to upgrade to 6.0. Definitely 
>> feels
>> like it will also slow down 6.0 adoption.
>>
>> And if nothing can be done, what's the recommended way then to
>> upgrade to 6.0?
>>
>> Shai
>>
> --
> - Mark
> about.me/markrmiller
>

>>>
>>
>>
>> --
>> Anshum Gupta
>>
> --
- Mark
about.me/markrmiller

[jira] [Commented] (SOLR-8420) Date statistics: sumOfSquares overflows long

[JIRA]

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

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

Thanks [~tomsolr], patch looks good to me, will commit shortly

> Date statistics: sumOfSquares overflows long
> 
>
> Key: SOLR-8420
> URL: https://issues.apache.org/jira/browse/SOLR-8420
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.4
>Reporter: Tom Hill
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, StdDev.java
>
>
> The values for Dates are large enough that squaring them overflows a "long" 
> field. This should be converted to a double. 
> StatsValuesFactory.java, line 755 DateStatsValues#updateTypeSpecificStats Add 
> a cast to double 
> sumOfSquares += ( (double)value * value * count);



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

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

[jira] [Commented] (SOLR-8711) Upgrade Carrot2 clustering dependency to 3.12.0

[JIRA]

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

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

CarrotClusteringEngineTest fails now, probably related to this change?

> Upgrade Carrot2 clustering dependency to 3.12.0
> ---
>
> Key: SOLR-8711
> URL: https://issues.apache.org/jira/browse/SOLR-8711
> Project: Solr
>  Issue Type: Improvement
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master
>
>




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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 15977 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15977/
Java: 32bit/jdk-9-ea+106 -server -XX:+UseParallelGC

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([B632785AA648BFC3:2A5437BBEB405C66]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:42561/hq/collection1: Carrot2 clustering 
failed

Stack Trace:

Re: Rolling upgrades from 5.x to 6.0

[Jan Høydahl]

> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can 
> read a 5.0 (or 6.0) Solr.

Agree. A lack of promise for major version back compat gives us the freedom to 
do crazy breaking changes - but it does not prevent us from doing best effort 
attempts of a smooth transition for those that want to attempt.


To contribute constructively to the discussion, here is the current 6.0 upgrade 
instructions from CHANGES.txt, which may give some hints on possible hurdles:

Upgrading from Solr 5.x
--

* The deprecated SolrServer and subclasses have been removed, use SolrClient
  instead.

* The deprecated  configuration in solrconfig.xml has been removed.
  Please remove it from solrconfig.xml.

* SolrClient.shutdown() has been removed, use SolrClient.close() instead.

* The deprecated zkCredientialsProvider element in solrcloud section of solr.xml
  is now removed. Use the correct spelling (zkCredentialsProvider) instead.

* SOLR-7957: internal/expert - ResultContext was significantly changed and 
expanded
  to allow for multiple full query results (DocLists) per Solr request.
  TransformContext was rendered redundant and was removed. (yonik)

* Several changes have been made regarding the "Similarity" used in Solr, in 
order to provide
  better default behavior for new users.  There are 3 key impacts of these 
changes on existing
  users who upgrade:
  * DefaultSimilarityFactory has been removed. If you currently have 
DefaultSimilarityFactory explicitly
referenced in your schema.xml, edit your config to use the functionally 
identical
ClassicSimilarityFactory.  See SOLR-8239 for more details.
  * The implicit default Similarity used when no  is configured in 
schema.xml has
been changed to SchemaSimilarityFactory.  Users who wish to preserve 
back-compatible behavior should
either explicitly configure ClassicSimilarityFactory, or ensure that the 
luceneMatchVersion
for the collection is less then 6.0.  See SOLR-8270 + SOLR-8271 for details.
  * SchemaSimilarityFactory has been modified to use BM25Similarity as the 
default for fieldTypes that
do not explicitly declare a Similarity.  The legacy behavior of using 
ClassicSimilarity as the
default will occur if the luceneMatchVersion for the collection is less 
then 6.0, or the
'defaultSimFromFieldType' configuration option may be used to specify any 
default of your choosing.
See SOLR-8261 + SOLR-8329 for more details.

* If your solrconfig.xml file doesn't explicitly mention the schemaFactory to 
use then Solr will choose
  the ManagedIndexSchemaFactory by default. Previously it would have chosen 
ClassicIndexSchemaFactory.
  This means that the Schema APIs ( //schema ) are enabled and the 
schema is mutable.
  When Solr starts your schema.xml file will be renamed to managed-schema. If 
you want to retain the old behaviour
  then please ensure that the solrconfig.xml explicitly uses the 
ClassicIndexSchemaFactory :
   or your luceneMatchVersion 
in the solrconfig.xml is less than 6.0

* SolrIndexSearcher.QueryCommand and QueryResult were moved to their own 
classes. If you reference them
  in your code, you should import them under o.a.s.search (or use your IDE's 
"Organize Imports").

* SOLR-8698: 'useParams' attribute specified in request handler cannot be 
overridden from request params

Looks like many of these changes would be possible to prepare for by modifying 
5.x config before upgrading, e.g. the schema factory etc.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 23. feb. 2016 kl. 19.54 skrev Shai Erera :
> 
> Mark, I understand that we currently don't have any other promises :). I 
> asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to 
> refer to /solr_collections instead of /collections" (I wish it would be 
> *that* trivial :)).
> 
> If you don't have a list that's fine. You just sounded really confident that 
> 5.x -> 6.0 won't work, so I hoped you also can tell why.
> 
> I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can 
> read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as a 
> thing we want to support. That's just my opinion though.
> 
> Shai
> 
> On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta  > wrote:
> For that, we provide an index upgrade tool with 6.0, like we did in 5.0.
> 
> On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob  > wrote:
> A 5.x Solr could have indices that are still in a 4.x format, right? That 
> would be one point where it's not "fully back compatible."
> 
> On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  > wrote:
> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0 will 
> be able to read Lucene 5.0 indexes. The only thing that we don't guarantee 
> support for is API, 

[jira] [Created] (SOLR-8725) Invalid name error with core names with hyphens

[Chris Beer (JIRA)]

Chris Beer created SOLR-8725:


 Summary: Invalid name error with core names with hyphens
 Key: SOLR-8725
 URL: https://issues.apache.org/jira/browse/SOLR-8725
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.5
Reporter: Chris Beer


In SOLR-8642, hyphens are no longer considered valid identifiers for cores (and 
collections?). Our solr instance was successfully using hyphens in our core 
names, and our affected cores now error with:

marc-profiler_shard1_replica1: 
org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: 
Invalid name: 'marc-profiler_shard1_replica1' Identifiers must consist entirely 
of periods, underscores and alphanumerics

Before starting to rename all of our collections, I wonder if this decision 
could be revisited to be backwards compatible with previously created 
collections.




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

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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[JIRA]

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

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

bq. A dedicated config option might be better than luceneMatchVersion, but I'm 
OK either way.
Both. We introduce a {{-Dsolr.enforceStrictIdentifiers}} and let 
luceneMatchVersion decide the default value if not explicitly set.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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

[jira] [Updated] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-8724:
-
Description: Zookeeper 3.4.8 was released a few days ago - we should 
upgrade.  (was: Zookeeper 3.4.8 was released a few weeks ago - we should 
upgrade.)

> Upgrade Zookeeper to 3.4.8
> --
>
> Key: SOLR-8724
> URL: https://issues.apache.org/jira/browse/SOLR-8724
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master
>
>
> Zookeeper 3.4.8 was released a few days ago - we should upgrade.



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

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

[jira] [Created] (SOLR-8724) Upgrade Zookeeper to 3.4.8

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-8724:


 Summary: Upgrade Zookeeper to 3.4.8
 Key: SOLR-8724
 URL: https://issues.apache.org/jira/browse/SOLR-8724
 Project: Solr
  Issue Type: Bug
Reporter: Steve Rowe
 Fix For: master


Zookeeper 3.4.8 was released a few weeks ago - we should upgrade.



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

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

[jira] [Assigned] (SOLR-8420) Date statistics: sumOfSquares overflows long

[JIRA]

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

Tomás Fernández Löbbe reassigned SOLR-8420:
---

Assignee: Tomás Fernández Löbbe

> Date statistics: sumOfSquares overflows long
> 
>
> Key: SOLR-8420
> URL: https://issues.apache.org/jira/browse/SOLR-8420
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.4
>Reporter: Tom Hill
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, StdDev.java
>
>
> The values for Dates are large enough that squaring them overflows a "long" 
> field. This should be converted to a double. 
> StatsValuesFactory.java, line 755 DateStatsValues#updateTypeSpecificStats Add 
> a cast to double 
> sumOfSquares += ( (double)value * value * count);



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

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

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

[Policeman Jenkins Server]

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

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([E754108EE395C0A3:7B325F6FAE9D2306]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:37944/lz/collection1: Carrot2 clustering 
failed

Stack Trace:

[jira] [Commented] (SOLR-8522) ImplicitSnitch to support IPv4 fragment tags

[Arcadius Ahouansou (JIRA)]

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

Arcadius Ahouansou commented on SOLR-8522:
--

Thank you very much [~noble.paul] for your valuable help on this issue.


> ImplicitSnitch to support IPv4 fragment tags
> 
>
> Key: SOLR-8522
> URL: https://issues.apache.org/jira/browse/SOLR-8522
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4
>Reporter: Arcadius Ahouansou
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 6.0
>
> Attachments: SOLR-8522.patch, SOLR-8522.patch, SOLR-8522.patch, 
> SOLR-8522.patch, SOLR-8522.patch
>
>
> This is a description from [~noble.paul]'s comment on SOLR-8146
> h3. IPv4 fragment tags
> Lets assume a Solr node IPv4 address is {{192.93.255.255}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support IP based 
> tags like:
> - {{hostfrag_1 = 255}}
> - {{hostfrag_2 = 255}}
> - {{hostfrag_3 = 93}}
> - {{hostfrag_4 = 192}}
> Note that IPv6 support will be implemented by a separate ticket
> h3. Host name fragment tags
> Lets assume a Solr node host name {{serv1.dc1.country1.apache.org}} .
> This is about enhancing the current {{ImplicitSnitch}}  to support  tags like:
> - {{hostfrag_1 = org}}
> - {{hostfrag_2 = apache}}
> - {{hostfrag_3 = country1}}
> - {{hostfrag_4 = dc1}}
> - {{hostfrag_5 = serv1}}



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk-9-ea+106) - Build # 15976 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15976/
Java: 32bit/jdk-9-ea+106 -client -XX:+UseG1GC

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([12951F2E8EDEBFD0:8EF350CFC3D65C75]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:38177/l/q/collection1: Carrot2 clustering 
failed

Stack Trace:

[jira] [Resolved] (LUCENE-7045) remove all encode/decode hooks from PointRangeQuery

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-7045.
-
   Resolution: Fixed
Fix Version/s: 6.0

> remove all encode/decode hooks from PointRangeQuery
> ---
>
> Key: LUCENE-7045
> URL: https://issues.apache.org/jira/browse/LUCENE-7045
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: 6.0
>
> Attachments: LUCENE-7045.patch
>
>
> In LUCENE-7043 we added several new point types and just gave them static 
> methods to generate exact/range/prefix/whatever queries.
> I think we should do the same in general, e.g. for IntPoint:
> {code}
> This field defines static factory methods for creating common queries:
> 
>   {@link #newExactQuery newExactQuery()} for matching an exact 1D point.
>   {@link #newRangeQuery newRangeQuery()} for matching a 1D range.
>   {@link #newMultiRangeQuery newMultiRangeQuery()} for matching 
> points/ranges in n-dimensional space.
> 
> {code}
> Then each Point can have types that make sense for it: e.g. multi-dimensional 
> range queries don't make sense at all for IP addresses, but prefix query 
> does, and polygon/distance queries make sense for LatLonPoint and so on (that 
> one is not refactored yet here, followup!)



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

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

[jira] [Commented] (LUCENE-7045) remove all encode/decode hooks from PointRangeQuery

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7045: remove all encode/decode hooks from PointRangeQuery


> remove all encode/decode hooks from PointRangeQuery
> ---
>
> Key: LUCENE-7045
> URL: https://issues.apache.org/jira/browse/LUCENE-7045
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7045.patch
>
>
> In LUCENE-7043 we added several new point types and just gave them static 
> methods to generate exact/range/prefix/whatever queries.
> I think we should do the same in general, e.g. for IntPoint:
> {code}
> This field defines static factory methods for creating common queries:
> 
>   {@link #newExactQuery newExactQuery()} for matching an exact 1D point.
>   {@link #newRangeQuery newRangeQuery()} for matching a 1D range.
>   {@link #newMultiRangeQuery newMultiRangeQuery()} for matching 
> points/ranges in n-dimensional space.
> 
> {code}
> Then each Point can have types that make sense for it: e.g. multi-dimensional 
> range queries don't make sense at all for IP addresses, but prefix query 
> does, and polygon/distance queries make sense for LatLonPoint and so on (that 
> one is not refactored yet here, followup!)



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

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

[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 13 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/13/

No tests ran.

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

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



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

[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 859 - Still Failing

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Could not register as the leader because creating the ephemeral registration 
node in ZooKeeper failed

Stack Trace:
org.apache.solr.common.SolrException: Could not register as the leader because 
creating the ephemeral registration node in ZooKeeper failed
at 
__randomizedtesting.SeedInfo.seed([3AF458B34A0E40A8:E4A7DF445096B559]:0)
at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:212)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:173)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:310)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:219)
at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:181)
at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:841)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-8723) Admin UIs' schema screen do not show the multiTerm part of the analyzer definition

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-8723:
-

Schema definition example:
{noformat}


  


  


  

  
{noformat}

> Admin UIs' schema screen do not show the multiTerm part of the analyzer 
> definition
> --
>
> Key: SOLR-8723
> URL: https://issues.apache.org/jira/browse/SOLR-8723
> Project: Solr
>  Issue Type: Improvement
>  Components: UI
>Affects Versions: 5.5
>Reporter: Alexandre Rafalovitch
>Priority: Minor
>
> If a field type is created with multiterm analyzer chain, it does not show up 
> in the Admin UI's Schema screen.
> This happens for both old and new UI implementations.



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

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

[jira] [Created] (SOLR-8723) Admin UIs' schema screen do not show the multiTerm part of the analyzer definition

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-8723:
---

 Summary: Admin UIs' schema screen do not show the multiTerm part 
of the analyzer definition
 Key: SOLR-8723
 URL: https://issues.apache.org/jira/browse/SOLR-8723
 Project: Solr
  Issue Type: Improvement
  Components: UI
Affects Versions: 5.5
Reporter: Alexandre Rafalovitch
Priority: Minor


If a field type is created with multiterm analyzer chain, it does not show up 
in the Admin UI's Schema screen.

This happens for both old and new UI implementations.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:51332/ur/p/awholynewcollection_0: non ok 
status: 500, message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:51332/ur/p/awholynewcollection_0: non ok 
status: 500, message:Server Error
at 
__randomizedtesting.SeedInfo.seed([422CDADE49538215:CA78E504E7AFEFED]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:510)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:240)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:229)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForNon403or404or503(AbstractFullDistribZkTestBase.java:1753)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:737)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:964)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:939)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Reopened] (SOLR-8497) Merge index does not mark the Directories it creates as 'done' and they are retained in the Directory cache.

[Mark Miller (JIRA)]

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

Mark Miller reopened SOLR-8497:
---

> Merge index does not mark the Directories it creates as 'done' and they are 
> retained in the Directory cache.
> 
>
> Key: SOLR-8497
> URL: https://issues.apache.org/jira/browse/SOLR-8497
> Project: Solr
>  Issue Type: Bug
>  Components: Hadoop Integration, SolrCloud
>Affects Versions: 4.10.3
> Environment: Cloudera Search (CDH 5.4.5 Solr 4.10.3)
>Reporter: Sivlio Sanchez
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8497.patch
>
>
> After a Merge Indexes, the input directories on HDFS do not get closed (only 
> released by the CachingDirectoryFactory). This causes the 
> HDFSLocalityReporter to continue monitoring the input directories even after 
> they are cleaned up/deleted. This results in a large volume of logged 
> warnings on the Solr node.



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

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

[jira] [Commented] (SOLR-8497) Merge index does not mark the Directories it creates as 'done' and they are retained in the Directory cache.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8497:
---

I don't think this is quite right yet. We should only mark the directory as 
done if it's not already being used by Solr I think.

> Merge index does not mark the Directories it creates as 'done' and they are 
> retained in the Directory cache.
> 
>
> Key: SOLR-8497
> URL: https://issues.apache.org/jira/browse/SOLR-8497
> Project: Solr
>  Issue Type: Bug
>  Components: Hadoop Integration, SolrCloud
>Affects Versions: 4.10.3
> Environment: Cloudera Search (CDH 5.4.5 Solr 4.10.3)
>Reporter: Sivlio Sanchez
>Assignee: Mark Miller
>Priority: Minor
> Fix For: master
>
> Attachments: SOLR-8497.patch
>
>
> After a Merge Indexes, the input directories on HDFS do not get closed (only 
> released by the CachingDirectoryFactory). This causes the 
> HDFSLocalityReporter to continue monitoring the input directories even after 
> they are cleaned up/deleted. This results in a large volume of logged 
> warnings on the Solr node.



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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8697:
--

Attached a patch with real synchronization.  99% sure this will fix the 
observed flake.
I also included the MockZKController.close() election cancel change, I think 
it's a good cleanup but not related to the flake.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8697:
-
Attachment: (was: SOLR-8697-followup.patch)

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8697:
-
Attachment: SOLR-8697-followup.patch

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8697:
-
Attachment: (was: SOLR-8697-followup.patch)

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8697:
-
Attachment: SOLR-8697-followup.patch

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697-followup.patch, SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8697:
--

Actually, I'm stupid.  The flaky problem is that I *still* didn't fix the race 
regarding leaderZkNodeParentVersion.  I just made it harder to repro.

The smoking gun is this line:

{code}
  log.info("No version found for ephemeral leader parent node, won't remove 
previous leader registration.");
{code}

You can repro this pretty easily with the following change:

{code}

 -- a/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
 ++ b/solr/core/src/java/org/apache/solr/cloud/ElectionContext.java

@@ -193,7 +193,7 @@ class ShardLeaderElectionContextBase extends 
ElectionContext {
   List results;
   
   results = zkClient.multi(ops, true);
   
   Thread.sleep(1);
   for (OpResult result : results) {
 if (result.getType() == ZooDefs.OpCode.setData) {
   SetDataResult dresult = (SetDataResult) result;
{code}

We need a harder synchronization around becoming leader vs. canceling.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-8349:
---
Attachment: SOLR-8349_4.patch

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
>Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, SOLR-8349.patch, 
> SOLR-8349_4.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



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

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

[jira] [Commented] (SOLR-8349) Allow sharing of large in memory data structures across cores

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-8349:


Sure I could, but other folks who try to use this after us will likely stumble 
into that pitfall. I've played around with it and simplified BlobContent, moved 
the PluginBag specific stuff to PluginBag and provided some javadoc and a user 
friendly method on SolrCore which will ensure that a close hook is also 
created. It seems all my goals except #3 are satisfied and we've exceeded 
expectations for #2 making it possible to reliably update the content on the 
fly with no danger of memory leaks (yay). I definitely like this approach 
better. Attaching patch #4. The patch contains a class named 
org.apache.solr.handler.component.XXCustomComponent demonstrating usage 
(redacted and cleansed version of what I'm using for a client's server, adapted 
to this patch) This class obviously should not be included in the commit.

> Allow sharing of large in memory data structures across cores
> -
>
> Key: SOLR-8349
> URL: https://issues.apache.org/jira/browse/SOLR-8349
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.3
>Reporter: Gus Heck
>Assignee: Noble Paul
> Attachments: SOLR-8349.patch, SOLR-8349.patch, SOLR-8349.patch
>
>
> In some cases search components or analysis classes may utilize a large 
> dictionary or other in-memory structure. When multiple cores are loaded with 
> identical configurations utilizing this large in memory structure, each core 
> holds it's own copy in memory. This has been noted in the past and a specific 
> case reported in SOLR-3443. This patch provides a generalized capability, and 
> if accepted, this capability will then be used to fix SOLR-3443.



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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8697:
---

bq. , even running like 100 iterations.

Unfortunately, that is common. The tests are run in a wicked diverse set of 
envs. We see stuff from the jenkins cluster no dev ever seems to hit. 

A lot of fails only pop when running with other tests to also bog down the 
system, and you won't see the issue with that test in isolation, and then you 
can configure different numbers of tests to run at the same time (I do 10 on my 
6 core machine), and the different levels of hardware...

Some things are pretty hard to replicate locally.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8697:
--

Attached a followup patch that cancels previous elections when the 
MockZkController is closed.  I haven't actually been able to get 
OverseerTest.testShardLeaderChange() to flake on my machine, with or without 
the change, even running like 100 iterations.  But 

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8697:
-
Attachment: SOLR-8697-followup.patch

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697-followup.patch, 
> SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8696:
-
Attachment: (was: SOLR-8696-followup.patch)

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Fix For: master
>
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Resolved] (SOLR-8720) ZkController#publishAndWaitForDownStates should use #publishNodeAsDown.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-8720.
---
   Resolution: Fixed
Fix Version/s: master

> ZkController#publishAndWaitForDownStates should use #publishNodeAsDown.
> ---
>
> Key: SOLR-8720
> URL: https://issues.apache.org/jira/browse/SOLR-8720
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: master
>
> Attachments: SOLR-8720.patch
>
>




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

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

[jira] [Updated] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8696:
-
Attachment: SOLR-8696-followup.patch

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Fix For: master
>
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_72) - Build # 15975 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15975/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testShardLeaderChange

Error Message:
Could not register as the leader because creating the ephemeral registration 
node in ZooKeeper failed

Stack Trace:
org.apache.solr.common.SolrException: Could not register as the leader because 
creating the ephemeral registration node in ZooKeeper failed
at 
__randomizedtesting.SeedInfo.seed([6569EDD68240161:D805192A72BCF490]:0)
at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:212)
at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:173)
at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:310)
at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:219)
at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:181)
at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:841)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

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

[Policeman Jenkins Server]

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

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([7346FE4D88FD49DB:EF20B1ACC5F5AA7E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:63861/cjz/e/collection1: Carrot2 
clustering failed

Stack Trace:

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8697:
---

bq. deleting the registration on cancel.

+1.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-8697:
--
Attachment: OverseerTestFail.log

Here is the log file just in case.

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: OverseerTestFail.log, SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8697:
--

I'll take a look.  I ran into this before on account of the test code doing a 
couple of questionable things.

1) Re-using the same ZK session for multiple election contexts on the same 
election.  I fixed that one in my patch.

2) Not deleting the registration on cancel.  I didn't bother fixing this one, 
since I figured eventually the session timeout would kill all the ephemeral 
nodes, making for a more thorough test.  But explicitly deleting the 
registration would speed the test up and make it more reliable, probably.

Thoughts?


> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Commented] (SOLR-8720) ZkController#publishAndWaitForDownStates should use #publishNodeAsDown.

[ASF subversion and git services (JIRA)]

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

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

Commit 18bb8caedecb5c7d1a7c93006b2d919218ef6386 in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=18bb8ca ]

SOLR-8720: ZkController#publishAndWaitForDownStates should use 
#publishNodeAsDown.


> ZkController#publishAndWaitForDownStates should use #publishNodeAsDown.
> ---
>
> Key: SOLR-8720
> URL: https://issues.apache.org/jira/browse/SOLR-8720
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-8720.patch
>
>




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

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

[jira] [Commented] (SOLR-8697) Fix LeaderElector issues

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8697:
---

Note: Have not seen any fails like this in this test in a long, long time so 
may be related to this change. Perhaps just a test issue, because this retries 
for like 60 seconds or something.

{noformat}
   [junit4] ERROR   66.3s J4  | OverseerTest.testShardLeaderChange <<<
   [junit4]> Throwable #1: org.apache.solr.common.SolrException: Could not 
register as the leader because creating the ephemeral registration node in 
ZooKeeper failed
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([C4618609907C7E14:1A3201FE8AE48BE5]:0)
   [junit4]>at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:212)
   [junit4]>at 
org.apache.solr.cloud.LeaderElector.runIamLeaderProcess(LeaderElector.java:173)
   [junit4]>at 
org.apache.solr.cloud.LeaderElector.checkIfIamLeader(LeaderElector.java:138)
   [junit4]>at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:310)
   [junit4]>at 
org.apache.solr.cloud.LeaderElector.joinElection(LeaderElector.java:219)
   [junit4]>at 
org.apache.solr.cloud.OverseerTest$MockZKController.publishState(OverseerTest.java:181)
   [junit4]>at 
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:841)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: 
org.apache.zookeeper.KeeperException$NodeExistsException: KeeperErrorCode = 
NodeExists
   [junit4]>at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:119)
   [junit4]>at 
org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:949)
   [junit4]>at 
org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:915)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient$11.execute(SolrZkClient.java:577)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient$11.execute(SolrZkClient.java:574)
   [junit4]>at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60)
   [junit4]>at 
org.apache.solr.common.cloud.SolrZkClient.multi(SolrZkClient.java:574)
   [junit4]>at 
org.apache.solr.cloud.ShardLeaderElectionContextBase$1.execute(ElectionContext.java:195)
   [junit4]>at 
org.apache.solr.common.util.RetryUtil.retryOnThrowable(RetryUtil.java:49)
   [junit4]>at 
org.apache.solr.common.util.RetryUtil.retryOnThrowable(RetryUtil.java:42)
   [junit4]>at 
org.apache.solr.cloud.ShardLeaderElectionContextBase.runLeaderProcess(ElectionContext.java:178)
   [junit4]>... 45 more
{noformat}

> Fix LeaderElector issues
> 
>
> Key: SOLR-8697
> URL: https://issues.apache.org/jira/browse/SOLR-8697
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, reliability, solrcloud
> Fix For: master
>
> Attachments: SOLR-8697.patch
>
>
> This patch is still somewhat WIP for a couple of reasons:
> 1) Still debugging test failures.
> 2) This will more scrutiny from knowledgable folks!
> There are some subtle bugs with the current implementation of LeaderElector, 
> best demonstrated by the following test:
> 1) Start up a small single-node solrcloud.  it should be become Overseer.
> 2) kill -9 the solrcloud process and immediately start a new one.
> 3) The new process won't become overseer.  The old process's ZK leader elect 
> node has not yet disappeared, and the new process fails to set appropriate 
> watches.
> NOTE: this is only reproducible if the new node is able to start up and join 
> the election quickly.



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

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

[jira] [Updated] (SOLR-8671) Date statistics: make "sum" a double instead of a long/date

[Tom Hill (JIRA)]

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

Tom Hill updated SOLR-8671:
---
Attachment: 0001-change-date-sum-to-double.patch

This patch requires the patch in SOLR-8420 be applied first, as this patch 
modifies a test added in the patch for SOLR-8420.

> Date statistics: make "sum" a double instead of a long/date
> ---
>
> Key: SOLR-8671
> URL: https://issues.apache.org/jira/browse/SOLR-8671
> Project: Solr
>  Issue Type: Improvement
>Reporter: Tomás Fernández Löbbe
> Fix For: master
>
> Attachments: 0001-change-date-sum-to-double.patch
>
>
> Currently {{DateStatsValues#sum}} is defined as long, and returned as a date. 
> This has two problems: It overflows (with ~6 million values), and the return 
> value can be a date like {{122366-06-12T21:06:06Z}}. 
> I think we should just change this stat to a double. See SOLR-8420.
> I think we can change this only in master, since it will break backward 
> compatibility.



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

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

[jira] [Updated] (SOLR-8420) Date statistics: sumOfSquares overflows long

[Tom Hill (JIRA)]

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

Tom Hill updated SOLR-8420:
---
Attachment: 0001-Fix-overflow-in-date-statistics.patch

This latest version of the path adds an allowance in tests for floating point 
errors in computations for specific stats. 

It also fixes the error in the test that Tomas noted.

> Date statistics: sumOfSquares overflows long
> 
>
> Key: SOLR-8420
> URL: https://issues.apache.org/jira/browse/SOLR-8420
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 5.4
>Reporter: Tom Hill
>Priority: Minor
> Attachments: 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, 
> 0001-Fix-overflow-in-date-statistics.patch, StdDev.java
>
>
> The values for Dates are large enough that squaring them overflows a "long" 
> field. This should be converted to a double. 
> StatsValuesFactory.java, line 755 DateStatsValues#updateTypeSpecificStats Add 
> a cast to double 
> sumOfSquares += ( (double)value * value * count);



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

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

[jira] [Commented] (LUCENE-7045) remove all encode/decode hooks from PointRangeQuery

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7045:


+1, this is really nice.  I like having all encode/decode for a given data type 
in once place, succinctly exposed, and having that same place create the 
queries.

> remove all encode/decode hooks from PointRangeQuery
> ---
>
> Key: LUCENE-7045
> URL: https://issues.apache.org/jira/browse/LUCENE-7045
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7045.patch
>
>
> In LUCENE-7043 we added several new point types and just gave them static 
> methods to generate exact/range/prefix/whatever queries.
> I think we should do the same in general, e.g. for IntPoint:
> {code}
> This field defines static factory methods for creating common queries:
> 
>   {@link #newExactQuery newExactQuery()} for matching an exact 1D point.
>   {@link #newRangeQuery newRangeQuery()} for matching a 1D range.
>   {@link #newMultiRangeQuery newMultiRangeQuery()} for matching 
> points/ranges in n-dimensional space.
> 
> {code}
> Then each Point can have types that make sense for it: e.g. multi-dimensional 
> range queries don't make sense at all for IP addresses, but prefix query 
> does, and polygon/distance queries make sense for LatLonPoint and so on (that 
> one is not refactored yet here, followup!)



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

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

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 420 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 29059 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/build.xml:520:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-trunk/solr/build.xml:448:
 java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at 
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at sun.net.NetworkClient.doConnect(NetworkClient.java:180)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:432)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:527)
at sun.net.www.http.HttpClient.(HttpClient.java:211)
at sun.net.www.http.HttpClient.New(HttpClient.java:308)
at sun.net.www.http.HttpClient.New(HttpClient.java:326)
at 
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:1169)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1105)
at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:999)
at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:933)
at 
org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660)
at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579)
at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569)

Total time: 12 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[jira] [Commented] (SOLR-8110) Start enforcing field naming recomendations in next X.0 release?

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-8110:


The core characters we need are letters, numbers, and the underscore. Consensus 
seems to be that we allow dots (periods).  If dashes (hyphens) are allowed, 
then they cannot be the first character, or that will cause confusion with 
negated query clauses and possibly cause other problems.

Underscores must be allowed as the first character, so \_version\_ and other 
special fields used internally will work.  My personal opinion is that the 
first character must be a letter or an underscore, so we don't have to worry 
about fixing bugs related to identifiers that start with a number.

One unanswered question is whether to only allow ASCII, or if "letters and 
numbers" should include all matching characters in Unicode.  My bias, which I 
admit is completely provincial and might be far too restrictive, is ASCII.

A dedicated config option might be better than luceneMatchVersion, but I'm OK 
either way.  There are users who must use an old version number even with newer 
versions of Solr.  Changes to WordDelimiterFilter in 4.8 have a number of 
people using 4.7 in luceneMatchVersion.

> Start enforcing field naming recomendations in next X.0 release?
> 
>
> Key: SOLR-8110
> URL: https://issues.apache.org/jira/browse/SOLR-8110
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>
> For a very long time now, Solr has made the following "recommendation" 
> regarding field naming conventions...
> bq. field names should consist of alphanumeric or underscore characters only 
> and not start with a digit.  This is not currently strictly enforced, but 
> other field names will not have first class support from all components and 
> back compatibility is not guaranteed.  ...
> I'm opening this issue to track discussion about if/how we should start 
> enforcing this as a rule instead (instead of just a "recommendation") in our 
> next/future X.0 (ie: major) release.
> The goals of doing so being:
> * simplify some existing code/apis that currently use hueristics to deal with 
> lists of field and produce strange errors when the huerstic fails (example: 
> ReturnFields.add)
> * reduce confusion/pain for new users who might start out unaware of the 
> recommended conventions and then only later encountering a situation where 
> their field names are not supported by some feature and get frustrated 
> because they have to change their schema, reindex, update index/query client 
> expectations, etc...



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

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

[jira] [Resolved] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-8696.
---
   Resolution: Fixed
Fix Version/s: master

Thanks Scott!

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Fix For: master
>
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[ASF subversion and git services (JIRA)]

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

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

Commit 8ac4fdd6bb84b225919d30f6073e7dad02aeb0a1 in lucene-solr's branch 
refs/heads/master from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8ac4fdd ]

SOLR-8696: Start the Overseer before actions that need the overseer on init and 
when reconnecting after zk expiration and improve init logic.


> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

Re: Rolling upgrades from 5.x to 6.0

[Shai Erera]

Mark, I understand that we currently don't have any other promises :). I
asked in case you happen to know that "oh yeah, in 6.0 we've changed ZK to
refer to /solr_collections instead of /collections" (I wish it would be
*that* trivial :)).

If you don't have a list that's fine. You just sounded really confident
that 5.x -> 6.0 won't work, so I hoped you also can tell why.

I think we should try to be back-compat here, i.e. that a 6.0 (or 7.0) can
read a 5.0 (or 6.0) Solr. If ZK is our "format", then we should treat it as
a thing we want to support. That's just my opinion though.

Shai

On Tue, Feb 23, 2016 at 8:46 PM Anshum Gupta  wrote:

> For that, we provide an index upgrade tool with 6.0, like we did in 5.0.
>
> On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob  wrote:
>
>> A 5.x Solr could have indices that are still in a 4.x format, right? That
>> would be one point where it's not "fully back compatible."
>>
>> On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  wrote:
>>
>>> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
>>> will be able to read Lucene 5.0 indexes. The only thing that we don't
>>> guarantee support for is API, which isn't the case here.
>>>
>>> So what's in 6.0 that can't read a 5.x Solr. It can't be the index
>>> format since that's supported by Lucene. Is it the ZK format? If so, should
>>> we try to "version" it so that a 6.0 code can read a 5.x version? Is it
>>> something else / additionally?
>>>
>>> Shai
>>>
>>> On Tue, Feb 23, 2016 at 7:06 PM Mark Miller 
>>> wrote:
>>>
 Yes, we are allowed wide berth to break backcompat across major
 versions and we cannot support rolling updates for the same reason Lucene
 stopped trying to do full back compat across major versions. Without, we
 can't properly innovate in the code or fix past mistakes and would also
 burn lots of cycles we don't have on crazy, "sophisticated" back compat
 layers.

 We don't even really support rolling updates between major versions. We
 make a simple best effort. Until we have tests, it's going to be a shaky
 affair. There is a JIRA open now working on some testing I believe.

 - Mark

 On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:

> Hi
>
> I read in few emails/issue comments that rolling upgrades from 5.x to
> 6.0 isn't supported. Is it really the case? Does it mean that anyone who
> has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>
> If this is really the case, can someone list the known issues/reasons
> for that?Can we do something about it, e.g. in a subsequent 5.6 release
> that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling
> upgrades from pre-5.4 to 5.4)?
>
> I feel it's odd (and may not be taken well) if we force users to take
> down their entire cluster if they want to upgrade to 6.0. Definitely feels
> like it will also slow down 6.0 adoption.
>
> And if nothing can be done, what's the recommended way then to upgrade
> to 6.0?
>
> Shai
>
 --
 - Mark
 about.me/markrmiller

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

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8696:
--

Thanks.  Way beyond the scope of this ticket, I was just curious about it.  It 
seemed a little silly on the face of it, because solr already has to tolerate 
long periods of things being marked ACTIVE in cluster state that aren't really 
up, since a node can crash and take a long time to recover.  I feel like all a 
recovering node really needs to do is verify that all the cores it owns are in 
the correct state immediately before publishing its live node entry.  We could 
save a lot of unnecessary overseer ops here on node restart.

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

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

[Apache Jenkins Server]

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

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([7E497A2ABA6628F:9B82D843E6AE812A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:55918/_/collection1: Carrot2 clustering 
failed

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at 

[jira] [Commented] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8722:
--

[~shalinmangar] is this what you had in mind?  We could probably optimize 
exactly what this code waits on, but I figured I'd just start by reusing the 
existing code.  But looping 320 x 1 second seems a bit excessive for a new core 
creation.

Also, what's the right way to handle things if the remote call fails?  Will the 
code throw before it reaches the wait loop, or should I try to inspect the 
response object for errors before deciding to wait?  I didn't see any special 
handling at other call sites.

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud
> Attachments: SOLR-8722.patch
>
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



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

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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8722:
-
Attachment: SOLR-8722.patch

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud
> Attachments: SOLR-8722.patch
>
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



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

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

Re: Rolling upgrades from 5.x to 6.0

[Anshum Gupta]

For that, we provide an index upgrade tool with 6.0, like we did in 5.0.

On Tue, Feb 23, 2016 at 10:41 AM, Mike Drob  wrote:

> A 5.x Solr could have indices that are still in a 4.x format, right? That
> would be one point where it's not "fully back compatible."
>
> On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  wrote:
>
>> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
>> will be able to read Lucene 5.0 indexes. The only thing that we don't
>> guarantee support for is API, which isn't the case here.
>>
>> So what's in 6.0 that can't read a 5.x Solr. It can't be the index format
>> since that's supported by Lucene. Is it the ZK format? If so, should we try
>> to "version" it so that a 6.0 code can read a 5.x version? Is it something
>> else / additionally?
>>
>> Shai
>>
>> On Tue, Feb 23, 2016 at 7:06 PM Mark Miller 
>> wrote:
>>
>>> Yes, we are allowed wide berth to break backcompat across major versions
>>> and we cannot support rolling updates for the same reason Lucene stopped
>>> trying to do full back compat across major versions. Without, we can't
>>> properly innovate in the code or fix past mistakes and would also burn lots
>>> of cycles we don't have on crazy, "sophisticated" back compat layers.
>>>
>>> We don't even really support rolling updates between major versions. We
>>> make a simple best effort. Until we have tests, it's going to be a shaky
>>> affair. There is a JIRA open now working on some testing I believe.
>>>
>>> - Mark
>>>
>>> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:
>>>
 Hi

 I read in few emails/issue comments that rolling upgrades from 5.x to
 6.0 isn't supported. Is it really the case? Does it mean that anyone who
 has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?

 If this is really the case, can someone list the known issues/reasons
 for that?Can we do something about it, e.g. in a subsequent 5.6 release
 that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling
 upgrades from pre-5.4 to 5.4)?

 I feel it's odd (and may not be taken well) if we force users to take
 down their entire cluster if they want to upgrade to 6.0. Definitely feels
 like it will also slow down 6.0 adoption.

 And if nothing can be done, what's the recommended way then to upgrade
 to 6.0?

 Shai

>>> --
>>> - Mark
>>> about.me/markrmiller
>>>
>>
>


-- 
Anshum Gupta

Re: Rolling upgrades from 5.x to 6.0

[Mike Drob]

A 5.x Solr could have indices that are still in a 4.x format, right? That
would be one point where it's not "fully back compatible."

On Tue, Feb 23, 2016 at 12:27 PM, Shai Erera  wrote:

> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
> will be able to read Lucene 5.0 indexes. The only thing that we don't
> guarantee support for is API, which isn't the case here.
>
> So what's in 6.0 that can't read a 5.x Solr. It can't be the index format
> since that's supported by Lucene. Is it the ZK format? If so, should we try
> to "version" it so that a 6.0 code can read a 5.x version? Is it something
> else / additionally?
>
> Shai
>
> On Tue, Feb 23, 2016 at 7:06 PM Mark Miller  wrote:
>
>> Yes, we are allowed wide berth to break backcompat across major versions
>> and we cannot support rolling updates for the same reason Lucene stopped
>> trying to do full back compat across major versions. Without, we can't
>> properly innovate in the code or fix past mistakes and would also burn lots
>> of cycles we don't have on crazy, "sophisticated" back compat layers.
>>
>> We don't even really support rolling updates between major versions. We
>> make a simple best effort. Until we have tests, it's going to be a shaky
>> affair. There is a JIRA open now working on some testing I believe.
>>
>> - Mark
>>
>> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:
>>
>>> Hi
>>>
>>> I read in few emails/issue comments that rolling upgrades from 5.x to
>>> 6.0 isn't supported. Is it really the case? Does it mean that anyone who
>>> has a 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>>>
>>> If this is really the case, can someone list the known issues/reasons
>>> for that?Can we do something about it, e.g. in a subsequent 5.6 release
>>> that will allow rolling upgrades (like the 5.4.1 fix that allowed rolling
>>> upgrades from pre-5.4 to 5.4)?
>>>
>>> I feel it's odd (and may not be taken well) if we force users to take
>>> down their entire cluster if they want to upgrade to 6.0. Definitely feels
>>> like it will also slow down 6.0 adoption.
>>>
>>> And if nothing can be done, what's the recommended way then to upgrade
>>> to 6.0?
>>>
>>> Shai
>>>
>> --
>> - Mark
>> about.me/markrmiller
>>
>

Re: Rolling upgrades from 5.x to 6.0

[Mark Miller]

On Tue, Feb 23, 2016 at 1:27 PM Shai Erera  wrote:

> Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
> will be able to read Lucene 5.0 indexes. The only thing that we don't
> guarantee support for is API, which isn't the case here.
>

Of course with Lucene I mean API back compat. Both Lucene and Solr support
indexes over major versions. We don't promise anything else.


>
> So what's in 6.0 that can't read a 5.x Solr. It can't be the index format
> since that's supported by Lucene. Is it the ZK format? If so, should we try
> to "version" it so that a 6.0 code can read a 5.x version? Is it something
> else / additionally?
>

We are free to change whatever we want subject to discussion on that issue.
So I can't make a list :)

We don't have promises over a major version other than Lucenes index back
comp promise.

- Mark

> --
- Mark
about.me/markrmiller

Re: Removing branch_5x shortly

[Shai Erera]

I agree. No one says anything about deliberately introducing new features
in a 5.6. At least from my POV, I'd like to be able to not take down my
Solr cluster when upgrading to 6.0, so if any work needs to happen on the
5x branch (and maybe also on the 6x branch) to make that happen, I'll
gladly do it. Even if it means that eventually I will only be able to
upgrade from 5.5 to 6.1 and have to skip all other releases.

I'm pretty sure that's the spirit of changes that will go into future 5x
releases (and I don't think it's gonna be a loong future after 6.0 is out)
-- definitely not index format changes.

Shai

On Tue, Feb 23, 2016 at 8:28 PM Mark Miller  wrote:

> It's just an example though. Beyond simple features and improvements,
> there are also lots of things we do under Other and Optimizations that we
> would not not necessarily consider for a bug fix release (higher bar), but
> that would be in a 5.6 release. A jetty point release update for example.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 1:10 PM Nicholas Knize  wrote:
>
>> > Things that help users migrate from 5x to 6x that we perhaps missed out.
>>
>> This may be semantics but these sound to me like bugs? Not features?
>>
>>
>> On Tuesday, February 23, 2016, Anshum Gupta 
>> wrote:
>>
>>> My thoughts exactly.
>>>
>>> The features that go into a possible 5.6 or 5.7 release would be stuff
>>> that is unrelated to index format. Things that help users migrate from 5x
>>> to 6x that we perhaps missed out. I'm just saying there's a real valid
>>> possibility of such a release.
>>>
>>>
>>> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller 
>>> wrote:
>>>
 I just want to point out: just like the previous line of bug fix
 releases dies down heavily, so would the feature backports. They will
 likely be simple useful things rather than crazy complicated hard things.
 There probably won't be that many, just like the bug fix releases. Let's
 not pretend it's going to end up like an active branch with devs always
 wondering if the new codec they are slamming in is going to mess things up.

 If there is any demand for this, it's going to be by people on 5x for
 stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
 or may not be any better. Upgrading a major release can be quite disturbing
 and many users take a long, long time to do it.

 A 5.6, 5.7 would only be more stable. Fewer and simpler backports than
 our two main branches. Users can simply gobble them up, rather than choke
 them down like a major release. Useful features can be found that may not
 affect index format.

 Anyway, if there ends up being demand, I'll certainly be one of the
 3 +1's needed.

 - Mark

 On Tue, Feb 23, 2016 at 12:18 PM Mark Miller 
 wrote:

> On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler 
> wrote:
>
>> Hi,
>>
>>
>>
>> To me it is quite clear that once we released 6.0, there is
>> technically no possibility to release a brand new 5.6 Feature-Release! 
>> The
>> main reason: 6.0 (if released before 5.6) will not be able to read 
>> indexes
>> of 5.6 (because it does not know about the format at the time of its
>> release). So the only thing we can do is release 5.5.1, 5.5.2,… where new
>> index/codecs are not allowed. And for that we already have a branch! Go
>> ahead and commit bugfixes there!
>>
> That makes no sense. There are only a handful of people committing
> index format changes. It's beyond simple for those people to understand
> once the next major version is released, don't put any more index format
> changes into the previous line.
>
> That is a very weak technical argument. Committers already have to
> remember how to deal with back compat and what changes can happen when.
> This is no different.
>
> - Mark
> --
> - Mark
> about.me/markrmiller
>
 --
 - Mark
 about.me/markrmiller

>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>> --
> - Mark
> about.me/markrmiller
>

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8696:
---

The stale state could say ACTIVE. No guarantee shutdown publishes DOWN (a crash 
won't).

The one in init, I'm less sure of. I think [~thelabdude] may have had to add 
that when he worked on recovering from partitions properly.

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8696:
--

Patch LGTM.  On an unrelated note, I've never understood why it's so important 
to register all cores as down on startup, since presumably we're about to bring 
them all up..

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8722:
-
Labels: patch performance solrcloud  (was: patch performance solrcloud 
startup)

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



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

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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8722:
-
Attachment: (was: SOLR-8696.patch)

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8722:
-
Attachment: (was: SOLR-8696.patch)

> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Updated] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

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

Scott Blum updated SOLR-8722:
-
Description: 
We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
operations.  This isn't necessary because ZkStateReader keeps itself up to date.

According to [~shalinmangar]'s analysis, we just need to put a wait loop at the 
end of addReplica to observe the state change.

  was:
ZkController.publishAndWaitForDownStates() occurs before overseer election.  
That means if there is currently no overseer, there is ironically no one to 
actually service the down state changes it's waiting on.  This particularly 
affects a single-node cluster such as you might run locally for development.

Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
up to date.


> Don't force a full ZkStateReader refresh on every Overseer operation
> 
>
> Key: SOLR-8722
> URL: https://issues.apache.org/jira/browse/SOLR-8722
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
>
> We're doing an unnecessary ZkStateReader forced refresh on all Overseer 
> operations.  This isn't necessary because ZkStateReader keeps itself up to 
> date.
> According to [~shalinmangar]'s analysis, we just need to put a wait loop at 
> the end of addReplica to observe the state change.



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

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

[jira] [Created] (SOLR-8722) Don't force a full ZkStateReader refresh on every Overseer operation

[Scott Blum (JIRA)]

Scott Blum created SOLR-8722:


 Summary: Don't force a full ZkStateReader refresh on every 
Overseer operation
 Key: SOLR-8722
 URL: https://issues.apache.org/jira/browse/SOLR-8722
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Affects Versions: 5.4.1
Reporter: Scott Blum
Assignee: Mark Miller
 Attachments: SOLR-8696.patch, SOLR-8696.patch

ZkController.publishAndWaitForDownStates() occurs before overseer election.  
That means if there is currently no overseer, there is ironically no one to 
actually service the down state changes it's waiting on.  This particularly 
affects a single-node cluster such as you might run locally for development.

Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
up to date.



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

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

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8696:
--

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

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Comment Edited] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum edited comment on SOLR-8696 at 2/23/16 6:30 PM:
---

Splitting it up sounds like a great idea.


was (Author: dragonsinth):
Splitting it up sound like a great idea.

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[jira] [Updated] (LUCENE-7045) remove all encode/decode hooks from PointRangeQuery

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7045:

Attachment: LUCENE-7045.patch

Here's a patch. 

Points get a little api cleanup, we don't need to expose so much guts anymore, 
just generally an {{encodeDimension}} and {{decodeDimension}} so that anyone 
doing anything custom is able to do it.

{{PointRangeQuery}} is marked abstract and has references to the core points to 
remove any confusion.

> remove all encode/decode hooks from PointRangeQuery
> ---
>
> Key: LUCENE-7045
> URL: https://issues.apache.org/jira/browse/LUCENE-7045
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7045.patch
>
>
> In LUCENE-7043 we added several new point types and just gave them static 
> methods to generate exact/range/prefix/whatever queries.
> I think we should do the same in general, e.g. for IntPoint:
> {code}
> This field defines static factory methods for creating common queries:
> 
>   {@link #newExactQuery newExactQuery()} for matching an exact 1D point.
>   {@link #newRangeQuery newRangeQuery()} for matching a 1D range.
>   {@link #newMultiRangeQuery newMultiRangeQuery()} for matching 
> points/ranges in n-dimensional space.
> 
> {code}
> Then each Point can have types that make sense for it: e.g. multi-dimensional 
> range queries don't make sense at all for IP addresses, but prefix query 
> does, and polygon/distance queries make sense for LatLonPoint and so on (that 
> one is not refactored yet here, followup!)



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

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

Re: Removing branch_5x shortly

[Mark Miller]

It's just an example though. Beyond simple features and improvements, there
are also lots of things we do under Other and Optimizations that we would
not not necessarily consider for a bug fix release (higher bar), but that
would be in a 5.6 release. A jetty point release update for example.

- Mark

On Tue, Feb 23, 2016 at 1:10 PM Nicholas Knize  wrote:

> > Things that help users migrate from 5x to 6x that we perhaps missed out.
>
> This may be semantics but these sound to me like bugs? Not features?
>
>
> On Tuesday, February 23, 2016, Anshum Gupta 
> wrote:
>
>> My thoughts exactly.
>>
>> The features that go into a possible 5.6 or 5.7 release would be stuff
>> that is unrelated to index format. Things that help users migrate from 5x
>> to 6x that we perhaps missed out. I'm just saying there's a real valid
>> possibility of such a release.
>>
>>
>> On Tue, Feb 23, 2016 at 9:44 AM, Mark Miller 
>> wrote:
>>
>>> I just want to point out: just like the previous line of bug fix
>>> releases dies down heavily, so would the feature backports. They will
>>> likely be simple useful things rather than crazy complicated hard things.
>>> There probably won't be that many, just like the bug fix releases. Let's
>>> not pretend it's going to end up like an active branch with devs always
>>> wondering if the new codec they are slamming in is going to mess things up.
>>>
>>> If there is any demand for this, it's going to be by people on 5x for
>>> stability. Upgrading to a 6.0 release is an early adopter. 6.1 and 6.2 may
>>> or may not be any better. Upgrading a major release can be quite disturbing
>>> and many users take a long, long time to do it.
>>>
>>> A 5.6, 5.7 would only be more stable. Fewer and simpler backports than
>>> our two main branches. Users can simply gobble them up, rather than choke
>>> them down like a major release. Useful features can be found that may not
>>> affect index format.
>>>
>>> Anyway, if there ends up being demand, I'll certainly be one of the
>>> 3 +1's needed.
>>>
>>> - Mark
>>>
>>> On Tue, Feb 23, 2016 at 12:18 PM Mark Miller 
>>> wrote:
>>>
 On Tue, Feb 23, 2016 at 12:14 PM Uwe Schindler  wrote:

> Hi,
>
>
>
> To me it is quite clear that once we released 6.0, there is
> technically no possibility to release a brand new 5.6 Feature-Release! The
> main reason: 6.0 (if released before 5.6) will not be able to read indexes
> of 5.6 (because it does not know about the format at the time of its
> release). So the only thing we can do is release 5.5.1, 5.5.2,… where new
> index/codecs are not allowed. And for that we already have a branch! Go
> ahead and commit bugfixes there!
>
 That makes no sense. There are only a handful of people committing
 index format changes. It's beyond simple for those people to understand
 once the next major version is released, don't put any more index format
 changes into the previous line.

 That is a very weak technical argument. Committers already have to
 remember how to deal with back compat and what changes can happen when.
 This is no different.

 - Mark
 --
 - Mark
 about.me/markrmiller

>>> --
>>> - Mark
>>> about.me/markrmiller
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
> --
- Mark
about.me/markrmiller

[jira] [Commented] (SOLR-8696) Start the Overseer before actions that need the overseer on init and when reconnecting after zk expiration and improve init logic.

[Scott Blum (JIRA)]

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

Scott Blum commented on SOLR-8696:
--

Splitting it up sound like a great idea.

> Start the Overseer before actions that need the overseer on init and when 
> reconnecting after zk expiration and improve init logic.
> --
>
> Key: SOLR-8696
> URL: https://issues.apache.org/jira/browse/SOLR-8696
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Scott Blum
>Assignee: Mark Miller
>  Labels: patch, performance, solrcloud, startup
> Attachments: SOLR-8696.patch, SOLR-8696.patch
>
>
> ZkController.publishAndWaitForDownStates() occurs before overseer election.  
> That means if there is currently no overseer, there is ironically no one to 
> actually service the down state changes it's waiting on.  This particularly 
> affects a single-node cluster such as you might run locally for development.
> Additionally, we're doing an unnecessary ZkStateReader forced refresh on all 
> Overseer operations.  This isn't necessary because ZkStateReader keeps itself 
> up to date.



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

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

[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk-9-ea+106) - Build # 15974 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/15974/
Java: 64bit/jdk-9-ea+106 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

27 tests failed.
FAILED:  
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent

Error Message:
clusters is null and it shouldn't be

Stack Trace:
java.lang.AssertionError: clusters is null and it shouldn't be
at 
__randomizedtesting.SeedInfo.seed([5995A2E05EAE2466:C5F3ED0113A6C7C3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.clustering.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:60)
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:520)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:804)


FAILED:  
org.apache.solr.handler.clustering.DistributedClusteringComponentTest.test

Error Message:
Error from server at http://127.0.0.1:46076//collection1: Carrot2 clustering 
failed

Stack Trace:

Re: Rolling upgrades from 5.x to 6.0

[Shai Erera]

Wait, what do you mean by Lucene not supporting back-compat? Lucene 6.0
will be able to read Lucene 5.0 indexes. The only thing that we don't
guarantee support for is API, which isn't the case here.

So what's in 6.0 that can't read a 5.x Solr. It can't be the index format
since that's supported by Lucene. Is it the ZK format? If so, should we try
to "version" it so that a 6.0 code can read a 5.x version? Is it something
else / additionally?

Shai

On Tue, Feb 23, 2016 at 7:06 PM Mark Miller  wrote:

> Yes, we are allowed wide berth to break backcompat across major versions
> and we cannot support rolling updates for the same reason Lucene stopped
> trying to do full back compat across major versions. Without, we can't
> properly innovate in the code or fix past mistakes and would also burn lots
> of cycles we don't have on crazy, "sophisticated" back compat layers.
>
> We don't even really support rolling updates between major versions. We
> make a simple best effort. Until we have tests, it's going to be a shaky
> affair. There is a JIRA open now working on some testing I believe.
>
> - Mark
>
> On Tue, Feb 23, 2016 at 11:29 AM Shai Erera  wrote:
>
>> Hi
>>
>> I read in few emails/issue comments that rolling upgrades from 5.x to 6.0
>> isn't supported. Is it really the case? Does it mean that anyone who has a
>> 5.x Solr cluster *must* incur down time when upgrading to 6.0?
>>
>> If this is really the case, can someone list the known issues/reasons for
>> that?Can we do something about it, e.g. in a subsequent 5.6 release that
>> will allow rolling upgrades (like the 5.4.1 fix that allowed rolling
>> upgrades from pre-5.4 to 5.4)?
>>
>> I feel it's odd (and may not be taken well) if we force users to take
>> down their entire cluster if they want to upgrade to 6.0. Definitely feels
>> like it will also slow down 6.0 adoption.
>>
>> And if nothing can be done, what's the recommended way then to upgrade to
>> 6.0?
>>
>> Shai
>>
> --
> - Mark
> about.me/markrmiller
>

[jira] [Created] (LUCENE-7045) remove all encode/decode hooks from PointRangeQuery

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7045:
---

 Summary: remove all encode/decode hooks from PointRangeQuery
 Key: LUCENE-7045
 URL: https://issues.apache.org/jira/browse/LUCENE-7045
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir


In LUCENE-7043 we added several new point types and just gave them static 
methods to generate exact/range/prefix/whatever queries.

I think we should do the same in general, e.g. for IntPoint:
{code}
This field defines static factory methods for creating common queries:

  {@link #newExactQuery newExactQuery()} for matching an exact 1D point.
  {@link #newRangeQuery newRangeQuery()} for matching a 1D range.
  {@link #newMultiRangeQuery newMultiRangeQuery()} for matching 
points/ranges in n-dimensional space.

{code}

Then each Point can have types that make sense for it: e.g. multi-dimensional 
range queries don't make sense at all for IP addresses, but prefix query does, 
and polygon/distance queries make sense for LatLonPoint and so on (that one is 
not refactored yet here, followup!)



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

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