[jira] [Updated] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

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

mosh updated SOLR-13125:

Attachment: SOLR-13125.patch

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch, SOLR-13125.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

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

mosh edited comment on SOLR-13125 at 1/16/19 7:36 AM:
--

Added a patch which introduces a new query component.
 The new query component only runs in cloud mode.
 It does the following, in this particular order, and falls back in case any of 
the conditions are not met:

  _Stage Start:_
 # Checks whether an alias is queried.
 # Checks whether the alias is a TRA.
 # Checks whether sort was specified and is sorted by router.field(field TRA 
uses to route docs)

  _Finish Execute Query:_
 # If numFound < rows, fail fast, since no filtering is needed.
 # gets all collections in TRA, sorted by date(descending or ascending, depends 
on the sort specified in query).
 # Count responses by collection, and add to whitelist.
 # If limit was not reached, drop requests from shards not in the whitelist.

The patch also contains a new test suite TRAQueryComponentTest,
 which tests the behavior of this new SearchComponent.


was (Author: moshebla):
Added a patch which introduces a new query component.
The new query component only runs in cloud mode.
It does the following, in this particular order, and falls back in case any of 
the conditions are not met:

  _Stage Start:_
 # Checks whether an alias is queried.
 # Checks whether the alias is a TRA.
 # Checks whether sort was specified and is sorted by router.field(field TRA 
uses to route docs)

  _Finish Execute Query:_
 # gets all collections in TRA, sorted by date(descending or ascending, depends 
on the sort specified in query).
 # Count responses by collection, and add to whitelist.
 # If limit was not reached, drop requests from shards not in the whitelist.

The patch also contains a new test suite TRAQueryComponentTest,
which tests the behavior of this new SearchComponent.

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10.0.1) - Build # 23528 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23528/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<221232.0> but was:<2752.0>

Stack Trace:
java.lang.AssertionError: expected:<221232.0> but was:<2752.0>
at 
__randomizedtesting.SeedInfo.seed([E36637A22952CF30:11C525E2E32DD066]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed(TermInSetQueryTest.java:186)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 728 lines...]
   [junit4] Suite: org.apache.lucene.search.TermInSetQueryTest
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TermInSetQueryTest 
-Dtests.method=testRamBytesUsed -Dtests.seed=E36637A22952CF30 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ff-MR 
-Dtests.timezone=SystemV/PST8PDT -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.08s J0 | TermInSetQueryTest.testRamBytesUsed <<<
   [junit4]> Throwable #1: java.lang.AssertionError: expected:<221232.0> 
but was:<2

[jira] [Commented] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

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

mosh commented on SOLR-13125:
-

Added a patch which introduces a new query component.
The new query component only runs in cloud mode.
It does the following, in this particular order, and falls back in case any of 
the conditions are not met:

  _Stage Start:_
 # Checks whether an alias is queried.
 # Checks whether the alias is a TRA.
 # Checks whether sort was specified and is sorted by router.field(field TRA 
uses to route docs)

  _Finish Execute Query:_
 # gets all collections in TRA, sorted by date(descending or ascending, depends 
on the sort specified in query).
 # Count responses by collection, and add to whitelist.
 # If limit was not reached, drop requests from shards not in the whitelist.

The patch also contains a new test suite TRAQueryComponentTest,
which tests the behavior of this new SearchComponent.

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

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

mosh updated SOLR-13125:

Attachment: (was: SOLR-13125.patch)

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-13125) Optimize Queries when sorting by router.field

[mosh (JIRA)]

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

mosh updated SOLR-13125:

Attachment: SOLR-13125.patch

> Optimize Queries when sorting by router.field
> -
>
> Key: SOLR-13125
> URL: https://issues.apache.org/jira/browse/SOLR-13125
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Minor
> Attachments: SOLR-13125-no-commit.patch, SOLR-13125.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We are currently testing TRA using Solr 7.7, having >300 shards in the alias, 
> with much growth in the coming months.
> The "hot" data(in our case, more recent) will be stored on stronger 
> nodes(SSD, more RAM, etc).
> A proposal of optimizing queries sorted by router.field(the field which TRA 
> uses to route the data to the correct collection) has emerged.
> Perhaps, in queries which are sorted by router.field, Solr could be smart 
> enough to wait for the more recent collections, and in case the limit was 
> reached cancel other queries(or just not block and wait for the results)?
> For example:
> When querying a TRA which with a filter on a different field than 
> router.field, but sorting by router.field desc, limit=100.
> Since this is a TRA, solr will issue queries for all the collections in the 
> alias.
> But to optimize this particular type of query, Solr could wait for the most 
> recent collection in the TRA, see whether the result set matches or exceeds 
> the limit. If so, the query could be returned to the user without waiting for 
> the rest of the shards. If not, the issuing node will block until the second 
> query returns, and so forth, until the limit of the request is reached.
> This might also be useful for deep paging, querying each collection and only 
> skipping to the next once there are no more results in the specified 
> collection.
> Thoughts or inputs are always welcome.
> This is just my two cents, and I'm always happy to brainstorm.
> Thanks in advance.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13138) Remove deprecated code in master

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13138:
-

I volunteer for the spatial stuff & highlighting stuff.

BTW I think in your description mentioning that the branch is "on gitbox" seems 
too specific as it is on GitHub too. I think we all know where to find the 
branches :)

> Remove deprecated code in master
> 
>
> Key: SOLR-13138
> URL: https://issues.apache.org/jira/browse/SOLR-13138
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Alan Woodward
>Priority: Major
>
> There are a number of deprecations in master that should be removed.  This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] dsmiley commented on issue #528: SOLR-12955 2

[GitBox]

dsmiley commented on issue #528: SOLR-12955 2
URL: https://github.com/apache/lucene-solr/pull/528#issuecomment-454653399
 
 
   I should mention... another thing on the back of my mind I'll finally 
mention is another possible different direction -- cut stand-alone support 
altogether for this URP.  There seems to be too much baggage here to maintain.  
'course such a proposal of that magnitude deserves a vetting on the dev list, 
not on some PR comments... and I don't feel like raising it right now.  Still 
what we're doing could be a stepping stone to potentially doing that someday 
which will easier.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] dsmiley commented on issue #528: SOLR-12955 2

[GitBox]

dsmiley commented on issue #528: SOLR-12955 2
URL: https://github.com/apache/lucene-solr/pull/528#issuecomment-454652785
 
 
   I didn't have time unfortunately, and there are some other more pressing 
issues.
   Please go ahead and upload a .patch file.  I'll then "Enable Patch Review" 
since I think you can't do that.
   
   @markrmiller I'm hoping you might lend your input on this overall (even if 
just a gut feel and not specifics) given your long history with this URP.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-5211) updating parent as childless makes old children orphans

[Lucky Sharma (JIRA)]

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

Lucky Sharma commented on SOLR-5211:


[~dsmiley] Hi David, Actually for the backward compatible part, I added one 
Chain Processor, I raised one Jira ticket with patched.
https://issues.apache.org/jira/browse/SOLR-13062

I have discussed it with Mikhail Khludnev, since he suggested its already 
covered in 8, so I marked my ticket as invalid.

The patch is also attached in that Ticket.

> updating parent as childless makes old children orphans
> ---
>
> Key: SOLR-5211
> URL: https://issues.apache.org/jira/browse/SOLR-5211
> Project: Solr
>  Issue Type: Sub-task
>  Components: update
>Affects Versions: 4.5, 6.0
>Reporter: Mikhail Khludnev
>Assignee: David Smiley
>Priority: Blocker
> Fix For: 8.0
>
> Attachments: SOLR-5211.patch, SOLR-5211.patch, SOLR-5211.patch, 
> SOLR-5211.patch, SOLR-5211.patch
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> if I have parent with children in the index, I can send update omitting 
> children. as a result old children become orphaned. 
> I suppose separate \_root_ fields makes much trouble. I propose to extend 
> notion of uniqueKey, and let it spans across blocks that makes updates 
> unambiguous.  
> WDYT? Do you like to see a test proves this issue?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-9.0.4) - Build # 149 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/149/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<241712.0> but was:<2992.0>

Stack Trace:
java.lang.AssertionError: expected:<241712.0> but was:<2992.0>
at 
__randomizedtesting.SeedInfo.seed([D8EACD24EB26B7FD:2A49DF642159A8AB]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed(TermInSetQueryTest.java:186)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 1610 lines...]
   [junit4] Suite: org.apache.lucene.search.TermInSetQueryTest
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TermInSetQueryTest 
-Dtests.method=testRamBytesUsed -Dtests.seed=D8EACD24EB26B7FD 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=kw 
-Dtests.timezone=America/North_Dakota/New_Salem -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.02s J0 | TermInSetQueryTest.testRamBytesUsed <<<
   [junit4]> Throwable #1: java.lang.As

[jira] [Commented] (LUCENE-8635) Lazy loading Lucene FST offheap using mmap

[Ankit Jain (JIRA)]

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

Ankit Jain commented on LUCENE-8635:


 Rally tests use underlying elasticsearch cluster which use cases other than 
search like log analytics. I ran 1 iteration for multiple data sets and did not 
notice significant performance degradations. Rather, I noticed 6% improvement 
in indexing throughput for all the data sets. Though, I should leave it running 
for more iterations, to get more conclusive evidence.

Thanks [~sokolov] for testing the changes. I think the impact is as expected, 
maybe slightly more for the PKLookup. Do the tests use randomized key for each 
PKLookup query or the keys are reused across queries? That will impact the 
overall throughput as mmap is inherently lazily loaded.

Though, I'm open to exposing per field setting in Lucene, I agree with 
[~dsmiley] about 25% reduction in throughput being tiny fraction of typical 
usage. And, throughput should be better if same keys get used for PKLookup 
queries. Adding per field setting might require code change and will be 
effective only for data indexed using new codec. My knowledge of Lucene 
settings is limited and I might be wrong.

> Lazy loading Lucene FST offheap using mmap
> --
>
> Key: LUCENE-8635
> URL: https://issues.apache.org/jira/browse/LUCENE-8635
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs
> Environment: I used below setup for es_rally tests:
> single node i3.xlarge running ES 6.5
> es_rally was running on another i3.xlarge instance
>Reporter: Ankit Jain
>Priority: Major
> Attachments: offheap.patch, rally_benchmark.xlsx
>
>
> Currently, FST loads all the terms into heap memory during index open. This 
> causes frequent JVM OOM issues if the term size gets big. A better way of 
> doing this will be to lazily load FST using mmap. That ensures only the 
> required terms get loaded into memory.
>  
> Lucene can expose API for providing list of fields to load terms offheap. I'm 
> planning to take following approach for this:
>  # Add a boolean property fstOffHeap in FieldInfo
>  # Pass list of offheap fields to lucene during index open (ALL can be 
> special keyword for loading ALL fields offheap)
>  # Initialize the fstOffHeap property during lucene index open
>  # FieldReader invokes default FST constructor or OffHeap constructor based 
> on fstOffHeap field
>  
> I created a patch (that loads all fields offheap), did some benchmarks using 
> es_rally and results look good.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12999) Index replication could delete segments first

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12999:
---

bq. Can you please clarify what you mean by "full replication"?

A full replication is performed when there are segments in master index with 
same name but different size/checksum. It used to be less common in the past 
with master-slave setup , but it's now very common with leader-replica setup in 
SolrCloud.


bq.For example, we often found ourselves in situations where...
Well, in your case it has downloaded the entire leader index to a new directory




> Index replication could delete segments first
> -
>
> Key: SOLR-12999
> URL: https://issues.apache.org/jira/browse/SOLR-12999
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java)
>Reporter: David Smiley
>Priority: Major
>
> Index replication could optionally delete files that it knows will not be 
> needed _first_.  This would reduce disk capacity requirements of Solr, and it 
> would reduce some disk fragmentation when space get tight.
> Solr (IndexFetcher) already grabs the remote file list, and it could see 
> which files it has locally, then delete the others.  Today it asks Lucene to 
> {{deleteUnusedFiles}} at the end.  This new mode would probably only be 
> useful if there is no SolrIndexSearcher open, since it would prevent the 
> removal of files.
> The motivating scenario is a SolrCloud replica that is going into full 
> recovery.  It ought to not be fielding searches.  The code changes would not 
> depend on SolrCloud though.
> This option would have some danger the user should be aware of.  If the 
> replication fails, leaving the local files incomplete/corrupt, the only 
> recourse is to try full replication again.  You can't just give up and field 
> queries.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 1 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/1/

