[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1260 - Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:54642/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:32801/solr/test_col_shard5_replica1: Server Errorrequest: 
http://127.0.0.1:32801/solr/test_col_shard5_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54642%2Fsolr%2Ftest_col_shard2_replica1%2F=javabin=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:46395/solr/test_col_shard5_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@39ff4f0e

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:54642/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:32801/solr/test_col_shard5_replica1: Server Error



request: 
http://127.0.0.1:32801/solr/test_col_shard5_replica1/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A54642%2Fsolr%2Ftest_col_shard2_replica1%2F=javabin=2
Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:46395/solr/test_col_shard5_replica2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@39ff4f0e
at 
__randomizedtesting.SeedInfo.seed([7331B5E3C1EFF429:4525D7A54BB2CE38]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:281)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

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

[Policeman Jenkins Server]

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

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

Error Message:
Did not find the expected number of groups for field longGSF expected:<4> but 
was:<3>

Stack Trace:
java.lang.AssertionError: Did not find the expected number of groups for field 
longGSF expected:<4> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([72D8085C14FC4F36:AC6FD3D4F1AD0FF3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDocAbsent(DocValuesNotIndexedTest.java:304)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12487 lines...]
   

[jira] [Commented] (SOLR-10255) Large psuedo-stored fields via BinaryDocValuesField

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10255:
-

I think I want to scale back the scope of what I plan to do in the short term 
(for 6.5), while still allowing a BinaryDocValuesField (with compressed 
codec/format) in the future.

I'll file a separate issue for this and try and throw up a patch Monday:  The 
field can remain stored but go _last_ (and the DocumentBuilder can ensure this 
happens).  The last stored value will _not_ be read from disk (well first 16KB 
but whatever) due to LUCENE-6898.  On the {{SolrIndexSearcher.doc(...)}} side, 
the "lazy" fields will get a LargeAlwaysDiskLazyField but one that goes to 
stored value not BinaryDocValues.

> Large psuedo-stored fields via BinaryDocValuesField
> ---
>
> Key: SOLR-10255
> URL: https://issues.apache.org/jira/browse/SOLR-10255
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-10255.patch, SOLR-10255.patch
>
>
> (sub-issue of SOLR-10117)  This is a proposal for a better way for Solr to 
> handle "large" text fields.  Large docs that are in Lucene StoredFields slow 
> requests that don't involve access to such fields.  This is fundamental to 
> the fact that StoredFields are row-stored.  Worse, the Solr documentCache 
> will wind up holding onto massive Strings.  While the latter could be tackled 
> on it's own somehow as it's the most serious issue, nevertheless it seems 
> wrong that such large fields are in row-stored storage to begin with.  After 
> all, relational DBs seemed to have figured this out and put CLOBs/BLOBs in a 
> separate place.  Here, we do similarly by using, Lucene 
> {{BinaryDocValuesField}}.  BDVF isn't well known in the DocValues family as 
> it's not for typical DocValues purposes like sorting/faceting etc.  The 
> default DocValuesFormat doesn't compress these but we could write one that 
> does.



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

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

[jira] [Commented] (LUCENE-7737) Remove spatial-extras dependency on queries

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7737:
--

Yes; bringing back some form of "explain" can be in another ticket.

> Remove spatial-extras dependency on queries
> ---
>
> Key: LUCENE-7737
> URL: https://issues.apache.org/jira/browse/LUCENE-7737
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial-extras
>Reporter: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7737.patch
>
>
> The spatial-extras module uses ValueSources for a number of different 
> purposes, requiring a dependency on the queries module.  I'd like to try 
> using core-only interfaces here instead, allowing us to remove the dependency



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

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

Re: Release 6.5

[Nicholas Knize]

+1

On Sat, Mar 11, 2017 at 7:28 PM Joel Bernstein  wrote:

> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Sat, Mar 11, 2017 at 12:43 PM, jim ferenczi 
> wrote:
>
> Hi,
> We have a lot of great improvements coming in 6.5 so I'd like to volunteer
> for a new release. I can cut the branch around march 17th in order to let
> some time for devs to finish the current issues.
> What do you think?
>
>
>

[jira] [Closed] (LUCENE-4698) Overhaul ShapeFieldCache because its a memory pig

[David Smiley (JIRA)]

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

David Smiley closed LUCENE-4698.

Resolution: Won't Fix

I think LatLonDocValuesField (currently in sandbox) is currently the optimal 
way to go about storing points per document for the purposes of distance 
sorting/boosting.

For general per-document access to a "shape" (possibly a MultiPoint), there's 
the SerializedDVStrategy.

Hence I think ShapeFieldCache stuff should be deprecated/removed.  I'll close 
this as won't-fix.

> Overhaul ShapeFieldCache because its a memory pig
> -
>
> Key: LUCENE-4698
> URL: https://issues.apache.org/jira/browse/LUCENE-4698
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial
>Reporter: David Smiley
> Attachments: solr_spatial_leak1.png
>
>
> The org.apache.lucene.spatial.util.ShapeFieldCache* classes together 
> implement a spatial field cache for points, similar to FieldCache for other 
> fields.  It supports a variable number of points per document, and it's 
> currently only used by the SpatialPrefixTree strategy because that's the only 
> strategy that supports a variable number of points per document.  The other 
> spatial strategies use the FieldCache.  The ShapeFieldCache has problems:
> * It's a memory pig. Each point is stored as a Point object, instead of an 
> array of x & y coordinates. Furthermore, each Point is in an ArrayList that 
> exists for each Document. It's not done any differently when your spatial 
> data isn't multi-valued.
> * The cache is not per-segment, it's per-IndexReader, thereby making it 
> un-friendly to NRT search.
> * The cache entries don't self-expire optimally to free up memory. The cache 
> is simply stored in a WeakHashMap. The big cache 
> entries are only freed when the WeakHashMap is used and the JVM realizes the 
> IndexSearcher instance has been GC'ed.



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

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

[jira] [Closed] (SOLR-5170) Spatial multi-value distance sort via DocValues

[David Smiley (JIRA)]

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

David Smiley closed SOLR-5170.
--
Resolution: Won't Fix

> Spatial multi-value distance sort via DocValues
> ---
>
> Key: SOLR-5170
> URL: https://issues.apache.org/jira/browse/SOLR-5170
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR-5170_spatial_multi-value_sort_via_docvalues.patch, 
> SOLR-5170_spatial_multi-value_sort_via_docvalues.patch, 
> SOLR-5170_spatial_multi-value_sort_via_docvalues.patch.txt
>
>
> The attached patch implements spatial multi-value distance sorting.  In other 
> words, a document can have more than one point per field, and using a 
> provided function query, it will return the distance to the closest point.  
> The data goes into binary DocValues, and as-such it's pretty friendly to 
> realtime search requirements, and it only uses 8 bytes per point.



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

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

[jira] [Resolved] (SOLR-10039) LatLonPointSpatialField

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-10039.
-
   Resolution: Fixed
Fix Version/s: 6.5

> LatLonPointSpatialField
> ---
>
> Key: SOLR-10039
> URL: https://issues.apache.org/jira/browse/SOLR-10039
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 6.5
>
> Attachments: SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch
>
>
> The fastest and most efficient spatial field for point data in Lucene/Solr is 
> {{LatLonPoint}} in Lucene's sandbox module.  I'll include 
> {{LatLonDocValuesField}} with this even though it's a separate class.  
> LatLonPoint is based on the Points API, using a BKD index.  It's multi-valued 
> capable.  LatLonDocValuesField is based on sorted numeric DocValues, and thus 
> is also multi-valued capable (a big deal as the existing Solr ones either 
> aren't or do poorly at it).  Note that this feature is limited to a 
> latitude/longitude spherical world model.  And furthermore the precision is 
> at about a centimeter -- less precise than the other spatial fields but 
> nonetheless plenty good for most applications.  Last but not least, this 
> capability natively supports polygons, albeit those that don't wrap the 
> dateline or a pole.
> I propose a {{LatLonPointSpatialField}} which uses this.  Patch & details 
> forthcoming...
> This development was funded by the Harvard Center for Geographic Analysis as 
> part of the HHypermap project



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

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

[jira] [Commented] (SOLR-10039) LatLonPointSpatialField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10039:


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

SOLR-10039: New LatLonPointSpatialField

(cherry picked from commit 182c20c)


> LatLonPointSpatialField
> ---
>
> Key: SOLR-10039
> URL: https://issues.apache.org/jira/browse/SOLR-10039
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch
>
>
> The fastest and most efficient spatial field for point data in Lucene/Solr is 
> {{LatLonPoint}} in Lucene's sandbox module.  I'll include 
> {{LatLonDocValuesField}} with this even though it's a separate class.  
> LatLonPoint is based on the Points API, using a BKD index.  It's multi-valued 
> capable.  LatLonDocValuesField is based on sorted numeric DocValues, and thus 
> is also multi-valued capable (a big deal as the existing Solr ones either 
> aren't or do poorly at it).  Note that this feature is limited to a 
> latitude/longitude spherical world model.  And furthermore the precision is 
> at about a centimeter -- less precise than the other spatial fields but 
> nonetheless plenty good for most applications.  Last but not least, this 
> capability natively supports polygons, albeit those that don't wrap the 
> dateline or a pole.
> I propose a {{LatLonPointSpatialField}} which uses this.  Patch & details 
> forthcoming...
> This development was funded by the Harvard Center for Geographic Analysis as 
> part of the HHypermap project



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

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

Re: Release 6.5

[Joel Bernstein]

+1

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

On Sat, Mar 11, 2017 at 12:43 PM, jim ferenczi 
wrote:

> Hi,
> We have a lot of great improvements coming in 6.5 so I'd like to volunteer
> for a new release. I can cut the branch around march 17th in order to let
> some time for devs to finish the current issues.
> What do you think?
>

Dealing with issues reported by Findbugs

[Daniel Jeliński]

Hi all,
I started fixing code issues reported by Findbugs; right now it is
reporting 4000+ issues in lucene/solr repository. I could use some guidance:
1) Will one JIRA issue be sufficient to cover all Findbugs-related items,
or should I raise separate items for distinct problems reported by
Findbugs? I raised LUCENE-7739 as a catch-all issue, but I can split it if
that's preferred.
2) My plan is to fix trivial issues first, then work on the harder ones. I
already sent a patch to fix issues related to unnecessary boxing/unboxing
when parsing strings. That patch covers the entire codebase, but in my
opinion it's fairly straightforward. Is that acceptable, or should I split
the patch somehow? Like, lucene/solr, or one file at a time, or one issue
at a time or...

Ideas welcome.
Regards,
Daniel

[jira] [Commented] (SOLR-10039) LatLonPointSpatialField

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10039:


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

SOLR-10039: New LatLonPointSpatialField


> LatLonPointSpatialField
> ---
>
> Key: SOLR-10039
> URL: https://issues.apache.org/jira/browse/SOLR-10039
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch, 
> SOLR_10039_LatLonPointSpatialField.patch
>
>
> The fastest and most efficient spatial field for point data in Lucene/Solr is 
> {{LatLonPoint}} in Lucene's sandbox module.  I'll include 
> {{LatLonDocValuesField}} with this even though it's a separate class.  
> LatLonPoint is based on the Points API, using a BKD index.  It's multi-valued 
> capable.  LatLonDocValuesField is based on sorted numeric DocValues, and thus 
> is also multi-valued capable (a big deal as the existing Solr ones either 
> aren't or do poorly at it).  Note that this feature is limited to a 
> latitude/longitude spherical world model.  And furthermore the precision is 
> at about a centimeter -- less precise than the other spatial fields but 
> nonetheless plenty good for most applications.  Last but not least, this 
> capability natively supports polygons, albeit those that don't wrap the 
> dateline or a pole.
> I propose a {{LatLonPointSpatialField}} which uses this.  Patch & details 
> forthcoming...
> This development was funded by the Harvard Center for Geographic Analysis as 
> part of the HHypermap project



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7738:


I opened LUCENE-7740 to refactor class names and move {{InetAddressRange}} from 
{{sandbox}} to {{misc}}. All other {{*Range}} fields will be refactored to core.

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7738:
--

Actually can you remove the {{e.printStackTrace()}} call in the test and 
rethrow the exception instead? (potentially wrapper in a RuntimeException if it 
makes things easier)

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7738:


+1

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Comment Edited] (LUCENE-7738) Add new InetAddressRangeField

[Adrien Grand (JIRA)]

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

Adrien Grand edited comment on LUCENE-7738 at 3/12/17 1:00 AM:
---

Actually can you remove the {{e.printStackTrace()}} call in the test and 
rethrow the exception instead? (potentially wrapped in a RuntimeException if it 
makes things easier)


was (Author: jpountz):
Actually can you remove the {{e.printStackTrace()}} call in the test and 
rethrow the exception instead? (potentially wrapper in a RuntimeException if it 
makes things easier)

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Created] (LUCENE-7740) Refactor Range Fields and graduate from sandbox

[Nicholas Knize (JIRA)]

Nicholas Knize created LUCENE-7740:
--

 Summary: Refactor Range Fields and graduate from sandbox
 Key: LUCENE-7740
 URL: https://issues.apache.org/jira/browse/LUCENE-7740
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Nicholas Knize


This task refactors Range fields as follows:

1. Remove the {{Field}} suffix to make them more consistent with their 
{{Point}} counterpart. 
2. Graduate {{InetAddressRange}} from {{sandbox}} to {{misc}}
3. Graduate all other {{*Range}} classes (e.g. {{DoubleRange}}) from 
{{sandbox}} to {{core}}



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

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

[jira] [Comment Edited] (SOLR-10265) Overseer can become the bottleneck in very large clusters

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-10265 at 3/12/17 12:57 AM:
-

bq.I haven't debugged why the transaction logs ran into terabytes without 
taking into snapshots but this was my assumption based on the other problems we 
observed

The current design is suboptimal. Just to change one small bit of information, 
we write ~300bytes per replica. for 600 replicas we write ~180kb of data (add 
the fact that 600 nodes have to read that data and parse for every state change 
operation). Every write is appended to the ZK transaction log. We must split 
the state.json to scale any further. 
If we write out the state separately to a format as follows
{code}
{
"replica1": 1
"replica2":0
}
{code}

we can bring down the data size to around 10 bytes per replica. This means 600, 
replicas will have only 6K data per update. 


was (Author: noble.paul):
bq.I haven't debugged why the transaction logs ran into terabytes without 
taking into snapshots but this was my assumption based on the other problems we 
observed

The current design is suboptimal. Just to change one small bit of information, 
we write ~300bytes per replica. for 600 replicas we write ~180kb of data (add 
the fact that 600 nodes have to read that data and parse for every state change 
operation). Every write is appended to the ZK transaction log. We must split 
the state.json to scale any further. 
If we write out the state separately to a format as follows
{code}
{
"replica1": 1
"replica2":0
}
{code}

we can bring down the data size to around 10 bytes per replica. This means 600, 
replicas will have only 6K data per update. 

> Overseer can become the bottleneck in very large clusters
> -
>
> Key: SOLR-10265
> URL: https://issues.apache.org/jira/browse/SOLR-10265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> Let's say we have a large cluster. Some numbers:
> - To ingest the data at the volume we want to I need roughly a 600 shard 
> collection.
> - Index into the collection for 1 hour and then create a new collection 
> - For a 30 days retention window with these numbers we would end up wth  
> ~400k cores in the cluster
> - Just a rolling restart of this cluster can take hours because the overseer 
> queue gets backed up. If a few nodes looses connectivity to ZooKeeper then 
> also we can end up with lots of messages in the Overseer queue
> With some tests here are the two high level problems we have identified:
> 1> How fast can the overseer process operations:
> The rate at which the overseer processes events is too slow at this scale. 
> I ran {{OverseerTest#testPerformance}} which creates 10 collections ( 1 shard 
> 1 replica ) and generates 20k state change events. The test took 119 seconds 
> to run on my machine which means ~170 events a second. Let's say a server can 
> process 5x of my machine so 1k events a second. 
> Total events generated by a 400k replica cluster = 400k * 4 ( state changes 
> till replica become active ) = 1.6M / 1k events a second will be 1600 minutes.
> Second observation was that the rate at which the overseer can process events 
> slows down when the number of items in the queue gets larger
> I ran the same {{OverseerTest#testPerformance}} but changed the number of 
> events generated to 2000 instead. The test took only 5 seconds to run. So it 
> was a lot faster than the test run which generated 20k events
> 2> State changes overwhelming ZK:
> For every state change Solr is writing out a big state.json to zookeeper. 
> This can lead to the zookeeper transaction logs going out of control even 
> with auto purging etc set . 
> I haven't debugged why the transaction logs ran into terabytes without taking 
> into snapshots but this was my assumption based on the other problems we 
> observed



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

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

[jira] [Commented] (SOLR-10265) Overseer can become the bottleneck in very large clusters

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-10265:
---

bq.I haven't debugged why the transaction logs ran into terabytes without 
taking into snapshots but this was my assumption based on the other problems we 
observed

The current design is suboptimal. Just to change one small bit of information, 
we write ~300bytes per replica. for 600 replicas we write ~180kb of data (add 
the fact that 600 nodes have to read that data and parse for every state change 
operation). Every write is appended to the ZK transaction log. We must split 
the state.json to scale any further. 
If we write out the state separately to a format as follows
{code}
{
"replica1": 1
"replica2":0
}
{code}

we can bring down the data size to around 10 bytes per replica. This means 600, 
replicas will have only 6K data per update. 

> Overseer can become the bottleneck in very large clusters
> -
>
> Key: SOLR-10265
> URL: https://issues.apache.org/jira/browse/SOLR-10265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> Let's say we have a large cluster. Some numbers:
> - To ingest the data at the volume we want to I need roughly a 600 shard 
> collection.
> - Index into the collection for 1 hour and then create a new collection 
> - For a 30 days retention window with these numbers we would end up wth  
> ~400k cores in the cluster
> - Just a rolling restart of this cluster can take hours because the overseer 
> queue gets backed up. If a few nodes looses connectivity to ZooKeeper then 
> also we can end up with lots of messages in the Overseer queue
> With some tests here are the two high level problems we have identified:
> 1> How fast can the overseer process operations:
> The rate at which the overseer processes events is too slow at this scale. 
> I ran {{OverseerTest#testPerformance}} which creates 10 collections ( 1 shard 
> 1 replica ) and generates 20k state change events. The test took 119 seconds 
> to run on my machine which means ~170 events a second. Let's say a server can 
> process 5x of my machine so 1k events a second. 
> Total events generated by a 400k replica cluster = 400k * 4 ( state changes 
> till replica become active ) = 1.6M / 1k events a second will be 1600 minutes.
> Second observation was that the rate at which the overseer can process events 
> slows down when the number of items in the queue gets larger
> I ran the same {{OverseerTest#testPerformance}} but changed the number of 
> events generated to 2000 instead. The test took only 5 seconds to run. So it 
> was a lot faster than the test run which generated 20k events
> 2> State changes overwhelming ZK:
> For every state change Solr is writing out a big state.json to zookeeper. 
> This can lead to the zookeeper transaction logs going out of control even 
> with auto purging etc set . 
> I haven't debugged why the transaction logs ran into terabytes without taking 
> into snapshots but this was my assumption based on the other problems we 
> observed



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7738: Add new InetAddressRangeField for indexing and querying 
InetAddress ranges.


> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7738:
--

+1 to the patch
+1 to removing the "Field" suffix from range fields
+1 on graduating those fields from sandbox, I was initially thinking core would 
be a good fit (LUCENE-7314) but misc works for me too

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7449:


Thanks [~steve_rowe] and sorry for the delay. I've pushed a fix for this.

> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7738: Add new InetAddressRangeField for indexing and querying 
InetAddress ranges.


> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7449: fix CROSSES queries so they don't match all docs when internal 
nodes are equal


> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

[jira] [Commented] (LUCENE-7449) Add CROSSES query support to RangeField

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7449: fix CROSSES queries so they don't match all docs when internal 
nodes are equal


> Add CROSSES query support to RangeField
> ---
>
> Key: LUCENE-7449
> URL: https://issues.apache.org/jira/browse/LUCENE-7449
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7449.patch, LUCENE-7449.patch, LUCENE-7449.patch
>
>
> {{RangeField}} currently supports {{INTERSECTS}}, {{WITHIN}}, and 
> {{CONTAINS}} query behavior. This feature adds support for an explicit 
> {{CROSSES}} query. Unlike {{INTERSECT}} and {{OVERLAP}} queries the 
> {{CROSSES}} query finds any indexed ranges whose interior (within range) 
> intersect the interior AND exterior (outside range) of the query range.



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19147/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) 
Thread[id=16836, name=jetty-launcher-3337-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 
   1) Thread[id=16836, name=jetty-launcher-3337-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
at __randomizedtesting.SeedInfo.seed([4CAD03D50B014516]:0)




Build Log:
[...truncated 11893 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.TestSolrCloudWithSecureImpersonation_4CAD03D50B014516-001/init-core-data-001
   [junit4]   2> 1022152 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[4CAD03D50B014516]-worker) [   
 ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 1022152 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[4CAD03D50B014516]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Using TrieFields
   [junit4]   2> 1022154 INFO  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[4CAD03D50B014516]-worker) [   
 ] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1022175 WARN  
(SUITE-TestSolrCloudWithSecureImpersonation-seed#[4CAD03D50B014516]-worker) [   
 ] 

[jira] [Updated] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-6736:
---
Attachment: newzkconf.zip
SOLR-6736.patch

Initial patch based on my proposal above.

# Adds configsets with trusted=false (TODO: this should be based on whether 
authz is enabled for /admin)
# Fail update requests using XSLT
# TODO: Fail to load StatelessScriptUpdateProcessor if configset is untrusted
# TODO: Fail to load script transformer in DIH if configset is untrusted

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Ishan Chattopadhyaya
> Attachments: newzkconf.zip, newzkconf.zip, SOLR-6736-newapi.patch, 
> SOLR-6736-newapi.patch, SOLR-6736-newapi.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> test_private.pem, test_pub.der, zkconfighandler.zip, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:57726/solr/awhollynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 510HTTP ERROR: 510 Problem 
accessing /solr/awhollynewcollection_0/select. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:6},code=510}
 http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:57726/solr/awhollynewcollection_0: Expected 
mime type application/octet-stream but got text/html. 


Error 510 


HTTP ERROR: 510
Problem accessing /solr/awhollynewcollection_0/select. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:6},code=510}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([4C1017DBEE435B66:465636FE87074F3]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:578)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:435)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:387)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1361)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1112)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:522)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7738:
--