2 tests failed.
FAILED:  org.apache.lucene.document.TestLatLonLineShapeQueries.testRandomBig

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.document.TestLatLonLineShapeQueries

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

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




Build Log:
[...truncated 10816 lines...]
   [junit4] Suite: org.apache.lucene.document.TestLatLonLineShapeQueries
   [junit4]   2> Jan 16, 2019 6:52:36 AM 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.document.TestLatLonLineShapeQueries
   [junit4]   2>1) Thread[id=1, name=main, state=WAITING, group=main]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1252)
   [junit4]   2> at java.lang.Thread.join(Thread.java:1326)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:639)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:496)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394)
   [junit4]   2> at 
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13)
   [junit4]   2>2) Thread[id=16, 
name=TEST-TestLatLonLineShapeQueries.testRandomBig-seed#[37C511586778964F], 
state=RUNNABLE, group=TGRP-TestLatLonLineShapeQueries]
   [junit4]   2> at sun.nio.ch.NativeThread.current(Native Method)
   [junit4]   2> at 
sun.nio.ch.NativeThreadSet.add(NativeThreadSet.java:46)
   [junit4]   2> at 
sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:737)
   [junit4]   2> at 
sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:727)
   [junit4]   2> at 
org.apache.lucene.mockfile.FilterFileChannel.read(FilterFileChannel.java:111)
   [junit4]   2> at 
org.apache.lucene.mockfile.FilterFileChannel.read(FilterFileChannel.java:111)
   [junit4]   2> at 
org.apache.lucene.mockfile.FilterFileChannel.read(FilterFileChannel.java:111)
   [junit4]   2> at 
org.apache.lucene.store.NIOFSDirectory$NIOFSIndexInput.readInternal(NIOFSDirectory.java:179)
   [junit4]   2> at 
org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:342)
   [junit4]   2> at 
org.apache.lucene.store.BufferedIndexInput.readByte(BufferedIndexInput.java:54)
   [junit4]   2> at 
org.apache.lucene.store.MockIndexInputWrapper.readByte(MockIndexInputWrapper.java:140)
   [junit4]   2> at 
org.apache.lucene.store.BufferedChecksumIndexInput.readByte(BufferedChecksumIndexInput.java:41)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextUtil.readLine(SimpleTextUtil.java:59)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextFieldsReader.readFields(SimpleTextFieldsReader.java:103)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextFieldsReader.(SimpleTextFieldsReader.java:88)
   [junit4]   2> at 
org.apache.lucene.codecs.simpletext.SimpleTextPostingsFormat.fieldsProducer(SimpleTextPostingsFormat.java:50)
   [junit4]   2> at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:113)
   [junit4]   2> at 
org.apache.lucene.index.SegmentReader.(SegmentReader.java:83)
   [junit4]   2> at 
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:172)
   [junit4]   2> at 
org.apache.lucene.index.BufferedUpdatesStream$SegmentState.(BufferedUpdatesStream.java:271)
   [junit4]   2> at 
org.apache.lucene.index.FrozenBufferedUpdates.openSegmentStates(FrozenBufferedUpdates.java:328)
   [junit4]   2> at 
org.apache.lucene.index.FrozenBufferedUpdates.forceApply(FrozenBufferedUpdates.java:222)
   [junit4]   2> at 
org.apache.lucene.index.FrozenBufferedUpdates.tryApply(FrozenBufferedUpdates.java:160)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.lambda$publishFrozenUpdates$3(IndexWriter.java:2589)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter$$Lambda$59/448719248.process(Unknown Source)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5112)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1597)
   [junit4]   2> at 
org.

[jira] [Commented] (SOLR-13007) Use javabin instead of JSON to send messages to overseer

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13007:
---

{quote}Seems like javabin can be quite easily used to send messages to overseer 
using the work queues, and then have overseer compute the final cluster state 
as JSON.
{quote}
 

Yes, that was added to support both json and javabin

 bq.The messages to the overseer are usually very small, I don't think the gain 
will be that much (speed or size)

Well, the messages are small. But the no:of messages we process are sometimes 
1000s every second for a very large cluster. My own benchmark shows that even 
for small messages it can be 20% to 30% in encoding  decoding. I'm in the 
process of making a lot many more improvements to javabin encoding/decoding  
and that can make the perf improvements  even more significant.

This is a micro optimization. Not very essential and it is not very urgent

> Use javabin instead of JSON to send messages to overseer
> 
>
> Key: SOLR-13007
> URL: https://issues.apache.org/jira/browse/SOLR-13007
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> The messages themselves are ephemeral and the readability is not a big issue. 
> Using javabin can:
> * reduce the payload size
> * make processing faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12194:
---

[~janhoy] can you write down how it looks when the new API is implemented. I 
just hope it doesn't make it far too unfriendly

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-12-ea+23) - Build # 36 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/36/
Java: 64bit/jdk-12-ea+23 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventQueue

Error Message:
action wasn't interrupted

Stack Trace:
java.lang.AssertionError: action wasn't interrupted
at 
__randomizedtesting.SeedInfo.seed([FCBBB2AC9FCECAC8:350EF00296A90C3D]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration.testEventQueue(TestSimTriggerIntegration.java:718)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 13353 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.autoscaling.sim.TestSimTriggerInteg

[jira] [Commented] (SOLR-12373) DocBasedVersionConstraintsProcessor doesn't work when schema has required fields

[JIRA]

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

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

[~hossman], let me know if you have any thoughts on the latest patch. I think 
it addresses your comments.

> DocBasedVersionConstraintsProcessor doesn't work when schema has required 
> fields
> 
>
> Key: SOLR-12373
> URL: https://issues.apache.org/jira/browse/SOLR-12373
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Attachments: SOLR-12373.patch, SOLR-12373.patch, SOLR-12373.patch
>
>
> DocBasedVersionConstraintsProcessor creates tombstones when processing a 
> delete by id. Those tombstones only have id (or whatever the unique key name 
> is) and version field(s), however, if the schema defines some required 
> fields, adding the tombstone will fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk1.8.0_172) - Build # 11 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/11/
Java: 64bit/jdk1.8.0_172 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution

Error Message:
0.8532264234705607 0.8742250101502959

Stack Trace:
java.lang.AssertionError: 0.8532264234705607 0.8742250101502959
at 
__randomizedtesting.SeedInfo.seed([3F848262E387BCFC:2FEA9CCC0FF16EB]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.client.solrj.io.stream.MathExpressionTest.testGammaDistribution(MathExpressionTest.java:4501)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 16305 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.stream.MathExpressionTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-solrj\test\J0\temp

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-12-ea+23) - Build # 23527 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23527/
Java: 64bit/jdk-12-ea+23 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<233520.0> but was:<2896.0>

Stack Trace:
java.lang.AssertionError: expected:<233520.0> but was:<2896.0>
at 
__randomizedtesting.SeedInfo.seed([82AA6096F7B610C1:700972D63DC90F97]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed(TermInSetQueryTest.java:186)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)


FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<233520.0> but was:<2896.0>

Stack Trace:
java.lang.AssertionError: expected:<233520.0> but was:<2896.0>
at 
__randomizedtesting.SeedInfo.seed([82AA6096F7B610C1:700972D63DC90F97]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.se

Re: Three quick questions

[John Wilson]

Got it, thanks.

On Mon, Jan 14, 2019 at 6:01 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Hi John,
>
> 1. When the total size across all in memory segments crosses 100 MB, then
> IW will pick the largest segment(s) to move to disk
> 2. There are in memory segments; when an indexing thread comes in, it will
> write to one segment and no other thread can write to that segment while
> that thread is indexing the one document.  We used to have some thread
> affinity so a given thread would prefer to write to the same in-memory
> segment but I think we don't do that anymore.  If an indexing thread
> arrives to index a doc, but all in memory segments are already handling
> other documents, then we will create a new in-memory segment for that
> thread to write to.
> 3. Should be .del files
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Jan 7, 2019 at 7:08 PM John Wilson 
> wrote:
>
>> Hi,
>>
>>
>>1. Assume I have two index writer threads using an IndexWriter object
>>(IndexWriter is thread safe) and my ramBufferSizeMB is set to 100M, then
>>are segments created when each thread writes 100M or when the total size
>>written in the buffers is 100M?
>>2. Does each index writer thread writes its own segment or the two
>>writers can write to the same segment (requiring synchronization)?
>>3. When a document is deleted/updated, the document is marked and
>>this info is stored in a separate file so that the next merge deletes the
>>document. What would be a typical name (or extension) of the file in my
>>index directory?
>>
>> Thanks,
>> John
>>
>

[jira] [Created] (SOLR-13140) Harden SearchRateTriggerIntegrationTest

[Hoss Man (JIRA)]

Hoss Man created SOLR-13140:
---

 Summary: Harden SearchRateTriggerIntegrationTest
 Key: SOLR-13140
 URL: https://issues.apache.org/jira/browse/SOLR-13140
 Project: Solr
  Issue Type: Sub-task
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12584) Add basic auth credentials configuration to the Solr exporter for Prometheus/Grafana

[Bill Vandenberk (JIRA)]

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

Bill Vandenberk commented on SOLR-12584:


It would be great to get this patched! The exporter also doesn't support 
zookeeper ACLs, so when you're trying to setup a secure solr cluster, it's hard 
to get the metrics out of it at all!

> Add basic auth credentials configuration to the Solr exporter for 
> Prometheus/Grafana  
> --
>
> Key: SOLR-12584
> URL: https://issues.apache.org/jira/browse/SOLR-12584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication, metrics, security
>Affects Versions: 7.3, 7.4
>Reporter: Dwane Hall
>Priority: Minor
>  Labels: authentication, metrics, security
> Attachments: lucene-solr.patch
>
>
> The Solr exporter for Prometheus/Grafana provides a useful visual layer over 
> the solr metrics api for monitoring the state of a Solr cluster. Currently 
> this can not be configured and used on a secure Solr cluster with the Basic 
> Authentication plugin enabled. The exporter does not provide a mechanism to 
> configure/pass through basic auth credentials when SolrJ requests information 
> from the metrics api endpoints and would be a useful addition for Solr users 
> running a secure Solr instance.   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-10.0.1) - Build # 959 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/959/
Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [SolrZkClient, 
ZkStateReader] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.SolrZkClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:306)  at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:950)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:997)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:837)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:813)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$3(ScheduledTriggers.java:323)
  at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.ZkStateReader  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:328)  
at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:950)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:997)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:837)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:813)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$3(ScheduledTriggers.java:323)
  at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
  at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.base/java.lang.Thread.run(Thread.java:844)   expected null, but 
was:(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.sol

[jira] [Commented] (SOLR-13007) Use javabin instead of JSON to send messages to overseer

[JIRA]

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

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

Yes, I don't think this would be particularly difficult to implement, but 
again, unless there are benchmarks that prove a big speedup/improvement I don't 
think we should do it. Back compatibility should also be considered

> Use javabin instead of JSON to send messages to overseer
> 
>
> Key: SOLR-13007
> URL: https://issues.apache.org/jira/browse/SOLR-13007
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> The messages themselves are ephemeral and the readability is not a big issue. 
> Using javabin can:
> * reduce the payload size
> * make processing faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12770) Make it possible to configure a shards whitelist for master/slave

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12770:


Commit 6d63958821232699f0a8423d9b21d4915bfba64e in lucene-solr's branch 
refs/heads/branch_7x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6d63958 ]

SOLR-12770: Make it possible to configure a host whitelist for distributed 
search


> Make it possible to configure a shards whitelist for master/slave
> -
>
> Key: SOLR-12770
> URL: https://issues.apache.org/jira/browse/SOLR-12770
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: masterSlave
>
> For legacy master/slave clusters, there is no Zookeeper to keep track of all 
> the nodes and shards in the cluster. So users manage the 'shards' parameter 
> manually for distributed search. This issue will add the option of 
> configuring a list of what shards can be requested.
> Users will then get an explicit error response if the request includes a 
> shard which is not in the preconfigured whitelist, e.g. due to a typo. I 
> think all shards logic is handled by HttpShardHandler already so the logic 
> should fit nicely in that one class, configured in {{solr.xml}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_172) - Build # 7696 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7696/
Java: 32bit/jdk1.8.0_172 -server -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimExtremeIndexing.testScaleUp