RE naming; some consistency is good.  So if the non-range variant doesn't have 
'Field' then don't put it on the range variant.  But vice-versa is also true -- 
consistency being most important.  I care little wether both should have (or 
not have) a "Field" suffix.  There seems to be a lot of variation across 
Lucene, unfortunately.

bq. I can open a separate issue to "Graduate Range Fields from sandbox" that 
will refactor the range field class names and move them to the appropriate 
module?

+1

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

[jira] [Updated] (LUCENE-7739) Issues reported by FindBugs

[Daniel Jelinski (JIRA)]

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

Daniel Jelinski updated LUCENE-7739:

Attachment: LUCENE-7739.patch

Patch to address "boxing/unboxing to parse a primitive"; removes unneeded heap 
allocations when parsing strings. Should be fairly easy to review, as the new 
version is functionally equivalent.

> Issues reported by FindBugs
> ---
>
> Key: LUCENE-7739
> URL: https://issues.apache.org/jira/browse/LUCENE-7739
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Daniel Jelinski
>Priority: Minor
> Attachments: LUCENE-7739.patch
>
>
> As suggested in LUCENE-3973, we could add findbugs as a precommit hook if we 
> get the number of issues reported down to zero. 



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

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

[jira] [Created] (LUCENE-7739) Issues reported by FindBugs