Error Message:
{numFound=97300,start=0,docs=[]} expected:<10> but was:<97300>

Stack Trace:
java.lang.AssertionError: {numFound=97300,start=0,docs=[]} 
expected:<10> but was:<97300>
at 
__randomizedtesting.SeedInfo.seed([6F003D6F2C9463E5:4E5E7BCD20BABD44]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimExtremeIndexing.testScaleUp(TestSimExtremeIndexing.java:135)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14021 lines...]
   [junit4] Suite: org.apache.solr.cloud.autoscaling.sim.TestSimExtremeIndexi

[GitHub] barrotsteindev commented on issue #528: SOLR-12955 2

[GitBox]

barrotsteindev commented on issue #528: SOLR-12955 2
URL: https://github.com/apache/lucene-solr/pull/528#issuecomment-454528785
 
 
   Hey @dsmiley ,
   Have you had time to look around?
   Should I upload a patch in the meantime so all tests will be run(I did run 
the Solr test suite which seems to pass).
   Thanks in advance.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[JENKINS] Lucene-Solr-Tests-master - Build # 3147 - Unstable

[Apache Jenkins Server]

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

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

Error Message:
ObjectTracker found 2 object(s) that were not released!!! [SolrZkClient, 
ZkStateReader] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.SolrZkClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:203)  
at org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:126)  at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:116)  at 
org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:306)  at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:950)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:836)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:807)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:302)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:633)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.common.cloud.ZkStateReader  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.common.cloud.ZkStateReader.(ZkStateReader.java:328)  
at 
org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.connect(ZkClientClusterStateProvider.java:160)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.connect(CloudSolrClient.java:399)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:827)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:950)
  at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817)
  at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)  at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)  at 
org.apache.solr.client.solrj.impl.SolrClientCloudManager.request(SolrClientCloudManager.java:115)
  at 
org.apache.solr.cloud.autoscaling.SystemLogListener.onEvent(SystemLogListener.java:126)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:836)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerListeners.fireListeners(ScheduledTriggers.java:807)
  at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers.lambda$add$4(ScheduledTriggers.java:302)
  at 
org.apache.solr.cloud.autoscaling.NodeLostTrigger.run(NodeLostTrigger.java:185) 
 at 
org.apache.solr.cloud.autoscaling.ScheduledTriggers$TriggerWrapper.run(ScheduledTriggers.java:633)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)  
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
  at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6

[jira] [Commented] (SOLR-13007) Use javabin instead of JSON to send messages to overseer

[Bar Rotstein (JIRA)]

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

Bar Rotstein commented on SOLR-13007:
-

Observing ZkNodeProps#load:
{code:java}/**
   * Create Replica from json string that is typically stored in zookeeper.
   */
  public static ZkNodeProps load(byte[] bytes) {
Map props = null;
if (bytes[0] == 2) {
  try {
props = (Map) new JavaBinCodec().unmarshal(bytes);
  } catch (IOException e) {
throw new RuntimeException("Unable to parse javabin content");
  }
} else {
  props = (Map) Utils.fromJSON(bytes);
}
return new ZkNodeProps(props);
  }{code}
Seems like javabin can be quite easily used to send messages to overseer using 
the work queues, and then have overseer compute the final cluster state as JSON.
Is that what you had in mind [~noble.paul]?
WDYT?

> Use javabin instead of JSON to send messages to overseer
> 
>
> Key: SOLR-13007
> URL: https://issues.apache.org/jira/browse/SOLR-13007
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Priority: Major
>
> The messages themselves are ephemeral and the readability is not a big issue. 
> Using javabin can:
> * reduce the payload size
> * make processing faster



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12770) Make it possible to configure a shards whitelist for master/slave

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12770:


Commit e9db95831b9db69fbc0bef499b0d3f41bc6448f1 in lucene-solr's branch 
refs/heads/branch_8x from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e9db958 ]

SOLR-12770: Make it possible to configure a host whitelist for distributed 
search


> Make it possible to configure a shards whitelist for master/slave
> -
>
> Key: SOLR-12770
> URL: https://issues.apache.org/jira/browse/SOLR-12770
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: masterSlave
>
> For legacy master/slave clusters, there is no Zookeeper to keep track of all 
> the nodes and shards in the cluster. So users manage the 'shards' parameter 
> manually for distributed search. This issue will add the option of 
> configuring a list of what shards can be requested.
> Users will then get an explicit error response if the request includes a 
> shard which is not in the preconfigured whitelist, e.g. due to a typo. I 
> think all shards logic is handled by HttpShardHandler already so the logic 
> should fit nicely in that one class, configured in {{solr.xml}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12770) Make it possible to configure a shards whitelist for master/slave

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12770:


Commit 8b54b20fc488ae3e83f4a350a707dc0303ade230 in lucene-solr's branch 
refs/heads/master from Tomas Eduardo Fernandez Lobbe
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8b54b20 ]

SOLR-12770: Make it possible to configure a host whitelist for distributed 
search


> Make it possible to configure a shards whitelist for master/slave
> -
>
> Key: SOLR-12770
> URL: https://issues.apache.org/jira/browse/SOLR-12770
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: masterSlave
>
> For legacy master/slave clusters, there is no Zookeeper to keep track of all 
> the nodes and shards in the cluster. So users manage the 'shards' parameter 
> manually for distributed search. This issue will add the option of 
> configuring a list of what shards can be requested.
> Users will then get an explicit error response if the request includes a 
> shard which is not in the preconfigured whitelist, e.g. due to a typo. I 
> think all shards logic is handled by HttpShardHandler already so the logic 
> should fit nicely in that one class, configured in {{solr.xml}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13139) RefGuide: fix date range syntax

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13139:
-

Ideally the delimiter should be validated.

> RefGuide: fix date range syntax 
> 
>
> Key: SOLR-13139
> URL: https://issues.apache.org/jira/browse/SOLR-13139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13139.patch
>
>
> https://lucene.apache.org/solr/guide/7_6/working-with-dates.html suggests 
> {{2000-11T13}} as a date range that makes to sense. It's worth to suggest the 
> correct syntax at least, not sure about adding explanation or validating 
> delimiters. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8620) Add CONTAINS support for LatLonShape

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8620:
--

Thanks Ignacio and sorry for taking so long to have a look. A few 
comments/questions:
 - Rectangle2D#withinTriangle and EdgeTree#withinTriangle are a bit hard to 
read, I think a dedicated enum and better javadocs (eg. with your description 
in the previous comment) would help.
 - Does Rectangle2D#withinTriangle actually return true if the box is within 
the triangle but touches an edge of the triangle?
 - Several tests do assertTrue(a == b) but assertEquals would make test 
failures easier to dig.
 - In Tessellator naming is a bit confusing at times. Eg. {{boolean 
cFromPolygon = (b.next == a) ? b.nextFromPolygon : false;}} is confusing since 
it's called "cFromPolygon" while it actually tests whether the ba edge belongs 
to the polygon.
 - Why did you add checks for the bounding box in Tessellator#pointInTriangle?
 - Can Tessellator.Triangle record a boolean[] or use the 3 lower bits of a 
byte instead of three properties regarding whether edges are shared with the 
polygon? This would be more aligned with the fact that it also records a Node[] 
rather than 3 Node properties?
 - Maybe remove the LatLonTriangle constructor that doesn't take booleans. It 
would usually be a mistake to use it?
 - I am confused by the logic in encodeTriangle. How can we make assumptions 
like {{ab = aFromShape}}. This seems to be making assumptions on how the 
tessellator works? It is generally not possible to know whether an edge belongs 
to the original polygon only based on whether vertices belong to the original 
polygon?

> Add CONTAINS support for LatLonShape
> 
>
> Key: LUCENE-8620
> URL: https://issues.apache.org/jira/browse/LUCENE-8620
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/sandbox
>Reporter: Ignacio Vera
>Priority: Major
> Fix For: 8.0, 7.7
>
> Attachments: LUCENE-8620.patch
>
>
> Currently the only spatial operation that cannot be performed using 
> {{LatLonShape}} is CONTAINS. This issue will add such capability by tracking 
> if an edge of a generated triangle from the {{Tessellator}} is an edge of the 
> polygon.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Re: Admin UI - Collections Management

[Erick Erickson]

bq: Thoughts?

I don't do UI work so I just sit back and cheer ;)

Then I do, of course have thoughts...

Mostly, when you're thinking about this think about scale. For
instance, the graph view is nice for a few nodes/collections. 1,000
collections (yes, some people scale that way) with even 2x2
collections is almost, but not quite totally, unusable. Maybe
copy/paste or cut/paste? Or some way to restrict what's shown to the
relevant nodes? More generally how to navigate around when there are
zillions of replicas

Best,
Erick


On Tue, Jan 15, 2019 at 8:39 AM Branham, Jeremy (Experis)
 wrote:
>
> Thanks Erick –
> I used the MOVEREPLICA command to shuffle them around, but like you 
> mentioned, I had to look up nodes names and such.
> I’m on the same page; drag-n-drop replica organization.
>
> I was looking at the newest section in the admin-ui  “Cloud > Nodes”
> Maybe we could add the drag-n-drop functionality to that last column, where 
> the replicas are listed by node. I think we have all the data required in 
> that view to construct a MOVEREPLICA command.
>
> Thoughts?
>
>
> Jeremy Branham
> jb...@allstate.com
>
> On 1/14/19, 4:55 PM, "Erick Erickson"  wrote:
>
> bq. The collections API allowed me to move the replicas around by
> investigating the core names and locations,
>
> What about the MOVEREPLICA command?
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org_solr_guide_6-5F6_collections-2Dapi.html&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=037mwmgIodjUnHNITRxTA5FJu2QXK_AYmNgd-oCyfxU&e=
>
> Although that still requires you to know things like node names and
> replica names. It'd be way cool to have
> some kind of drag-n-drop or wizard-driven capability, perhaps built on
> top of that. In addition to Jan's
> suggestions.
>
> Best,
> Erick
>
> On Mon, Jan 14, 2019 at 2:37 PM Jan Høydahl  wrote:
> >
> > Hi and thanks for offering to help.
> >
> > If you are not familiar with the new Autoscaling framework, I'd start 
> by exploring it, since it aims at solving replica placement without explicit 
> commands.
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org_solr_guide_7-5F6_solrcloud-2Dautoscaling.html&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=SRn57bErK14_HIBo5zPxDGt8KgkslZhmB2zNNCd2jXc&e=
> >
> > Next, I'd try to find an open JIRA issue to solve, perhaps something 
> related to Collections API and/or Admin UI. Pick something very simple, just 
> to get started with the procedure of contributing, and then look at e.g. 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D10209&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=XB6iMPC0x1pEBUc-i-g8TwI9Y9QuQHcT87S-0Qx3NV8&e=
>  which seems related in that it aims to expose collection api through UI
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cominvent.com&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=YUNZMwT6xSa-P3X04jHMB58-A-jn5E9PII77JqfQceo&e=
> >
> > 14. jan. 2019 kl. 21:39 skrev Branham, Jeremy (Experis) 
> :
> >
> > I recently split some shards, and the new replicas didn’t go to the 
> nodes I wanted them.
> > The collections API allowed me to move the replicas around by 
> investigating the core names and locations, then constructing the correct 
> urls to execute the moves.
> > This worked, but it would have been faster if the admin UI supported 
> such operations.
> >
> > Is this something I could contribute to? Maybe a PR in GitHub?
> > I’ve been a solr user for quite a while and would like to start giving 
> back some.
> >
> > Thanks!
> >
> > Jeremy Branham
> > jb...@allstate.com
> > Allstate Insurance Company | UCV Technology Services | Information 
> Services Group
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.4) - Build # 23526 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23526/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<237616.0> but was:<2944.0>

Stack Trace:
java.lang.AssertionError: expected:<237616.0> but was:<2944.0>
at 
__randomizedtesting.SeedInfo.seed([39D1BD17CEFBFCB2:CB72AF570484E3E4]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed(TermInSetQueryTest.java:186)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.lucene.search.TermInSetQueryTest.testRamBytesUsed

Error Message:
expected:<237616.0> but was:<2944.0>

Stack Trace:
java.lang.AssertionError: expected:<237616.0> but was:<2944.0>
at 
__randomizedtesting.SeedInfo.seed([39D1BD17CEFBFCB2:CB72AF570484E3E4]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:575)
at org.junit.Assert.assertEquals(Assert.java:700)
at 
org.apache.lucene.search.TermInSet

[jira] [Commented] (LUCENE-8635) Lazy loading Lucene FST offheap using mmap

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8635:
--

+1 looks valuable, especially for cases where you don't necessarily want to 
always bring the FSTs into memory since it's inherently lazy-load.

The PK lookup doesn't concern me much since such queries would usually already 
be fast and overall a tiny fraction of a search platform in typical usage.

Ideally this setting could be toggled on a per-field basis.

> Lazy loading Lucene FST offheap using mmap
> --
>
> Key: LUCENE-8635
> URL: https://issues.apache.org/jira/browse/LUCENE-8635
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs
> Environment: I used below setup for es_rally tests:
> single node i3.xlarge running ES 6.5
> es_rally was running on another i3.xlarge instance
>Reporter: Ankit Jain
>Priority: Major
> Attachments: offheap.patch, rally_benchmark.xlsx
>
>
> Currently, FST loads all the terms into heap memory during index open. This 
> causes frequent JVM OOM issues if the term size gets big. A better way of 
> doing this will be to lazily load FST using mmap. That ensures only the 
> required terms get loaded into memory.
>  
> Lucene can expose API for providing list of fields to load terms offheap. I'm 
> planning to take following approach for this:
>  # Add a boolean property fstOffHeap in FieldInfo
>  # Pass list of offheap fields to lucene during index open (ALL can be 
> special keyword for loading ALL fields offheap)
>  # Initialize the fstOffHeap property during lucene index open
>  # FieldReader invokes default FST constructor or OffHeap constructor based 
> on fstOffHeap field
>  
> I created a patch (that loads all fields offheap), did some benchmarks using 
> es_rally and results look good.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Re: Admin UI - Collections Management

[Branham, Jeremy (Experis)]

Thanks Erick – 
I used the MOVEREPLICA command to shuffle them around, but like you mentioned, 
I had to look up nodes names and such.
I’m on the same page; drag-n-drop replica organization.

I was looking at the newest section in the admin-ui  “Cloud > Nodes”
Maybe we could add the drag-n-drop functionality to that last column, where the 
replicas are listed by node. I think we have all the data required in that view 
to construct a MOVEREPLICA command.

Thoughts?

 
Jeremy Branham
jb...@allstate.com

On 1/14/19, 4:55 PM, "Erick Erickson"  wrote:

bq. The collections API allowed me to move the replicas around by
investigating the core names and locations,

What about the MOVEREPLICA command?

https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org_solr_guide_6-5F6_collections-2Dapi.html&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=037mwmgIodjUnHNITRxTA5FJu2QXK_AYmNgd-oCyfxU&e=

Although that still requires you to know things like node names and
replica names. It'd be way cool to have
some kind of drag-n-drop or wizard-driven capability, perhaps built on
top of that. In addition to Jan's
suggestions.

Best,
Erick

On Mon, Jan 14, 2019 at 2:37 PM Jan Høydahl  wrote:
>
> Hi and thanks for offering to help.
>
> If you are not familiar with the new Autoscaling framework, I'd start by 
exploring it, since it aims at solving replica placement without explicit 
commands.
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lucene.apache.org_solr_guide_7-5F6_solrcloud-2Dautoscaling.html&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=SRn57bErK14_HIBo5zPxDGt8KgkslZhmB2zNNCd2jXc&e=
>
> Next, I'd try to find an open JIRA issue to solve, perhaps something 
related to Collections API and/or Admin UI. Pick something very simple, just to 
get started with the procedure of contributing, and then look at e.g. 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_SOLR-2D10209&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=XB6iMPC0x1pEBUc-i-g8TwI9Y9QuQHcT87S-0Qx3NV8&e=
 which seems related in that it aims to expose collection api through UI
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cominvent.com&d=DwIFaQ&c=gtIjdLs6LnStUpy9cTOW9w&r=0SwsmPELGv6GC1_5JSQ9T7ZPMLljrIkbF_2jBCrKXI0&m=H4NKUT5exNIKdsoam9tBFwkVy-6YdmME9JkEo0ISjnk&s=YUNZMwT6xSa-P3X04jHMB58-A-jn5E9PII77JqfQceo&e=
>
> 14. jan. 2019 kl. 21:39 skrev Branham, Jeremy (Experis) 
:
>
> I recently split some shards, and the new replicas didn’t go to the nodes 
I wanted them.
> The collections API allowed me to move the replicas around by 
investigating the core names and locations, then constructing the correct urls 
to execute the moves.
> This worked, but it would have been faster if the admin UI supported such 
operations.
>
> Is this something I could contribute to? Maybe a PR in GitHub?
> I’ve been a solr user for quite a while and would like to start giving 
back some.
>
> Thanks!
>
> Jeremy Branham
> jb...@allstate.com
> Allstate Insurance Company | UCV Technology Services | Information 
Services Group
>
>
>

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

[jira] [Commented] (SOLR-13137) NPE when /admin/zookeeper/status endpoint hit in standalone mode

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13137:


Commit 3f87dd9e6e3d78c38d765a7dd934934550bb4d1a in lucene-solr's branch 
refs/heads/branch_7x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3f87dd9 ]

SOLR-13137: NPE when /admin/zookeeper/status endpoint hit in standalone mode

(cherry picked from commit b7f99fe55a6fb6e7b38828676750b3512d6899a1)


> NPE when /admin/zookeeper/status endpoint hit in standalone mode
> 
>
> Key: SOLR-13137
> URL: https://issues.apache.org/jira/browse/SOLR-13137
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Attempting to hit [http://localhost:8983/solr/admin/zookeeper/status] when 
> not in cloud mode produces NPE. Should instead return a 400 error with 
> description.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 2684 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2684/

[...truncated 28 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/432/consoleText

[repro] Revision: 35955b3891ed6621d5faa1c2c20ce0a333bc7b83

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=ForceLeaderTest 
-Dtests.method=testReplicasInLIRNoLeader -Dtests.seed=CD8D4CEA280B801A 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-MT -Dtests.timezone=Australia/Lindeman -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] Repro line:  ant test  -Dtestcase=LIROnShardRestartTest 
-Dtests.method=testAllReplicasInLIR -Dtests.seed=CD8D4CEA280B801A 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=vi-VN -Dtests.timezone=Africa/El_Aaiun -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
d4e016afdf41baf0104f79e82d953a4650df42aa
[repro] git fetch
[repro] git checkout 35955b3891ed6621d5faa1c2c20ce0a333bc7b83

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   LIROnShardRestartTest
[repro]   ForceLeaderTest
[repro] ant compile-test

[...truncated 3605 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 
-Dtests.class="*.LIROnShardRestartTest|*.ForceLeaderTest" 
-Dtests.showOutput=onerror -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=CD8D4CEA280B801A -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=vi-VN -Dtests.timezone=Africa/El_Aaiun -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[...truncated 8132 lines...]
   [junit4]   2> 304317 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.AbstractFullDistribZkTestBase ERROR: 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request. ... Sleeping for 1 seconds before re-try ...
   [junit4]   2> 305317 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=0 commError=false errorCode=510 
   [junit4]   2> 305317 INFO  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 305317 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Re-trying request to collection(s) 
[forceleader_lower_terms_collection] after stale state error from server.
   [junit4]   2> 305318 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=1 commError=false errorCode=510 
   [junit4]   2> 305318 INFO  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 305318 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Re-trying request to collection(s) 
[forceleader_lower_terms_collection] after stale state error from server.
   [junit4]   2> 305318 ERROR 
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Request to collection 
[forceleader_lower_terms_collection] failed due to (510) 
org.apache.solr.common.SolrException: Could not find a healthy node to handle 
the request., retry=2 commError=false errorCode=510 
   [junit4]   2> 305318 INFO  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient request was not communication error it seems
   [junit4]   2> 305319 WARN  
(TEST-ForceLeaderTest.testReplicasInLowerTerms-seed#[CD8D4CEA280B801A]) [] 
o.a.s.c.s.i.CloudSolrClient Re-trying req

[GitHub] janhoy commented on issue #441: SOLR-11690: Improve documentation about DIH password encryption

[GitBox]

janhoy commented on issue #441: SOLR-11690: Improve documentation about DIH 
password encryption
URL: https://github.com/apache/lucene-solr/pull/441#issuecomment-454456865
 
 
   Also Fixes #277 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] janhoy closed pull request #336: SOLR-11774 langid.map.individual broken

[GitBox]

janhoy closed pull request #336: SOLR-11774 langid.map.individual broken
URL: https://github.com/apache/lucene-solr/pull/336
 
 
   

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@lucene.apache.org


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] janhoy closed pull request #441: SOLR-11690: Improve documentation about DIH password encryption

[GitBox]

janhoy closed pull request #441: SOLR-11690: Improve documentation about DIH 
password encryption
URL: https://github.com/apache/lucene-solr/pull/441
 
 
   

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@lucene.apache.org


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] janhoy closed pull request #353: SOLR-12194: Deprecate SolrRequest#setBasicAuthCredentials

[GitBox]

janhoy closed pull request #353: SOLR-12194: Deprecate 
SolrRequest#setBasicAuthCredentials
URL: https://github.com/apache/lucene-solr/pull/353
 
 
   

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@lucene.apache.org


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Resolved] (SOLR-13137) NPE when /admin/zookeeper/status endpoint hit in standalone mode

[JIRA]

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

Jan Høydahl resolved SOLR-13137.

   Resolution: Fixed
Fix Version/s: (was: master (9.0))

> NPE when /admin/zookeeper/status endpoint hit in standalone mode
> 
>
> Key: SOLR-13137
> URL: https://issues.apache.org/jira/browse/SOLR-13137
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Attempting to hit [http://localhost:8983/solr/admin/zookeeper/status] when 
> not in cloud mode produces NPE. Should instead return a 400 error with 
> description.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] janhoy closed pull request #534: SOLR-13137: NPE when /admin/zookeeper/statusin standalone mode

[GitBox]

janhoy closed pull request #534: SOLR-13137: NPE when /admin/zookeeper/statusin 
standalone mode
URL: https://github.com/apache/lucene-solr/pull/534
 
 
   

As this is a foreign pull request (from a fork), the diff has been
sent to your commit mailing list, comm...@lucene.apache.org


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8639) SeqNo accounting in IW is broken if many threads start indexing while we flush.

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8639:
-

[~mikemccand] can you take a look at the PR?