[Daniel Jelinski (JIRA)]

Daniel Jelinski created LUCENE-7739:
---

 Summary: Issues reported by FindBugs
 Key: LUCENE-7739
 URL: https://issues.apache.org/jira/browse/LUCENE-7739
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Daniel Jelinski
Priority: Minor


As suggested in LUCENE-3973, we could add findbugs as a precommit hook if we 
get the number of issues reported down to zero. 



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 782 - Unstable

[Apache Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: Expected 2 of 3 replicas to be active but only found 
1; 
[core_node3:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:44929/cr","node_name":"127.0.0.1:44929_cr","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf//clusterstate.json/30)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica2",
  "base_url":"http://127.0.0.1:48152/cr;,
  "node_name":"127.0.0.1:48152_cr",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:34155/cr;,
  "core":"c8n_1x3_lf_shard1_replica3",
  "node_name":"127.0.0.1:34155_cr"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:44929/cr;,
  "node_name":"127.0.0.1:44929_cr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([FD9C1F5EECD7D98B:75C82084422BB473]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:168)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 

[jira] [Commented] (SOLR-8045) Deploy V2 API at /v2 instead of /solr/v2

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8045:
--

Same (looking) failure on master 
[https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/723/]:

{noformat}
  [smoker] Test Solr...
[...]
  [smoker] Solr techproducts example launched successfully. Direct your Web 
browser to http://localhost:8983/solr to visit the Solr Admin UI
  [smoker]   test utf8...
  [smoker]   run query...
  [smoker] FAILED: response is:
  [smoker] 
{"responseHeader":{"status":0,"QTime":2},"initFailures":{},"status":{"techproducts":{"name":"techproducts","instanceDir":"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr/techproducts","dataDir":"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr/techproducts/data/","config":"solrconfig.xml","schema":"managed-schema","startTime":"2017-03-11T18:52:09.695Z","uptime":1178,"index":{"numDocs":32,"maxDoc":32,"deletedDocs":0,"indexHeapUsageBytes":-1,"version":6,"segmentCount":1,"current":true,"hasDeletions":false,"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr/techproducts/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@45968d2f; 
maxCacheMB=48.0 
maxMergeSizeMB=4.0)","segmentsFile":"segments_2","segmentsFileSizeInBytes":169,"userData":{"commitTimeMSec":"1489258330575"},"lastModified":"2017-03-11T18:52:10.575Z","sizeInBytes":28881,"size":"28.2
 KB"
  [smoker] 
  [smoker]   stop server using: bin/solr stop -p 8983
  [smoker] Sending stop command to Solr running on port 8983 ... waiting up to 
180 seconds to allow Jetty process 5742 to stop gracefully.
  [smoker] Traceback (most recent call last):
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1478, in 
  [smoker] main()
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1422, in main
  [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 1466, in smokeTest
  [smoker] unpackAndVerify(java, 'solr', tmpDir, artifact, gitRevision, 
version, testArgs, baseURL)
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
  [smoker] verifyUnpacked(java, project, artifact, unpackPath, gitRevision, 
version, testArgs, tmpDir, baseURL)
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 760, in verifyUnpacked
  [smoker] testSolrExample(java8UnpackPath, java.java8_home, False)
  [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/dev-tools/scripts/smokeTestRelease.py",
 line 861, in testSolrExample
  [smoker] raise RuntimeError('query api v2 on solr example instance 
failed')
  [smoker] RuntimeError: query api v2 on solr example instance failed
  [smoker]  [|]   [/]   [-]   [\]  
{noformat}

> Deploy V2 API at /v2 instead of /solr/v2
> 
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Cao Manh Dat
> Fix For: 6.5
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 39749 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (34.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 30.6 MB in 0.03 sec (1106.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 65.0 MB in 0.06 sec (1093.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 75.4 MB in 0.07 sec (1101.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6210 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6210 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 214 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (282.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 40.4 MB in 0.16 sec (257.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 141.8 MB in 0.13 sec (1065.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 143.1 MB in 0.13 sec (1103.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=5742). Happy searching!
   

[jira] [Commented] (SOLR-8045) Deploy V2 API at /v2 instead of /solr/v2

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8045:
--

ASF Jenkins has a smoke tester failure after this issue's branch_6x commit 
[https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.x/283/] - when I run 
{{ant nightly-smoke}} without a seed on current branch_6x, I see the same 
failure:

{noformat}
Checking out Revision 89baa4fd43477c3b0be59e81299b651d70b3c128 
(refs/remotes/origin/branch_6x)
[...]
   [smoker] Test Solr...
[...]
   [smoker] Solr techproducts example launched successfully. Direct your Web 
browser to http://localhost:8983/solr to visit the Solr Admin UI
   [smoker]   test utf8...
   [smoker]   run query...
   [smoker] FAILED: response is:
   [smoker] 
{"responseHeader":{"status":0,"QTime":2},"initFailures":{},"status":{"techproducts":{"name":"techproducts","instanceDir":"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/example/techproducts/solr/techproducts","dataDir":"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/example/techproducts/solr/techproducts/data/","config":"solrconfig.xml","schema":"managed-schema","startTime":"2017-03-11T14:53:39.348Z","uptime":1183,"index":{"numDocs":32,"maxDoc":32,"deletedDocs":0,"indexHeapUsageBytes":-1,"version":6,"segmentCount":1,"current":true,"hasDeletions":false,"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/example/techproducts/solr/techproducts/data/index
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@2a09960c; 
maxCacheMB=48.0 
maxMergeSizeMB=4.0)","segmentsFile":"segments_2","segmentsFileSizeInBytes":165,"userData":{"commitTimeMSec":"1489244020126"},"lastModified":"2017-03-11T14:53:40.126Z","sizeInBytes":28411,"size":"27.75
 KB"
   [smoker] 
   [smoker]   stop server using: bin/solr stop -p 8983
   [smoker] Sending stop command to Solr running on port 8983 ... waiting up to 
180 seconds to allow Jetty process 15932 to stop gracefully.
   [smoker] Traceback (most recent call last):
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1476, in 
   [smoker] main()
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1420, in main
   [smoker] smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, 
c.is_signed, ' '.join(c.test_args))
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 1464, in smokeTest
   [smoker] unpackAndVerify(java, 'solr', tmpDir, artifact, gitRevision, 
version, testArgs, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 622, in unpackAndVerify
   [smoker] verifyUnpacked(java, project, artifact, unpackPath, 
gitRevision, version, testArgs, tmpDir, baseURL)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 760, in verifyUnpacked
   [smoker] testSolrExample(java8UnpackPath, java.java8_home, False)
   [smoker]   File 
"/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/dev-tools/scripts/smokeTestRelease.py",
 line 861, in testSolrExample
   [smoker] raise RuntimeError('query api v2 on solr example instance 
failed')
   [smoker] RuntimeError: query api v2 on solr example instance failed
   [smoker]  [|]   [/]   [-]   [\]  
{noformat}

When I run {{ant nightly-smoke}} on branch_6x at {{8c5ea32}}, the commit just 
before this issue was committed to branch_6x, I don't see this failure.

> Deploy V2 API at /v2 instead of /solr/v2
> 
>
> Key: SOLR-8045
> URL: https://issues.apache.org/jira/browse/SOLR-8045
> Project: Solr
>  Issue Type: Wish
>Reporter: Noble Paul
>Assignee: Cao Manh Dat
> Fix For: 6.5
>
> Attachments: SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, 
> SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch, SOLR-8045.patch
>
>
> This does not mean that the path to access Solr will be changed. All paths 
> will remain as is and would behave exactly the same



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

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

[jira] [Commented] (LUCENE-7738) Add new InetAddressRangeField

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7738:


Thanks [~dsmiley]!

I have no problem putting both {{InetAddressRangeField}} and 
{{InetAddressPoint}} in the misc module. Seems like a sound justification to me.

I also think I'm going to refactor all range field classes to remove {{Field}} 
from the class name. It seems more natural (to me) to have {{Point}} and 
{{Range}} counterparts (e.g., {{DoublePoint}}, {{DoubleRange}}, 
{{InetAddressPoint}}, {{InetAddressRange}})? (and less typing is always a 
bonus) What do you think? (or does anyone care? - I know naming is often an 
exercise in bikeshedding)

If no one objects I can open a separate issue to "Graduate Range Fields from 
sandbox" that will refactor the range field class names and move them to the 
appropriate module? What does everyone think?

> Add new InetAddressRangeField
> -
>
> Key: LUCENE-7738
> URL: https://issues.apache.org/jira/browse/LUCENE-7738
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Nicholas Knize
> Attachments: LUCENE-7738.patch, LUCENE-7738.patch
>
>
> This issue adda a new {{InetAddressRangeField}} for indexing and querying 
> InetAddress ranges.



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

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

Release 6.5

[jim ferenczi]

Hi,
We have a lot of great improvements coming in 6.5 so I'd like to volunteer
for a new release. I can cut the branch around march 17th in order to let
some time for devs to finish the current issues.
What do you think?

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10079:
---

This branch_6x failure from ASF Jenkins 
[https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/305/] reproduces 
for me, but only if I remove the {{-Dtests.method=testUpdatingDocValues}} 
cmdline param:

{noformat}
Checking out Revision 89baa4fd43477c3b0be59e81299b651d70b3c128 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestInPlaceUpdatesStandalone -Dtests.method=testUpdatingDocValues 
-Dtests.seed=48FDDE490CDE142B -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=tr -Dtests.timezone=Etc/GMT-11 -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 0.03s J2 | 
TestInPlaceUpdatesStandalone.testUpdatingDocValues <<<
   [junit4]> Throwable #1: java.lang.AssertionError
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([48FDDE490CDE142B:9E8D03EE67836A7D]:0)
   [junit4]>at 
org.apache.solr.update.TestInPlaceUpdatesStandalone.testUpdatingDocValues(TestInPlaceUpdatesStandalone.java:179)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
[...]
   [junit4]   2> NOTE: test params are: codec=SimpleText, 
sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=tr, 
timezone=Etc/GMT-11
   [junit4]   2> NOTE: Linux 3.13.0-85-generic amd64/Oracle Corporation 
1.8.0_121 (64-bit)/cpus=4,threads=1,free=175027640,total=535298048
{noformat}

> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> 

[jira] [Commented] (SOLR-10079) TestInPlaceUpdates(Distrib|Standalone) failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10079:
---

Non-reproducing failure for {{TestStressInplaceUpdates}}, from my Jenkins:

{noformat}
Checking out Revision 89baa4fd43477c3b0be59e81299b651d70b3c128 
(refs/remotes/origin/branch_6x)
[...]
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestStressInPlaceUpdates -Dtests.method=stressTest 
-Dtests.seed=81C361EBE4263C1B -Dtests.slow=true -Dtests.locale=es-DO 
-Dtests.timezone=Africa/Maputo -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   65.9s J8  | TestStressInPlaceUpdates.stressTest <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=195, name=WRITER4, state=RUNNABLE, 
group=TGRP-TestStressInPlaceUpdates]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([81C361EBE4263C1B:EAA5BE46DAF3E8E1]:0)
   [junit4]> Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:43738/collection1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([81C361EBE4263C1B]:0)
   [junit4]>at 
org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:320)
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
IOException occured when talking to server at: 
https://127.0.0.1:43738/collection1
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:624)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:524)
   [junit4]>at 
org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:544)
   [junit4]>at 
org.apache.solr.cloud.TestStressInPlaceUpdates$1.run(TestStressInPlaceUpdates.java:183)
   [junit4]> Caused by: org.apache.http.NoHttpResponseException: 
127.0.0.1:43738 failed to respond
   [junit4]>at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
   [junit4]>at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
   [junit4]>at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
   [junit4]>at 
org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
   [junit4]>at 
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
   [junit4]>at 
org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
   [junit4]>at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
   [junit4]>at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
   [junit4]>at 
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
   [junit4]>at 
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
   [junit4]>at 
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
   [junit4]>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
   [junit4]>at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:515)
   [junit4]>... 6 more
[...]
   [junit4]   2> NOTE: test params are: codec=CheapBastard, 
sim=RandomSimilarity(queryNorm=true,coord=crazy): {}, locale=es-DO, 
timezone=Africa/Maputo
   [junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
1.8.0_77 (64-bit)/cpus=16,threads=1,free=346846424,total=428343296
{noformat}

> TestInPlaceUpdates(Distrib|Standalone) failures
> ---
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch, stdout

[jira] [Commented] (SOLR-10265) Overseer can become the bottleneck in very large clusters

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-10265:
-

Side comment, need its own issue if we decide to pursue.

Only about 6 entries can fit in the overseer queue before retrieving the 
queue exceeds the default jute.maxbuffer and ZOOKEEPER-1162 becomes a problem.

Some calculation revealed that if we use a nested node structure where we 
create a "directory" node in the overseer queue and then put events inside 
those directories, limiting the number of directories to 32768 and the number 
of entries in each directory to 32768, we can handle a billion entries without 
exceeding the 1MB maxbuffer.  Figuring out how to handle rollover in the 
directory names would be necessary.

Of course it would likely take weeks or months to actually process a billion 
entries, but it does need to be able to handle more than 6 without breaking 
down.


> Overseer can become the bottleneck in very large clusters
> -
>
> Key: SOLR-10265
> URL: https://issues.apache.org/jira/browse/SOLR-10265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> Let's say we have a large cluster. Some numbers:
> - To ingest the data at the volume we want to I need roughly a 600 shard 
> collection.
> - Index into the collection for 1 hour and then create a new collection 
> - For a 30 days retention window with these numbers we would end up wth  
> ~400k cores in the cluster
> - Just a rolling restart of this cluster can take hours because the overseer 
> queue gets backed up. If a few nodes looses connectivity to ZooKeeper then 
> also we can end up with lots of messages in the Overseer queue
> With some tests here are the two high level problems we have identified:
> 1> How fast can the overseer process operations:
> The rate at which the overseer processes events is too slow at this scale. 
> I ran {{OverseerTest#testPerformance}} which creates 10 collections ( 1 shard 
> 1 replica ) and generates 20k state change events. The test took 119 seconds 
> to run on my machine which means ~170 events a second. Let's say a server can 
> process 5x of my machine so 1k events a second. 
> Total events generated by a 400k replica cluster = 400k * 4 ( state changes 
> till replica become active ) = 1.6M / 1k events a second will be 1600 minutes.
> Second observation was that the rate at which the overseer can process events 
> slows down when the number of items in the queue gets larger
> I ran the same {{OverseerTest#testPerformance}} but changed the number of 
> events generated to 2000 instead. The test took only 5 seconds to run. So it 
> was a lot faster than the test run which generated 20k events
> 2> State changes overwhelming ZK:
> For every state change Solr is writing out a big state.json to zookeeper. 
> This can lead to the zookeeper transaction logs going out of control even 
> with auto purging etc set . 
> I haven't debugged why the transaction logs ran into terabytes without taking 
> into snapshots but this was my assumption based on the other problems we 
> observed



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

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

[jira] [Commented] (SOLR-10265) Overseer can become the bottleneck in very large clusters

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10265:
---

Trying to think a little OOB here:

> Is there any way to split one or more collections across multiple ZK 
> ensembles? My instant response is yuck, that'd be major surgery and perhaps 
> practically impossible but I thought I'd toss it out there.

> Can we reduce the number of messages the Overseer has to process, especially 
> when nodes are coming up?

> Does all that stuff have to be written to the tlog so often (I'd guess yes, 
> just askin').

> Does all this stuff actually have to flow through ZK?

> Could we "somehow" roll up/batch changes? I.e. go through the queue, assemble 
> all of the changes that affect a particular znode and write _one_ state 
> change (or do we already)? 

And I don't know that code at all so much of this may be nonsense or already 
done. Think of it as brainstorming

> Overseer can become the bottleneck in very large clusters
> -
>
> Key: SOLR-10265
> URL: https://issues.apache.org/jira/browse/SOLR-10265
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> Let's say we have a large cluster. Some numbers:
> - To ingest the data at the volume we want to I need roughly a 600 shard 
> collection.
> - Index into the collection for 1 hour and then create a new collection 
> - For a 30 days retention window with these numbers we would end up wth  
> ~400k cores in the cluster
> - Just a rolling restart of this cluster can take hours because the overseer 
> queue gets backed up. If a few nodes looses connectivity to ZooKeeper then 
> also we can end up with lots of messages in the Overseer queue
> With some tests here are the two high level problems we have identified:
> 1> How fast can the overseer process operations:
> The rate at which the overseer processes events is too slow at this scale. 
> I ran {{OverseerTest#testPerformance}} which creates 10 collections ( 1 shard 
> 1 replica ) and generates 20k state change events. The test took 119 seconds 
> to run on my machine which means ~170 events a second. Let's say a server can 
> process 5x of my machine so 1k events a second. 
> Total events generated by a 400k replica cluster = 400k * 4 ( state changes 
> till replica become active ) = 1.6M / 1k events a second will be 1600 minutes.
> Second observation was that the rate at which the overseer can process events 
> slows down when the number of items in the queue gets larger
> I ran the same {{OverseerTest#testPerformance}} but changed the number of 
> events generated to 2000 instead. The test took only 5 seconds to run. So it 
> was a lot faster than the test run which generated 20k events
> 2> State changes overwhelming ZK:
> For every state change Solr is writing out a big state.json to zookeeper. 
> This can lead to the zookeeper transaction logs going out of control even 
> with auto purging etc set . 
> I haven't debugged why the transaction logs ran into terabytes without taking 
> into snapshots but this was my assumption based on the other problems we 
> observed



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

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

[jira] [Resolved] (LUCENE-6187) explore symmetic docvalues pull API

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6187.

   Resolution: Fixed
Fix Version/s: master (7.0)

This was done with the switch to an iterator API for doc values for 7.0.

> explore symmetic docvalues pull API
> ---
>
> Key: LUCENE-6187
> URL: https://issues.apache.org/jira/browse/LUCENE-6187
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: master (7.0)
>
>
> Currently the DocValuesConsumer and NormsConsumer have a streaming pull API 
> based on Iterable.
> {code}
> addNumericField(FieldInfo field, Iterable values)
> ...
> addSortedSetField(FieldInfo field, Iterable values, 
> Iterable docToOrdCount, Iterable ords)
> {code}
> I think this was a good initial approach, but it has a few downsides:
> * for more complex structures (sorted/sortedset/sortednumeric) the codec must 
> awkwardly handle multiple streams and sometimes inefficiently do extra passes.
> * thousands of lines of XXXDocValues <-> Iterable bridge handling in merge 
> code (when MultiDocValues already knows how to merge multiple subs)
> * missing values represented as null is awkward, complicated and a little 
> trappy on the consumer.
> I think we should explore changing it to look more like postings:
> {code}
> addNumericField(FieldInfo field, NumericDocValues values, Bits docsWithField)
> addSortedSetField(FieldInfo field, SortedSetDocValues values, Bits 
> docsWithField)
> {code}
> I don't think it would be hard on the implementation: e.g. when I look at 
> IndexWriter it seems like these would even be simpler code than the current 
> iterators (e.g. for numerics its already got a NumericDocValues and a Bits 
> docsWithField, the current iterable stuff is just "extra" bridge code like 
> merging).
> My main concern is if it makes things easier on the codec impls or not. I 
> think we have to try it out to see. We could test it out on trunk with just 
> NormsConsumer.



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

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

[jira] [Resolved] (LUCENE-5966) How to migrate from numeric fields to auto-prefix terms

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-5966.

Resolution: Won't Fix

We removed auto prefix terms ...

> How to migrate from numeric fields to auto-prefix terms
> ---
>
> Key: LUCENE-5966
> URL: https://issues.apache.org/jira/browse/LUCENE-5966
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>
> In LUCENE-5879 we are adding auto-prefix terms to the default terms dict, 
> which is generalized from numeric fields and offers faster performance while 
> using less indexing space and about the same indexing time.
> But there are many users out there with indices already created containing 
> numeric fields ... so ideally we have some simple way for such users to 
> switch over to auto-prefix  terms.
> Robert has a good plan (copied from LUCENE-5879):
> Here are some thoughts.
> # keep current trie "Encoding" for terms, it just uses precision step=Inf and 
> lets the term dictionary do it automatically.
> # create a filteratomicreader, that for a previous trie encoded field, 
> removes "fake" terms on merge.
> Users could continue to use NumericRangeQuery just with the infinite 
> precision step, and it will always work, just execute slower for old segments 
> as it doesnt take advantage of the trie terms that are not yet merged away.
> One issue to making it really nice, is that lucene doesnt know for sure that 
> a field is numeric, so it cannot be "full-auto". Apps would have to use their 
> schema or whatever to wrap with this reader in their merge policy.
> Maybe we could provide some sugar for this, such as a wrapping merge policy 
> that takes a list of field names that are numeric, or sugar to pass this to 
> IWC in IndexUpgrader to force it, and so on.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 39758 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 260 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.02 sec (13.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.5.0-src.tgz...
   [smoker] 30.7 MB in 0.03 sec (1134.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.tgz...
   [smoker] 65.2 MB in 0.06 sec (1089.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.5.0.zip...
   [smoker] 75.6 MB in 0.16 sec (472.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6240 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6240 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.5.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (112.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.5.0-src.tgz...
   [smoker] 40.5 MB in 0.32 sec (125.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.5.0.tgz...
   [smoker] 141.8 MB in 1.45 sec (98.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.5.0.zip...
   [smoker] 143.0 MB in 1.45 sec (98.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.5.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.5.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.x/lucene/build/smokeTestRelease/tmp/unpack/solr-6.5.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=15932). Happy searching!
   [smoker] 
   [smoker] 
   

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+159) - Build # 19143 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19143/
Java: 32bit/jdk-9-ea+159 -server -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 6 object(s) that were not released!!! [TransactionLog, 
MDCAwareThreadPoolExecutor, SolrIndexSearcher, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:188)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:443)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1102)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:529)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:514)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:328)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:247)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:202)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:987)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1200)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:749)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:336)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:97)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:186)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:142)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:313) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:258)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:128)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:278) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:258)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:180)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:193)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:107)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:54)  
at 

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 305 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.update.TestInPlaceUpdatesStandalone.testUpdatingDocValues

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([48FDDE490CDE142B:9E8D03EE67836A7D]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at 
org.apache.solr.update.TestInPlaceUpdatesStandalone.testUpdatingDocValues(TestInPlaceUpdatesStandalone.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 13640 lines...]
   [junit4] Suite: org.apache.solr.update.TestInPlaceUpdatesStandalone
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (LUCENE-5069) Can/should we store NumericField's precisionStep in the index?

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-5069.

Resolution: Won't Fix

We moved to dimensional points for storing inverted numeric values in Lucene.

> Can/should we store NumericField's precisionStep in the index?
> --
>
> Key: LUCENE-5069
> URL: https://issues.apache.org/jira/browse/LUCENE-5069
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>
> I was just helping a user (buzzkills) on IRC on why NumericRangeQuery was 
> failing to hit the expected docs ... and it was because s/he had indexed with 
> precStep=4 but searched with precStep=1.
> Then we wondered if it'd be possible to somehow catch this, e.g. we could 
> maybe store precStep in FieldInfo, and then fail at search time if you use a 
> "non-matching" precStep?
> I think you can index fine and then search on a multiple of that?  E.g., I 
> can index with precStep=2 but search with precStep=8?  But indexing with 
> precStep=4 and searching precStep=1 won't work ...



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

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

[jira] [Resolved] (LUCENE-5712) Remove Similarity.queryNorm

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-5712.

Resolution: Fixed

Duplicate of LUCENE-7368, yay.

> Remove Similarity.queryNorm
> ---
>
> Key: LUCENE-5712
> URL: https://issues.apache.org/jira/browse/LUCENE-5712
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Michael McCandless
> Fix For: 6.0, 4.9
>
>
> This method is a no-op for ranking within one query, causes confusion for 
> users making their own Similarity impls, and isn't necessary for / makes it 
> harder to switch the default to more modern scoring models like BM25.



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

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

[JENKINS] Lucene-Solr-6.4-Windows (64bit/jdk1.8.0_121) - Build # 29 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Windows/29/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup

Error Message:
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\solr\build\solr-core\test\J1\temp\solr.handler.TestReplicationHandlerBackup_813B5CE7C883F069-001\solr-instance-002\collection1\data\snapshot.dylyb\_0.fnm

Stack Trace:
java.nio.file.NoSuchFileException: 
C:\Users\jenkins\workspace\Lucene-Solr-6.4-Windows\solr\build\solr-core\test\J1\temp\solr.handler.TestReplicationHandlerBackup_813B5CE7C883F069-001\solr-instance-002\collection1\data\snapshot.dylyb\_0.fnm
at 
__randomizedtesting.SeedInfo.seed([813B5CE7C883F069:C0B07C82EF3D0326]:0)
at 
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at 
sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at 
org.apache.lucene.store.SimpleFSDirectory.openInput(SimpleFSDirectory.java:77)
at 
org.apache.lucene.store.Directory.openChecksumInput(Directory.java:137)
at 
org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:104)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:62)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:54)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:690)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:77)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
at 
org.apache.solr.handler.TestReplicationHandlerBackup.verify(TestReplicationHandlerBackup.java:150)
at 
org.apache.solr.handler.TestReplicationHandlerBackup.doTestBackup(TestReplicationHandlerBackup.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
 

[JENKINS-EA] Lucene-Solr-6.4-Linux (32bit/jdk-9-ea+159) - Build # 173 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/173/
Java: 32bit/jdk-9-ea+159 -server -XX:+UseSerialGC

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

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([B2A7338B66C07427:4BEAA0245AB539AD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280)
at 
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:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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 

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew

Error Message:
expected:<200> but was:<403>

Stack Trace:
java.lang.AssertionError: expected:<200> but was:<403>
at 
__randomizedtesting.SeedInfo.seed([35B4AB552D695904:22F5F4B15A584A0]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.renewDelegationToken(TestSolrCloudWithDelegationTokens.java:130)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.verifyDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:316)
at 
org.apache.solr.cloud.TestSolrCloudWithDelegationTokens.testDelegationTokenRenew(TestSolrCloudWithDelegationTokens.java:333)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, 
InternalHttpClient] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:388)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:269) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:399) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$2(ReplicationHandler.java:1145)
  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:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:480)  
at org.apache.solr.core.SolrCore.(SolrCore.java:907)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:829)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:949)  at 
org.apache.solr.core.CoreContainer.lambda$load$3(CoreContainer.java:582)  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:347)
  at 
org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:388)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:269) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:399) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$2(ReplicationHandler.java:1145)
  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:1142) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
 at java.lang.Thread.run(Thread.java:745)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1003)  at 
org.apache.solr.core.SolrCore.reload(SolrCore.java:638)  at 
org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1138)  at 
org.apache.solr.handler.IndexFetcher.lambda$reloadCore$0(IndexFetcher.java:796) 
 at java.lang.Thread.run(Thread.java:745)  
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:289)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:298)
  at