> SeqNo accounting in IW is broken if many threads start indexing while we 
> flush.
> ---
>
> Key: LUCENE-8639
> URL: https://issues.apache.org/jira/browse/LUCENE-8639
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Simon Willnauer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> While this is rare in the wild we have a test failure that shows that our 
> seqNo accounting is broken  when we carry over seqNo to a new delete queue. 
> We had this test-failure:
> {noformat}
> 6:06:08[junit4] Suite: org.apache.lucene.index.TestIndexTooManyDocs
> 16:06:08[junit4]   2> ??? 14, 2019 9:05:46 ? 
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
>  uncaughtException
> 16:06:08[junit4]   2> WARNING: Uncaught exception in thread: 
> Thread[Thread-8,5,TGRP-TestIndexTooManyDocs]
> 16:06:08[junit4]   2> java.lang.AssertionError: seqNo=7 vs maxSeqNo=6
> 16:06:08[junit4]   2> at 
> __randomizedtesting.SeedInfo.seed([43B7C75B765AFEBD]:0)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.getNextSequenceNumber(DocumentsWriterDeleteQueue.java:482)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:168)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:146)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterPerThread.finishDocument(DocumentsWriterPerThread.java:362)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:264)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1586)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$0(TestIndexTooManyDocs.java:70)
> 16:06:08[junit4]   2> at java.lang.Thread.run(Thread.java:748)
> 16:06:08[junit4]   2> 
> 16:06:08[junit4]   2> ??? 14, 2019 9:05:46 ? 
> com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
>  uncaughtException
> 16:06:08[junit4]   2> WARNING: Uncaught exception in thread: 
> Thread[Thread-9,5,TGRP-TestIndexTooManyDocs]
> 16:06:08[junit4]   2> java.lang.AssertionError: seqNo=6 vs maxSeqNo=6
> 16:06:08[junit4]   2> at 
> __randomizedtesting.SeedInfo.seed([43B7C75B765AFEBD]:0)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.getNextSequenceNumber(DocumentsWriterDeleteQueue.java:482)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:168)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:146)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterPerThread.finishDocument(DocumentsWriterPerThread.java:362)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:264)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1586)
> 16:06:08[junit4]   2> at 
> org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$0(TestIndexTooManyDocs.java:70)
> 16:06:08[junit4]   2> at java.lang.Thread.run(Thread.java:748)
> 16:06:08[junit4]   2> 
> 16:06:08[junit4]   2> ??? 14, 2019 11:05:45 ? 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
> 16:06:08[junit4]   2> WARNING: Suite execution timed out: 
> org.apache.lucene.index.TestIndexTooManyDocs
> 16:06:08[junit4]   2>1) Thread[id=20, 
> name=SUITE-TestIndexTooManyDocs-seed#[43B7C75B765AFEBD], state=RUNNABLE, 
> group=TGRP-TestIndexTooManyDocs]
> 16:06:08[junit4]   2> at 
> java.lang.Thread.getStackTrace(Thread.java:1559)
> 16:06:08[junit4]   2> at 

[GitHub] s1monw opened a new pull request #535: LUCENE-8639: Prevent new threadstates from being created while we cut over to a new delete queue

[GitBox]

s1monw opened a new pull request #535: LUCENE-8639: Prevent new threadstates 
from being created while we cut over to a new delete queue
URL: https://github.com/apache/lucene-solr/pull/535
 
 
   This prevents an edge case where suddenly a lot of threads start indexing
   while we carry over sequence ids from the previous to the new delete queue.
   We now lock creation of new thread states for a very short time until we 
created and assigned
   a new delete queue.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Created] (LUCENE-8639) SeqNo accounting in IW is broken if many threads start indexing while we flush.

[Simon Willnauer (JIRA)]

Simon Willnauer created LUCENE-8639:
---

 Summary: SeqNo accounting in IW is broken if many threads start 
indexing while we flush.
 Key: LUCENE-8639
 URL: https://issues.apache.org/jira/browse/LUCENE-8639
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Simon Willnauer


While this is rare in the wild we have a test failure that shows that our seqNo 
accounting is broken  when we carry over seqNo to a new delete queue. We had 
this test-failure:

{noformat}
6:06:08[junit4] Suite: org.apache.lucene.index.TestIndexTooManyDocs
16:06:08[junit4]   2> ??? 14, 2019 9:05:46 ? 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
16:06:08[junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-8,5,TGRP-TestIndexTooManyDocs]
16:06:08[junit4]   2> java.lang.AssertionError: seqNo=7 vs maxSeqNo=6
16:06:08[junit4]   2>   at 
__randomizedtesting.SeedInfo.seed([43B7C75B765AFEBD]:0)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.getNextSequenceNumber(DocumentsWriterDeleteQueue.java:482)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:168)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:146)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterPerThread.finishDocument(DocumentsWriterPerThread.java:362)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:264)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1586)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$0(TestIndexTooManyDocs.java:70)
16:06:08[junit4]   2>   at java.lang.Thread.run(Thread.java:748)
16:06:08[junit4]   2> 
16:06:08[junit4]   2> ??? 14, 2019 9:05:46 ? 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
16:06:08[junit4]   2> WARNING: Uncaught exception in thread: 
Thread[Thread-9,5,TGRP-TestIndexTooManyDocs]
16:06:08[junit4]   2> java.lang.AssertionError: seqNo=6 vs maxSeqNo=6
16:06:08[junit4]   2>   at 
__randomizedtesting.SeedInfo.seed([43B7C75B765AFEBD]:0)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.getNextSequenceNumber(DocumentsWriterDeleteQueue.java:482)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:168)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterDeleteQueue.add(DocumentsWriterDeleteQueue.java:146)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterPerThread.finishDocument(DocumentsWriterPerThread.java:362)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:264)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1594)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1586)
16:06:08[junit4]   2>   at 
org.apache.lucene.index.TestIndexTooManyDocs.lambda$testIndexTooManyDocs$0(TestIndexTooManyDocs.java:70)
16:06:08[junit4]   2>   at java.lang.Thread.run(Thread.java:748)
16:06:08[junit4]   2> 
16:06:08[junit4]   2> ??? 14, 2019 11:05:45 ? 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
16:06:08[junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.index.TestIndexTooManyDocs
16:06:08[junit4]   2>1) Thread[id=20, 
name=SUITE-TestIndexTooManyDocs-seed#[43B7C75B765AFEBD], state=RUNNABLE, 
group=TGRP-TestIndexTooManyDocs]
16:06:08[junit4]   2> at 
java.lang.Thread.getStackTrace(Thread.java:1559)
16:06:08[junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:696)
16:06:08[junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$4.run(ThreadLeakControl.java:693)
16:06:08[junit4]   2> at 
java.security.AccessController.doPrivileged(Native Method)
16:06:08[junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.getStackTrace(ThreadLeakControl.java:693)
16:06:08[junit4]   2> at 

[jira] [Commented] (SOLR-13137) NPE when /admin/zookeeper/status endpoint hit in standalone mode

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13137:


Commit 5a5a84c7ada4e5c671a66d4dad1d78613c10cefb in lucene-solr's branch 
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5a5a84c ]

SOLR-13137: NPE when /admin/zookeeper/status endpoint hit in standalone mode

(cherry picked from commit b7f99fe55a6fb6e7b38828676750b3512d6899a1)


> NPE when /admin/zookeeper/status endpoint hit in standalone mode
> 
>
> Key: SOLR-13137
> URL: https://issues.apache.org/jira/browse/SOLR-13137
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Attempting to hit [http://localhost:8983/solr/admin/zookeeper/status] when 
> not in cloud mode produces NPE. Should instead return a 400 error with 
> description.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13137) NPE when /admin/zookeeper/status endpoint hit in standalone mode

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13137:


Commit b7f99fe55a6fb6e7b38828676750b3512d6899a1 in lucene-solr's branch 
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b7f99fe ]

SOLR-13137: NPE when /admin/zookeeper/status endpoint hit in standalone mode


> NPE when /admin/zookeeper/status endpoint hit in standalone mode
> 
>
> Key: SOLR-13137
> URL: https://issues.apache.org/jira/browse/SOLR-13137
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 7.7, master (9.0)
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Attempting to hit [http://localhost:8983/solr/admin/zookeeper/status] when 
> not in cloud mode produces NPE. Should instead return a 400 error with 
> description.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8635) Lazy loading Lucene FST offheap using mmap

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8635:


Thanks for testing [~sokolov] – the results make sense: the most terms 
dictionary intensive queries are impacted the most, with {{PKLookup}} being 
heavily impacted since that's just purely exercising the terms dictionary with 
no postings visited.  Fuzzy queries, and then queries matching few hits 
(conjunctions with low/medium freq terms) also spend relatively more time in 
the terms dictionary ...

So net/net it looks like we should not make this the default, but expose it 
somehow as an option for those use cases that don't want to dedicate heap 
memory to storing FSTs?

> Lazy loading Lucene FST offheap using mmap
> --
>
> Key: LUCENE-8635
> URL: https://issues.apache.org/jira/browse/LUCENE-8635
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs
> Environment: I used below setup for es_rally tests:
> single node i3.xlarge running ES 6.5
> es_rally was running on another i3.xlarge instance
>Reporter: Ankit Jain
>Priority: Major
> Attachments: offheap.patch, rally_benchmark.xlsx
>
>
> Currently, FST loads all the terms into heap memory during index open. This 
> causes frequent JVM OOM issues if the term size gets big. A better way of 
> doing this will be to lazily load FST using mmap. That ensures only the 
> required terms get loaded into memory.
>  
> Lucene can expose API for providing list of fields to load terms offheap. I'm 
> planning to take following approach for this:
>  # Add a boolean property fstOffHeap in FieldInfo
>  # Pass list of offheap fields to lucene during index open (ALL can be 
> special keyword for loading ALL fields offheap)
>  # Initialize the fstOffHeap property during lucene index open
>  # FieldReader invokes default FST constructor or OffHeap constructor based 
> on fstOffHeap field
>  
> I created a patch (that loads all fields offheap), did some benchmarks using 
> es_rally and results look good.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[ANNOUNCE] Apache Roadshow Chicago, Call for Presentations

[Trevor Grant]

Hello Devs!


You're receiving this email because you are subscribed to one or more
Apache developer email lists.

I’m writing to let you know about an exciting event coming to the Chicago
area: The Apache Roadshow Chicago.  It will be held May 13th and 14th at
three bars in the Logan Square neighborhood (Revolution Brewing, The
Native, and the Radler).

There will be six tracks:

   -

   Apache in Adtech:  Tell us how Apache works in your advertising stack
   -

   Apache in Fintech: Tell us how Apache works in your finance/insurance
   business
   -

   Apache in Startups: Tell us how you’re using Apache in your startup
   -

   Diversity in Apache: How do we increase and encourage diversity in
   Apache and tech fields overall?
   -

   Made in Chicago: Apache related things made by people in Chicago that
   don’t fall into other buckets
   -

   Project Shark Tank: Do you want more developers or users for your Apache
   project? Come here and pitch it!


This is an exciting chance to learn about how Apache Projects are in use in
production around Chicago, how business users make the decision to use
Apache projects, to learn about exciting new projects that want help from
developers like you, and how/why to increase diversity in tech and IT.

If you have any use cases of Apache products in Adtech, Fintech, or
Startups; if you represent a minority working in tech and have perspectives
to share, if you live in the Chicagoland area and want to highlight some
work you’ve done on an Apache project, or if you want to get other people
excited to come work on your project, then please submit a CFP before the
deadline on February 15th!

Tickets to the Apache Roadshow Chicago are $100; speakers will get a
complimentary ticket.

We’re looking forward to reading your submissions and seeing you there on
May 13-14!

Sincerely,

Trevor Grant

https://www.apachecon.com/chiroadshow19/cfp.html

https://www.apachecon.com/chiroadshow19/register.html

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

[Policeman Jenkins Server]

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

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.request.json.DirectJsonQueryRequestFacetingIntegrationTest

Error Message:
Error starting up MiniSolrCloudCluster

Stack Trace:
java.lang.Exception: Error starting up MiniSolrCloudCluster
at __randomizedtesting.SeedInfo.seed([B62EE87E71D19AAC]:0)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:619)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.(MiniSolrCloudCluster.java:275)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.build(SolrCloudTestCase.java:206)
at 
org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:198)
at 
org.apache.solr.client.solrj.request.json.DirectJsonQueryRequestFacetingIntegrationTest.setupCluster(DirectJsonQueryRequestFacetingIntegrationTest.java:54)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:878)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Suppressed: java.lang.RuntimeException: Jetty/Solr unresponsive
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:493)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner.start(JettySolrRunner.java:451)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.startJettySolrRunner(MiniSolrCloudCluster.java:434)
at 
org.apache.solr.cloud.MiniSolrCloudCluster.lambda$new$0(MiniSolrCloudCluster.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
... 1 more


FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.request.json.DirectJsonQueryRequestFacetingIntegrationTest

Error Message:
10 threads leaked from SUITE scope at 
org.apache.solr.client.solrj.request.json.DirectJsonQueryRequestFacetingIntegrationTest:
 1) Thread[id=2235, name=qtp1080377500-2235, state=TIMED_WAITING, 
group=TGRP-DirectJsonQueryRequestFacetingIntegrationTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.Abstrac

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1235 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23486 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2465 links (2016 relative) to 3228 anchors in 247 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disal

[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk-11) - Build # 34 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/34/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
expected:<100> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<100> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([79BBD47AD60B0B82:F1EFEBA078F7667A]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.cloud.TestCloudRecovery2.test(TestCloudRecovery2.java:74)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:834)




Build Log:
[...truncated 14376 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestCloudRecovery2
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestCloudRecovery2

[jira] [Commented] (LUCENE-8635) Lazy loading Lucene FST offheap using mmap

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8635:
--

This looked interesting to me, too, so I did run the becnhmarks with the 
change, but sadly the results were not great, which is surprising given the 
Rally test results, which looked positive I think? I'm not really sure how to 
interpret Rally output since I'm not familiar wit hthat tool. Does it test 
query performance? Maybe there is a use case for this that is different than 
what is being tested by the benchmarks; here is what I saw after a benchmark 
run. This run is maybe a little unusual since I have some mods to the benchmark 
(running w/8 threads executor service, enabled indexSort, topN=500 b/c of some 
other tests I was running. I can re-run with more "normal" settings, but this 
already looks kind of suspect.
{noformat}
Task  QPS before  StdDev   QPS after  StdDev
Pct diff
PKLookup  163.94  (2.3%)  123.50  (2.0%)  
-24.7% ( -28% -  -20%)
  AndHighLow 5096.79  (1.2%) 4860.87  (1.5%)   
-4.6% (  -7% -   -2%)
  Fuzzy1  711.37  (2.3%)  681.03  (2.4%)   
-4.3% (  -8% -0%)
  Fuzzy2  203.67  (2.6%)  196.77  (2.6%)   
-3.4% (  -8% -1%)
  AndHighMed 3460.06  (2.7%) 3346.84  (3.2%)   
-3.3% (  -8% -2%)
   LowPhrase 3448.68  (2.8%) 3345.41  (2.7%)   
-3.0% (  -8% -2%)
 LowSloppyPhrase 3278.72  (2.9%) 3184.03  (2.8%)   
-2.9% (  -8% -2%)
 LowSpanNear 3123.68  (2.9%) 3040.74  (2.6%)   
-2.7% (  -7% -2%)
 Respell  716.61  (1.7%)  699.22  (1.8%)   
-2.4% (  -5% -1%)
   MedPhrase 2970.83  (3.2%) 2899.18  (3.0%)   
-2.4% (  -8% -3%)
 AndHighHigh 2626.26  (3.7%) 2563.37  (4.0%)   
-2.4% (  -9% -5%)
 MedSloppyPhrase 2642.66  (3.6%) 2582.02  (3.3%)   
-2.3% (  -8% -4%)
 MedSpanNear 2598.01  (3.5%) 2541.03  (3.2%)   
-2.2% (  -8% -4%)
BrowseDateTaxoFacets 3467.39  (2.7%) 3399.62  (3.3%)   
-2.0% (  -7% -4%)
 LowTerm 3896.13  (4.7%) 3824.62  (4.4%)   
-1.8% ( -10% -7%)
HighSpanNear 1511.97  (4.7%) 1484.42  (4.6%)   
-1.8% ( -10% -7%)
   OrHighMed 1406.84  (5.7%) 1382.52  (5.8%)   
-1.7% ( -12% -   10%)
   OrHighLow 1484.58  (6.1%) 1460.06  (6.0%)   
-1.7% ( -12% -   11%)
  HighPhrase 1740.06  (4.5%) 1712.12  (4.4%)   
-1.6% ( -10% -7%)
HighSloppyPhrase 1547.60  (4.7%) 1523.48  (4.6%)   
-1.6% ( -10% -8%)
   BrowseMonthTaxoFacets 9031.31  (2.1%) 8897.26  (2.6%)   
-1.5% (  -6% -3%)
  OrHighHigh .59  (6.3%) 1095.29  (6.5%)   
-1.5% ( -13% -   12%)
   HighTermDayOfYearSort 2197.07  (5.9%) 2166.89  (3.9%)   
-1.4% ( -10% -8%)
 MedTerm 2621.21  (5.3%) 2586.41  (5.0%)   
-1.3% ( -11% -9%)
BrowseDayOfYearTaxoFacets 9011.41  (1.6%) 8907.44  (1.5%)   
-1.2% (  -4% -1%)
   HighTermMonthSort 2449.33  (5.5%) 2421.11  (4.4%)   
-1.2% ( -10% -9%)
HighTerm 1629.92  (6.5%) 1612.72  (6.4%)   
-1.1% ( -13% -   12%)
  IntNRQ  980.43  (9.1%)  973.72  (8.9%)   
-0.7% ( -17% -   19%)
Wildcard 1779.82  (5.7%) 1771.12  (5.5%)   
-0.5% ( -11% -   11%)
 Prefix3 1790.47  (5.9%) 1781.85  (5.8%)   
-0.5% ( -11% -   11%)
BrowseDayOfYearSSDVFacets 2038.63  (3.0%) 2032.32  (2.1%)   
-0.3% (  -5% -4%)
   BrowseMonthSSDVFacets 2295.02  (2.5%) 2303.01  (1.9%)
0.3% (  -4% -4%)
{noformat}

> Lazy loading Lucene FST offheap using mmap
> --
>
> Key: LUCENE-8635
> URL: https://issues.apache.org/jira/browse/LUCENE-8635
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: core/FSTs
> Environment: I used below setup for es_rally tests:
> single node i3.xlarge running ES 6.5
> es_rally was running on another i3.xlarge instance
>Reporter: Ankit Jain
>Priority: Major
> Attachments: offheap.patch, rally_benchmark.xlsx
>
>
> Currently, FST loads all the terms into heap memory during index open. This 
> causes frequent JVM OOM issues if the term size gets big. A better way of 
> doing th

[jira] [Commented] (SOLR-13139) RefGuide: fix date range syntax

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-13139:
-

[~dsmiley], [~nknize], just want to double check that still there's no reason 
to validate delimiter.

> RefGuide: fix date range syntax 
> 
>
> Key: SOLR-13139
> URL: https://issues.apache.org/jira/browse/SOLR-13139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13139.patch
>
>
> https://lucene.apache.org/solr/guide/7_6/working-with-dates.html suggests 
> {{2000-11T13}} as a date range that makes to sense. It's worth to suggest the 
> correct syntax at least, not sure about adding explanation or validating 
> delimiters. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SOLR-13139) RefGuide: fix date range syntax

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-13139 at 1/15/19 1:35 PM:
--

[~dsmiley], [~nknize], just want to double check that still there's no reason 
to [validate 
delimiter|https://github.com/apache/lucene-solr/blob/f083473b891e596def2877b5429fcfa6db175464/lucene/spatial-extras/src/java/org/apache/lucene/spatial/prefix/tree/DateRangePrefixTree.java#L462].


was (Author: mkhludnev):
[~dsmiley], [~nknize], just want to double check that still there's no reason 
to validate delimiter.

> RefGuide: fix date range syntax 
> 
>
> Key: SOLR-13139
> URL: https://issues.apache.org/jira/browse/SOLR-13139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13139.patch
>
>
> https://lucene.apache.org/solr/guide/7_6/working-with-dates.html suggests 
> {{2000-11T13}} as a date range that makes to sense. It's worth to suggest the 
> correct syntax at least, not sure about adding explanation or validating 
> delimiters. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13116) Add Admin UI login support for Kerberos

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-13116:


Oh shoot, I missed your last comment, sorry.  I don't remember if there was a 
refguide link or not.  Maybe there was a link there but my browser had issues 
with it for some reason?  I'll take a look again today with your latest patch 
and let you know.  Hopefully we can get this cleared up.

> Add Admin UI login support for Kerberos
> ---
>
> Key: SOLR-13116
> URL: https://issues.apache.org/jira/browse/SOLR-13116
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 8.0, 7.7
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.0, 7.7
>
> Attachments: SOLR-13116.patch, SOLR-13116.patch, eventual_auth.png, 
> improved_login_page.png
>
>
> Spinoff from SOLR-7896. Kerberos auth plugin should get Admin UI Login 
> support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-13139) RefGuide: fix date range syntax

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-13139:
---

 Summary: RefGuide: fix date range syntax 
 Key: SOLR-13139
 URL: https://issues.apache.org/jira/browse/SOLR-13139
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
 Fix For: 8.0, master (9.0)


https://lucene.apache.org/solr/guide/7_6/working-with-dates.html suggests 
{{2000-11T13}} as a date range that makes to sense. It's worth to suggest the 
correct syntax at least, not sure about adding explanation or validating 
delimiters. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8474) Remove deprecated RAMDirectory

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8474:
-

I've committed the first batch of updates and removals of ram directory to 
master. There are a bunch of tests that still use RAMDirectory, I'll keep 
removing it in small batches to give jenkins a try to catch regressions.

> Remove deprecated RAMDirectory
> --
>
> Key: LUCENE-8474
> URL: https://issues.apache.org/jira/browse/LUCENE-8474
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
> Placeholder for the remainder of the original patch, removing all 
> 8.x-deprecated RAMDirectory classes and replacing their use cases with 
> ByteBuffersDirectory.
> This will have to wait until branch 8.x is officially cut.
> Local branch with RAMDirectory related classes removed (pending 8.x branch, 
> will be updated then).
> https://github.com/dweiss/lucene-solr/tree/LUCENE-8438



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8474) Remove deprecated RAMDirectory

[ASF subversion and git services (JIRA)]

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

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

Commit d4e016afdf41baf0104f79e82d953a4650df42aa in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d4e016a ]

LUCENE-8474: (partial) removal of accesses to RAMFile and RAMDirectory streams. 
Removal of GrowableByteArrayDataOutput.


> Remove deprecated RAMDirectory
> --
>
> Key: LUCENE-8474
> URL: https://issues.apache.org/jira/browse/LUCENE-8474
> Project: Lucene - Core
>  Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
> Placeholder for the remainder of the original patch, removing all 
> 8.x-deprecated RAMDirectory classes and replacing their use cases with 
> ByteBuffersDirectory.
> This will have to wait until branch 8.x is officially cut.
> Local branch with RAMDirectory related classes removed (pending 8.x branch, 
> will be updated then).
> https://github.com/dweiss/lucene-solr/tree/LUCENE-8438



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] janhoy opened a new pull request #534: SOLR-13137: NPE when /admin/zookeeper/statusin standalone mode

[GitBox]

janhoy opened a new pull request #534: SOLR-13137: NPE when 
/admin/zookeeper/statusin standalone mode
URL: https://github.com/apache/lucene-solr/pull/534
 
 
   Simply throw an exception with 400 code for a cleaner experience


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8638) Remove deprecated code in master

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8638:
-

I'll do that. I'm testing the first batch of removals and changes. If it 
passes, I'll commit to master.

> Remove deprecated code in master
> 
>
> Key: LUCENE-8638
> URL: https://issues.apache.org/jira/browse/LUCENE-8638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed. This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8638) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8638:
---

Let's commit it to master separately and let CI work on it.  I'll periodically 
merge master back into this deprecations branch anyway to keep things 
up-to-date.

> Remove deprecated code in master
> 
>
> Key: LUCENE-8638
> URL: https://issues.apache.org/jira/browse/LUCENE-8638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed. This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13138) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-13138:
--

Related work in lucene is at LUCENE-8638

WordDelimiterFilter, SynonymFilter and LegacyBM25Similarity are all referred to 
in Solr, but will be deprecated throughout Solr 8.0 and issue warnings whenever 
they're used, so I think we're safe to just remove all references to them in 
master.

Jaspell is a bit trickier, as it's the default lookup implementation.  The 
JaspellLookupFactory class itself is also not deprecated, so there aren't any 
warnings emitted when it's used currently (JaspellLookup isn't loaded via a 
classloader so the normal deprecation checks don't happen there).  We should 
open a separate issue to deal with this in isolation.

> Remove deprecated code in master
> 
>
> Key: SOLR-13138
> URL: https://issues.apache.org/jira/browse/SOLR-13138
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Alan Woodward
>Priority: Major
>
> There are a number of deprecations in master that should be removed.  This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8638) Remove deprecated code in master

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8638:
-

I'm working on RAMDirectory deprecations. It's a large patch. Do we want to put 
some ordering to it so that people don't get too many collisions? I have it on 
a private branch and could commit to master today.

> Remove deprecated code in master
> 
>
> Key: LUCENE-8638
> URL: https://issues.apache.org/jira/browse/LUCENE-8638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed. This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-13138) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward updated SOLR-13138:
-
Description: 
There are a number of deprecations in master that should be removed.  This 
issue is to keep track of deprecations as a whole, some individual deprecations 
may require their own issues.

 

Work on this issue should be pushed to the `master-deprecations` branch on 
gitbox.

  was:There are a number of deprecations in master that should be removed.  
This issue is to keep track of deprecations as a whole, some individual 
deprecations may require their own issues.


> Remove deprecated code in master
> 
>
> Key: SOLR-13138
> URL: https://issues.apache.org/jira/browse/SOLR-13138
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0)
>Reporter: Alan Woodward
>Priority: Major
>
> There are a number of deprecations in master that should be removed.  This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[ASF subversion and git services (JIRA)]

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

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

Commit f083473b891e596def2877b5429fcfa6db175464 in lucene-solr's branch 
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f083473 ]

LUCENE-8636: follow-up speedups and cleanups.


> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8638) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward updated LUCENE-8638:
--
Description: 
There are a number of deprecations in master that should be removed. This issue 
is to keep track of deprecations as a whole, some individual deprecations may 
require their own issues.

 

Work on this issue should be pushed to the `master-deprecations` branch on 
gitbox

  was:There are a number of deprecations in master that should be removed.  
This issue is to keep track of deprecations as a whole, some individual 
deprecations may require their own issues.


> Remove deprecated code in master
> 
>
> Key: LUCENE-8638
> URL: https://issues.apache.org/jira/browse/LUCENE-8638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed. This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.
>  
> Work on this issue should be pushed to the `master-deprecations` branch on 
> gitbox



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[ASF subversion and git services (JIRA)]

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

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

Commit cbbf703f6aaa94c78af3fccd03893852353e8d05 in lucene-solr's branch 
refs/heads/branch_8x from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cbbf703 ]

LUCENE-8636: follow-up speedups and cleanups.


> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[ASF subversion and git services (JIRA)]

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

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

Commit df5d6de473f2b48b03418df706481bea7fe3bfe0 in lucene-solr's branch 
refs/heads/branch_7x from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=df5d6de ]

LUCENE-8636: follow-up speedups and cleanups.


> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-13138) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward commented on SOLR-13138:
--

The following files in Solr contain deprecated methods or classes:

 

solr/contrib/analytics/src/java/org/apache/solr/analytics/function/field/DateMultiTrieField.java:30:@Deprecated
solr/contrib/analytics/src/java/org/apache/solr/analytics/function/field/DoubleMultiTrieField.java:35:@Deprecated
solr/contrib/analytics/src/java/org/apache/solr/analytics/function/field/IntMultiTrieField.java:37:@Deprecated
solr/contrib/analytics/src/java/org/apache/solr/analytics/function/field/LongMultiTrieField.java:35:@Deprecated
solr/contrib/analytics/src/java/org/apache/solr/analytics/function/field/FloatMultiTrieField.java:36:@Deprecated
solr/core/src/test/org/apache/solr/handler/tagger/EmbeddedSolrNoSerializeTest.java:96:
 // Deprecated in 7.2 but should live on until 8.x
solr/core/src/test/org/apache/solr/TestTrie.java:39:@Deprecated
solr/core/src/test/org/apache/solr/legacy/TestNumericTokenStream.java:29:@Deprecated
solr/core/src/test/org/apache/solr/search/TestTrieFacet.java:28:@Deprecated
solr/core/src/test/org/apache/solr/schema/TrieIntPrefixActsAsRangeQueryFieldType.java:29:@Deprecated
solr/core/src/test/org/apache/solr/schema/WrappedTrieIntField.java:25:@Deprecated
solr/core/src/java/org/apache/solr/handler/StandardRequestHandler.java:21:@Deprecated
solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java:151:
 @Deprecated
solr/core/src/java/org/apache/solr/handler/component/HighlightComponent.java:86:
 @Deprecated // DWS: in 7.0 lets restructure the abstractions/relationships
solr/core/src/java/org/apache/solr/handler/component/HighlightComponent.java:93:
 @Deprecated
solr/core/src/java/org/apache/solr/handler/component/HighlightComponent.java:99:
 @Deprecated
solr/core/src/java/org/apache/solr/handler/SnapShooter.java:66: @Deprecated
solr/core/src/java/org/apache/solr/core/SolrCore.java:729: @Deprecated
solr/core/src/java/org/apache/solr/core/NodeConfig.java:64: @Deprecated
solr/core/src/java/org/apache/solr/core/NodeConfig.java:233: @Deprecated
solr/core/src/java/org/apache/solr/core/NodeConfig.java:358: @Deprecated
solr/core/src/java/org/apache/solr/analysis/LowerCaseTokenizer.java:41:@Deprecated
solr/core/src/java/org/apache/solr/analysis/LowerCaseTokenizerFactory.java:45:@Deprecated
solr/core/src/java/org/apache/solr/response/DocsStreamer.java:120: @Deprecated
solr/core/src/java/org/apache/solr/update/DefaultSolrCoreState.java:89: 
@Deprecated
solr/core/src/java/org/apache/solr/highlight/PostingsSolrHighlighter.java:37:@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:107: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:118: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:123: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:128: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:134: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:139: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:146: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:153: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:160: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:165: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:174: 
@Deprecated
solr/core/src/java/org/apache/solr/internal/csv/CSVStrategy.java:189:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyNumericTokenStream.java:93:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyDoubleField.java:115:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyIntField.java:114:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyFloatField.java:113:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyNumericRangeQuery.java:177:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyNumericUtils.java:58:@Deprecated
solr/core/src/java/org/apache/solr/legacy/PointVectorStrategy.java:85: 
@Deprecated
solr/core/src/java/org/apache/solr/legacy/PointVectorStrategy.java:133: 
@Deprecated
solr/core/src/java/org/apache/solr/legacy/BBoxStrategy.java:88: @Deprecated
solr/core/src/java/org/apache/solr/legacy/BBoxStrategy.java:146: @Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyLongField.java:125:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyNumericType.java:24:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyFieldType.java:26:@Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyFieldType.java:55: @Deprecated
solr/core/src/java/org/apache/solr/legacy/LegacyFieldType.java:71: @Deprecated
solr/core/src/java/org/apache/solr/leg

[jira] [Resolved] (LUCENE-8636) TestPointQueries times out on nightly

[Dawid Weiss (JIRA)]

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

Dawid Weiss resolved LUCENE-8636.
-
   Resolution: Fixed
Fix Version/s: (was: 8.0)
   master (9.0)

Backported to branch_7x and branch_8x as well.

> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: master (9.0)
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-13138) Remove deprecated code in master

[Alan Woodward (JIRA)]

Alan Woodward created SOLR-13138:


 Summary: Remove deprecated code in master
 Key: SOLR-13138
 URL: https://issues.apache.org/jira/browse/SOLR-13138
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: master (9.0)
Reporter: Alan Woodward


There are a number of deprecations in master that should be removed.  This 
issue is to keep track of deprecations as a whole, some individual deprecations 
may require their own issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8638) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8638:
---

Of the deprecations that I haven't removed from the branch yet:
 * WordDelimiterFilter, SynonymFilter, JaspellLookup and LegacyBM25Similarity 
are all referred to from Solr, so we can deal with those in the related Solr 
issue
 * [~dweiss] was planning on dealing with the RAMDirectory deprecations, I 
think?
 * FuzzyQuery changed from taking a float to taking an int a long time ago, but 
queryparsers still allow floats to be passed in and use the deprecated 
conversion methods.  This probably needs its own issue as I think we'll need 
some separate deprecations in the various queryparsers to properly remove this.
 * CharsRef has a deprecated Comparator which is still used in a couple of 
places.  The equivalent BytesRef comparator was removed in LUCENE-7053, so we 
may be able to just get rid of this and use CharsRef.compareTo(), but I want 
more eyes on it to be sure - pinging [~thetaphi‍] and [~rcmuir ] for input on 
this one.
 * The Memory Codec still has a bunch of bridging code between the old 
random-access docvalues implementation and the newer iterative API.  This 
should be simple enough to rewrite, but I vaguely remember some discussion 
about removing it entirely so I want to double check we want to keep this code 
before I spend any time refactoring it.
 * ClasspathResourceLoader has a deprecated constructor using the ThreadContext 
classloader.  This was deprecated in LUCENE-7883 but it's still used in a 
couple of places, so I'd like some input from [~thetaphi‍] as to what it should 
be replaced with
 * FixBrokenOffsetsFilter was added as a stopgap to help cut over token filters 
that potentially produce backwards offsets.  We don't have any filters in core 
or analysis that require this any more, so the question is do we leave it in to 
help the writers of custom token filters, or do we remove it and tell people 
not to write broken code?

> Remove deprecated code in master
> 
>
> Key: LUCENE-8638
> URL: https://issues.apache.org/jira/browse/LUCENE-8638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Major
> Fix For: master (9.0)
>
>
> There are a number of deprecations in master that should be removed.  This 
> issue is to keep track of deprecations as a whole, some individual 
> deprecations may require their own issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8638) Remove deprecated code in master

[Alan Woodward (JIRA)]

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

Alan Woodward commented on LUCENE-8638:
---

The following files contain deprecated methods or classes.  We can strike them 
off as they are fixed and pushed to the `master-deprecations` branch.

lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilter.java:110:@Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/synonym/SynonymFilterFactory.java:82:@Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/util/FilesystemResourceLoader.java:55:
  @Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/util/ClasspathResourceLoader.java:44:
  @Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/FixBrokenOffsetsFilter.java:31:@Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/WordDelimiterFilter.java:95:@Deprecated
lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/WordDelimiterFilterFactory.java:58:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyBinaryDocValues.java:28:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedSetDocValues.java:36:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyNumericDocValuesWrapper.java:30:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedNumericDocValuesWrapper.java:29:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:47:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:76:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:105:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:152:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:207:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:271:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:319:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:383:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:438:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyDocValuesIterables.java:489:
  @Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedSetDocValuesWrapper.java:30:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedNumericDocValues.java:27:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedDocValues.java:34:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyBinaryDocValuesWrapper.java:31:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacySortedDocValuesWrapper.java:30:@Deprecated
lucene/codecs/src/java/org/apache/lucene/codecs/memory/LegacyNumericDocValues.java:26:@Deprecated
-lucene/core/src/test/org/apache/lucene/analysis/TestToken.java:31:@Deprecated-
 - undeprecated and moved to test-framework tests


-lucene/core/src/java/org/apache/lucene/util/SloppyMath.java:75:  @Deprecated-
-lucene/core/src/java/org/apache/lucene/util/IOUtils.java:426:  @Deprecated-
-lucene/core/src/java/org/apache/lucene/util/IOUtils.java:438:  @Deprecated-
lucene/core/src/java/org/apache/lucene/util/CharsRef.java:145:  @Deprecated
lucene/core/src/java/org/apache/lucene/util/CharsRef.java:149:  @Deprecated
lucene/core/src/java/org/apache/lucene/util/CharsRef.java:155:  @Deprecated
-lucene/core/src/java/org/apache/lucene/util/Version.java:39:  @Deprecated-
-lucene/core/src/java/org/apache/lucene/util/Version.java:75:  @Deprecated-
-lucene/core/src/java/org/apache/lucene/util/Constants.java:96:  @Deprecated-
-lucene/core/src/java/org/apache/lucene/util/Constants.java:103:  @Deprecated-
lucene/core/src/java/org/apache/lucene/search/FuzzyQuery.java:217:  @Deprecated
lucene/core/src/java/org/apache/lucene/search/FuzzyQuery.java:229:  @Deprecated
lucene/core/src/java/org/apache/lucene/store/RAMOutputStream.java:37:@Deprecated
lucene/core/src/java/org/apache/lucene/store/RAMInputStream.java:33:@Deprecated
lucene/core/src/java/org/apache/lucene/store/RAMDirectory.java:57:@Deprecated
lucene/core/src/java/org/apache/lucene/store/RAMFile.java:33:@Deprecated
-lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptParser.java:43:
  @Deprecated-
-lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptParser.java:60:
  @Deprecated-
-lucene/expressions/src/java/org/apache/lucene/expressions/js/JavascriptLexer.java:50:
  @Deprecated-
-lucene/expressions/src/java/org/apache/lucene/expressions/js

[jira] [Created] (SOLR-13137) NPE when /admin/zookeeper/status endpoint hit in standalone mode

[JIRA]

Jan Høydahl created SOLR-13137:
--

 Summary: NPE when /admin/zookeeper/status endpoint hit in 
standalone mode
 Key: SOLR-13137
 URL: https://issues.apache.org/jira/browse/SOLR-13137
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 7.5
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 7.7, master (9.0)


Attempting to hit [http://localhost:8983/solr/admin/zookeeper/status] when not 
in cloud mode produces NPE. Should instead return a 400 error with description.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (LUCENE-8638) Remove deprecated code in master

[Alan Woodward (JIRA)]

Alan Woodward created LUCENE-8638:
-

 Summary: Remove deprecated code in master
 Key: LUCENE-8638
 URL: https://issues.apache.org/jira/browse/LUCENE-8638
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
 Fix For: master (9.0)


There are a number of deprecations in master that should be removed.  This 
issue is to keep track of deprecations as a whole, some individual deprecations 
may require their own issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Lucene/Solr 8.0

[Alan Woodward]

I’ve started to work through the various deprecations on the new master branch. 
 There are a lot of them, and I’m going to need some assistance for several of 
them, as it’s not entirely clear what to do.

I’ll open two overarching issues in JIRA, one for lucene and one for Solr, with 
lists of the deprecations that need to be removed in each one.  I’ll create a 
shared branch on gitbox to work against, and push the changes I’ve already done 
there.  We can then create individual JIRA issues for any changes that are more 
involved than just deleting code.

All assistance gratefully received, particularly for the Solr deprecations 
where there’s a lot of code I’m unfamiliar with.

> On 8 Jan 2019, at 09:21, Alan Woodward  > wrote:
> 
> I think the current plan is to do a 7.7 release at the same time as 8.0, to 
> handle any last-minute deprecations etc.  So let’s keep those jobs enabled 
> for now.
> 
>> On 8 Jan 2019, at 09:10, Uwe Schindler > > wrote:
>> 
>> Hi,
>>  
>> I will start and add the branch_8x jobs to Jenkins once I have some time 
>> later today.
>>  
>> The question: How to proceed with branch_7x? Should we stop using it and 
>> release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are we 
>> planning to one more Lucene/Solr 7.7? In the latter case I would keep the 
>> jenkins jobs enabled for a while.
>>  
>> Uwe
>>  
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de 
>> eMail: u...@thetaphi.de 
>>  
>> From: Alan Woodward mailto:romseyg...@gmail.com>> 
>> Sent: Monday, January 7, 2019 11:30 AM
>> To: dev@lucene.apache.org 
>> Subject: Re: Lucene/Solr 8.0
>>  
>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x 
>> from master, and am in the process of updating the master branch to version 
>> 9.  New commits that should be included in the 8.0 release should also be 
>> back-ported to branch_8x from master.
>>  
>> This is not intended as a feature freeze, as I know there are still some 
>> things being worked on for 8.0; however, it should let us clean up master by 
>> removing as much deprecated code as possible, and give us an idea of any 
>> replacement work that needs to be done.
>> 
>> 
>>> On 19 Dec 2018, at 15:13, David Smiley >> > wrote:
>>>  
>>> January.
>>>  
>>> On Wed, Dec 19, 2018 at 2:04 AM S G >> > wrote:
 It would be nice to see Solr 8 in January soon as there is an enhancement 
 on nested-documents we are waiting to get our hands on.
 Any idea when Solr 8 would be out ?
  
 Thx
 SG
  
 On Mon, Dec 17, 2018 at 1:34 PM David Smiley >>> > wrote:
> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) 
> AND priority = Blocker and status = open and fixVersion = "master (8.0)" 
>click here:
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>  
> 
>  
> Thru the end of the month, I intend to work on those issues not yet 
> assigned. 
>  
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand  > wrote:
>> +1
>> 
>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward > > wrote:
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about 
>> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to 
>> > create the branch this week - say Wednesday?  Then we should have some 
>> > time to clean up the master branch and uncover anything that still 
>> > needs to be done on 8.0 before we start the release process next year.
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett > > > wrote:
>> >
>> > I'm a bit delayed, but +1 on the 7.6 and 8.0 plan from me too.
>> >
>> > On Fri, Oct 19, 2018 at 7:18 AM Erick Erickson 
>> > mailto:erickerick...@gmail.com>> wrote:
>> >>
>> >> +1, this gives us all a chance to prioritize getting the blockers out
>> >> of the way in a careful manner.
>> >> On Fri, Oct 19, 2018 at 7:56 AM jim ferenczi > >> > wrote:
>> >> >
>> >> > +1 too. With this new perspective we could create the branch just 
>> >> > after the 7.6 release and target the 8.0 release for January 2019 
>> >> > which gives almost 3 month to finish the blockers ?
>> >> >
>> >> > Le jeu. 18 oc

[jira] [Commented] (SOLR-13116) Add Admin UI login support for Kerberos

[JIRA]

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

Jan Høydahl commented on SOLR-13116:


Uploaded new patch with CSS changes for the refguide link. I still wonder why I 
don't see the link with text "Solr's Kerberos documentation" in your screenshot 
above [~gerlowskija]. I don't have a Kerberos environment but it shows if I 
fake it.

> Add Admin UI login support for Kerberos
> ---
>
> Key: SOLR-13116
> URL: https://issues.apache.org/jira/browse/SOLR-13116
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 8.0, 7.7
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.0, 7.7
>
> Attachments: SOLR-13116.patch, SOLR-13116.patch, eventual_auth.png, 
> improved_login_page.png
>
>
> Spinoff from SOLR-7896. Kerberos auth plugin should get Admin UI Login 
> support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-13136) Queries fail during shard creation [testcase included]

[Bram Van Dam (JIRA)]

Bram Van Dam created SOLR-13136:
---

 Summary: Queries fail during shard creation [testcase included]
 Key: SOLR-13136
 URL: https://issues.apache.org/jira/browse/SOLR-13136
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 7.6
Reporter: Bram Van Dam
 Attachments: TestSearchDuringShardCreation.java

Shard creation takes a certain amount of time. Queries launched between the 
start of shard creation and the full "upness" of the shard will fail: "Error 
from server at foo: no servers hosting shard: bar".

Ideally, shards should not be used in queries before their creation is fully 
completed. A new shard is empty anyway, so its upness couldn't even influence 
the query results in any way.

I'm attaching a testcase which reproduces the problem. Tested on two machines, 
but your mileage may vary assuming this is a concurrency issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-13116) Add Admin UI login support for Kerberos

[JIRA]

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

Jan Høydahl updated SOLR-13116:
---
Attachment: SOLR-13116.patch

> Add Admin UI login support for Kerberos
> ---
>
> Key: SOLR-13116
> URL: https://issues.apache.org/jira/browse/SOLR-13116
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 8.0, 7.7
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.0, 7.7
>
> Attachments: SOLR-13116.patch, SOLR-13116.patch, eventual_auth.png, 
> improved_login_page.png
>
>
> Spinoff from SOLR-7896. Kerberos auth plugin should get Admin UI Login 
> support.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 1212 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/1212/

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

Error Message:
expected:<5> but was:<7>

Stack Trace:
java.lang.AssertionError: expected:<5> but was:<7>
at 
__randomizedtesting.SeedInfo.seed([2ED07635D40FE828:A68449EF7AF385D0]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.solr.cloud.ShardRoutingTest.doTestNumRequests(ShardRoutingTest.java:294)
at 
org.apache.solr.cloud.ShardRoutingTest.test(ShardRoutingTest.java:110)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1063)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1035)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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$

[jira] [Resolved] (SOLR-5169) Provide a way to query for zookeeper quorum state and other cloud-related info

[JIRA]

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

Jan Høydahl resolved SOLR-5169.
---
   Resolution: Duplicate
Fix Version/s: (was: 6.0)
   (was: 4.9)

SOLR-7767 provides a new {{/admin/zookeeper/status}} endpoint for this

> Provide a way to query for zookeeper quorum state and other cloud-related info
> --
>
> Key: SOLR-5169
> URL: https://issues.apache.org/jira/browse/SOLR-5169
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Shawn Heisey
>Priority: Minor
>
> There should be a way, either through an existing admin handler or a new one, 
> to get an up-to-the-moment zookeeper status.  There may be other status 
> information related to SolrCloud that could be included as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-repro - Build # 2682 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2682/

[...truncated 42 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-8.x/5/consoleText

[repro] Revision: 2bcb7f13f0df371bdfc567106847800a22493763

[repro] Repro line:  ant test  -Dtestcase=HttpPartitionTest -Dtests.method=test 
-Dtests.seed=7399E9BB72CF773E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Montreal 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
d970375cd2f2357b6a8da5ac67ef994f8d43
[repro] git fetch
[repro] git checkout 2bcb7f13f0df371bdfc567106847800a22493763

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   HttpPartitionTest
[repro] ant compile-test

[...truncated 3592 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.HttpPartitionTest" -Dtests.showOutput=onerror  
-Dtests.seed=7399E9BB72CF773E -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Montreal 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

[...truncated 1669 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   3/5 failed: org.apache.solr.cloud.HttpPartitionTest
[repro] git checkout d970375cd2f2357b6a8da5ac67ef994f8d43

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Resolved] (SOLR-5207) Admin UI - Zookeeper status graph

[JIRA]

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

Jan Høydahl resolved SOLR-5207.
---
Resolution: Won't Do

> Admin UI - Zookeeper status graph
> -
>
> Key: SOLR-5207
> URL: https://issues.apache.org/jira/browse/SOLR-5207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI, SolrCloud
>Affects Versions: 4.4
>Reporter: Shawn Heisey
>Priority: Minor
> Fix For: 6.0, 4.9
>
> Attachments: zk-graph.png
>
>
> SOLR-5169 puts forth the idea of having an API to show zookeeper status.  
> This issue aims to use that information to draw a graph for zookeeper similar 
> to what we have for SolrCloud nodes.  Attached is an extremely rough image of 
> what I'm shooting for.  It probably needs to have a black outline around one 
> of the nodes to indicate the leader, just like the existing cloud graph does.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8636:
-

I agree, it doesn't seem to make any difference. I'll remove the 
testRandomBinaryBig and commit.

> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 8.0
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8636:
--

[~dweiss] Yes. I'm unsure what bugs testRandomBinaryBig would find that 
testRandomBinaryMedium wouldn't now that the big size is 50k?

> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 8.0
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8636) TestPointQueries times out on nightly

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-8636:
-

Ping, Adrien -- can you confirm you just wanted to remove the 
testRandomBinaryBig, leaving other methods in, did I get you right?

> TestPointQueries times out on nightly
> -
>
> Key: LUCENE-8636
> URL: https://issues.apache.org/jira/browse/LUCENE-8636
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Minor
> Fix For: 8.0
>
> Attachments: LUCENE-8636.patch
>
>
> Nightlies have failed with a suite timeout on:
> {code}
> -Dtestcase=TestPointQueries -Dtests.method=testRandomBinaryBig 
> -Dtests.seed=81DB11C283A04F59 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
> {code}
> This is a result of plain text codec being used and a large volume of 
> repetitions.
> I'll disable plain text codec on that test.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 23524 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/23524/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [MMapDirectory, 
InternalHttpClient, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MMapDirectory  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:95)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:772)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:969)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:876)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1189)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1099)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:395)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:180)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:164)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1610)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) 
 at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:703)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) 
 at org.eclipse.jetty.server.Server.handle(Server.java:502)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)  at 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) 
 at java.base/java.lang.Thread.run(Thread.java:834)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:225)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:267)  at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:418) 
 at org.apache.solr.cloud.RecoveryStrategy.replicate(RecoveryStrategy.java:237) 
 at 
org.apache.solr.cloud.RecoveryStrategy.doReplicateOnlyRecovery(RecoveryStrategy.java:382)
  at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:328)  
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:307)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
  at java.base/java.util.concurrent.FutureTas