[jira] [Created] (LUCENE-7192) Geo3d polygon creation should not get upset about co-linear points

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7192:
---

 Summary: Geo3d polygon creation should not get upset about 
co-linear points
 Key: LUCENE-7192
 URL: https://issues.apache.org/jira/browse/LUCENE-7192
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial3d
Affects Versions: master
Reporter: Karl Wright
Assignee: Karl Wright


Currently, if you create a polygon with co-linear adjacent points, the polygon 
fails to create (you get IllegalArgumentException).  We should make this more 
robust.



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

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

Re: Lucene IndexDeletionPolicy + snapshots

[Shalin Shekhar Mangar]

Look at PersistentSnapshotDeletionPolicy which does almost exactly what you
want.

On Fri, Apr 8, 2016 at 10:44 AM, Hrishikesh Gadre 
wrote:

> This in the context of providing backup/restore operation for SolrCloud
> (on HDFS). The copy operation is unavoidable in case Solr is using local
> filesystem and backup is being written on a shared file-system. But in case
> of HDFS, I am wondering if we can avoid the copy operation by using
> IndexDeletionPolicy.
>
> On Thu, Apr 7, 2016 at 10:10 PM, Hrishikesh Gadre 
> wrote:
>
>> Hello,
>>
>> IndexDeletionPolicy in Lucene enables users to configure when the stale
>> Index commits should be deleted. Currently Solr uses this support to
>> "reserve" a commit point while the relevant segment files are being copied
>> as part of the backup operation. This reservation information is stored
>> in-memory only (and hence doesn't preserve across server restart).
>>
>> I wonder if we can use this to implement point-in-time and zero-copy
>> snapshots ?Essentially the idea would be store the IndexCommit related
>> information in a persistent fashion so that this "reservation" can be
>> preserved across server restart. Hence once the snapshot is created, the
>> relevant commit_point would be reserved permanently (unless the snapshot is
>> deleted). The advantage of this would be that we can eliminate the copy
>> operation.
>>
>> Any thoughts?
>>
>> Thanks
>> Hrishikesh
>>
>>
>>
>>
>


-- 
Regards,
Shalin Shekhar Mangar.

[jira] [Updated] (LUCENE-7191) Hook up Geo3DPoint query factory methods in TestGeo3DPoint

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7191:

Attachment: LUCENE-7191.diff

[~mikemccand]: Any objection if I commit this?  Or would you want to beast it a 
while first?


> Hook up Geo3DPoint query factory methods in TestGeo3DPoint
> --
>
> Key: LUCENE-7191
> URL: https://issues.apache.org/jira/browse/LUCENE-7191
> Project: Lucene - Core
>  Issue Type: Test
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Attachments: LUCENE-7191.diff
>
>
> Tests of the Geo3DPoint query factory API methods are needed, and probably 
> the best way is to hook these up in the TestGeo3DPoint random stress test.



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

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

[jira] [Created] (LUCENE-7191) Hook up Geo3DPoint query factory methods in TestGeo3DPoint

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7191:
---

 Summary: Hook up Geo3DPoint query factory methods in TestGeo3DPoint
 Key: LUCENE-7191
 URL: https://issues.apache.org/jira/browse/LUCENE-7191
 Project: Lucene - Core
  Issue Type: Test
  Components: modules/spatial3d
Affects Versions: master
Reporter: Karl Wright
Assignee: Karl Wright


Tests of the Geo3DPoint query factory API methods are needed, and probably the 
best way is to hook these up in the TestGeo3DPoint random stress test.




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

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1060 - Still Failing

[Apache Jenkins Server]

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

5 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.LeaderElectionIntegrationTest

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [InternalHttpClient]
at __randomizedtesting.SeedInfo.seed([21E80097680A9D0C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:255)
at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([21E80097680A9D0C:4AA7A0EA11054036]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:134)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy(ZkStateReaderTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

Re: Lucene IndexDeletionPolicy + snapshots

[Hrishikesh Gadre]

This in the context of providing backup/restore operation for SolrCloud (on
HDFS). The copy operation is unavoidable in case Solr is using local
filesystem and backup is being written on a shared file-system. But in case
of HDFS, I am wondering if we can avoid the copy operation by using
IndexDeletionPolicy.

On Thu, Apr 7, 2016 at 10:10 PM, Hrishikesh Gadre 
wrote:

> Hello,
>
> IndexDeletionPolicy in Lucene enables users to configure when the stale
> Index commits should be deleted. Currently Solr uses this support to
> "reserve" a commit point while the relevant segment files are being copied
> as part of the backup operation. This reservation information is stored
> in-memory only (and hence doesn't preserve across server restart).
>
> I wonder if we can use this to implement point-in-time and zero-copy
> snapshots ?Essentially the idea would be store the IndexCommit related
> information in a persistent fashion so that this "reservation" can be
> preserved across server restart. Hence once the snapshot is created, the
> relevant commit_point would be reserved permanently (unless the snapshot is
> deleted). The advantage of this would be that we can eliminate the copy
> operation.
>
> Any thoughts?
>
> Thanks
> Hrishikesh
>
>
>
>

Lucene IndexDeletionPolicy + snapshots

[Hrishikesh Gadre]

Hello,

IndexDeletionPolicy in Lucene enables users to configure when the stale
Index commits should be deleted. Currently Solr uses this support to
"reserve" a commit point while the relevant segment files are being copied
as part of the backup operation. This reservation information is stored
in-memory only (and hence doesn't preserve across server restart).

I wonder if we can use this to implement point-in-time and zero-copy
snapshots ?Essentially the idea would be store the IndexCommit related
information in a persistent fashion so that this "reservation" can be
preserved across server restart. Hence once the snapshot is created, the
relevant commit_point would be reserved permanently (unless the snapshot is
deleted). The advantage of this would be that we can eliminate the copy
operation.

Any thoughts?

Thanks
Hrishikesh

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+112-patched) - Build # 16454 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16454/
Java: 32bit/jdk-9-ea+112-patched -client -XX:+UseConcMarkSweepGC 
-XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString

Error Message:
expected:<...at=0.772208221547936[6], lon=0.135607475210...> but 
was:<...at=0.772208221547936[7], lon=0.135607475210...>

Stack Trace:
org.junit.ComparisonFailure: expected:<...at=0.772208221547936[6], 
lon=0.135607475210...> but was:<...at=0.772208221547936[7], 
lon=0.135607475210...>
at 
__randomizedtesting.SeedInfo.seed([53C51195ABB393AB:7A53CE6389410B27]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString(TestGeo3DPoint.java:735)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)




Build Log:
[...truncated 9003 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.00s J0 | TestGeo3DPoint.testRandomBig
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 

[jira] [Commented] (SOLR-8954) RealTimeGet NPE

[wjw465150 (JIRA)]

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

wjw465150 commented on SOLR-8954:
-

when create collection,router.name is "implicit",use RealTimeGet must add 
parameter "shards"!

> RealTimeGet NPE
> ---
>
> Key: SOLR-8954
> URL: https://issues.apache.org/jira/browse/SOLR-8954
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
> Environment: centos x64 6.3 jdk 1.7
>Reporter: wjw465150
>
> when i use http://solr_ip:8983/solr/collection1/get?id=123456, solr throw 
> nullpoint exception:
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.createSubRequests(RealTimeGetComponent.java:407)
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.distributedProcess(RealTimeGetComponent.java:364)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:322)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:670)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> but,when when i use 
> http://solr_ip:8983/solr/collection1/get?id=123456=shard1, solr will 
> return the correct result!



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

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

[jira] [Commented] (SOLR-8954) RealTimeGet NPE

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-8954:
--

You have to explain this in significantly more detail to have any hope of 
finding an underlying cause.

What do you mean "dynamic shard"? Exactly how did you create the core?

> RealTimeGet NPE
> ---
>
> Key: SOLR-8954
> URL: https://issues.apache.org/jira/browse/SOLR-8954
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
> Environment: centos x64 6.3 jdk 1.7
>Reporter: wjw465150
>
> when i use http://solr_ip:8983/solr/collection1/get?id=123456, solr throw 
> nullpoint exception:
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.createSubRequests(RealTimeGetComponent.java:407)
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.distributedProcess(RealTimeGetComponent.java:364)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:322)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:670)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> but,when when i use 
> http://solr_ip:8983/solr/collection1/get?id=123456=shard1, solr will 
> return the correct result!



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

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

[jira] [Commented] (SOLR-8954) RealTimeGet NPE

[wjw465150 (JIRA)]

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

wjw465150 commented on SOLR-8954:
-

I found the reason is:when create core use dynamic shard!

> RealTimeGet NPE
> ---
>
> Key: SOLR-8954
> URL: https://issues.apache.org/jira/browse/SOLR-8954
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.5
> Environment: centos x64 6.3 jdk 1.7
>Reporter: wjw465150
>
> when i use http://solr_ip:8983/solr/collection1/get?id=123456, solr throw 
> nullpoint exception:
> null:java.lang.NullPointerException
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.createSubRequests(RealTimeGetComponent.java:407)
> at 
> org.apache.solr.handler.component.RealTimeGetComponent.distributedProcess(RealTimeGetComponent.java:364)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:322)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2082)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:670)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:458)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:225)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:183)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> but,when when i use 
> http://solr_ip:8983/solr/collection1/get?id=123456=shard1, solr will 
> return the correct result!



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

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

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

[Apache Jenkins Server]

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

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_node2:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:45438","node_name":"127.0.0.1:45438_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   "state":"down",   
"base_url":"http://127.0.0.1:46406;,   
"core":"c8n_1x3_lf_shard1_replica2",   "node_name":"127.0.0.1:46406_"}, 
"core_node2":{   "core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:45438;,   "node_name":"127.0.0.1:45438_",  
 "state":"active",   "leader":"true"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:57325;,   "node_name":"127.0.0.1:57325_",  
 "state":"down",   "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_node2:{"core":"c8n_1x3_lf_shard1_replica1","base_url":"http://127.0.0.1:45438","node_name":"127.0.0.1:45438_","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "state":"down",
  "base_url":"http://127.0.0.1:46406;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:46406_"},
"core_node2":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:45438;,
  "node_name":"127.0.0.1:45438_",
  "state":"active",
  "leader":"true"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:57325;,
  "node_name":"127.0.0.1:57325_",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([74F742A70CA964E8:FCA37D7DA2550910]: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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)

[jira] [Commented] (LUCENE-7190) Geo3d public classes have some unnecessary protected member methods and classes; this should be cleaned up

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7190:
-

nice!

> Geo3d public classes have some unnecessary protected member methods and 
> classes; this should be cleaned up
> --
>
> Key: LUCENE-7190
> URL: https://issues.apache.org/jira/browse/LUCENE-7190
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
>
> The classes that were allowed to remain public in geo3d need to be reviewed 
> for protected fields, classes, and methods.  Some of these can be made 
> private without reducing the flexibility of the package much.



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

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

[jira] [Commented] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-8097:


Thanks Jason and Shawn. I'll commit this to 6x tomorrow.

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



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

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

[jira] [Updated] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-8097:
---
Fix Version/s: 6.1
   master

> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



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

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

[jira] [Commented] (SOLR-8097) Implement a builder pattern for constructing a Solrj client

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8097: Implement builder pattern design for constructing SolrJ clients and 
deprecate direct construction of clients


> Implement a builder pattern for constructing a Solrj client
> ---
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: master
>Reporter: Hrishikesh Gadre
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, 
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors 
> as follows,
> public CloudSolrClient(String zkHost) 
> public CloudSolrClient(String zkHost, HttpClient httpClient) 
> public CloudSolrClient(Collection zkHosts, String chroot)
> public CloudSolrClient(Collection zkHosts, String chroot, HttpClient 
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient 
> httpClient)
> It is kind of problematic while introducing an additional parameters (since 
> we need to introduce additional constructors). Instead it will be helpful to 
> provide SolrClient Builder which can provide either default values or support 
> overriding specific parameter. 



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[ASF subversion and git services (JIRA)]

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

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

Commit dd9d5d06d2d5aef1f9367ff6459b325a44d0de4c in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dd9d5d0 ]

LUCENE-7168: use center value on decode


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[ASF subversion and git services (JIRA)]

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

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

Commit 1848477bd83ca3f45ffda0d15a2eee901adb90b6 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1848477 ]

LUCENE-7168: use center value on decode


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

+1 for the new patch.


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7189:


bq. I can add my geojson string creator from luceneutil. 

+1, I think we need all the geo debugging help we can get!

> Make BaseGeoPointTestCase more debuggable
> -
>
> Key: LUCENE-7189
> URL: https://issues.apache.org/jira/browse/LUCENE-7189
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This class tests queries (boxes, circles, polygons) against indexed documents 
> and fails if the query is wrong.
> Unfortunately it can be hard to debug (depending which test method failed, if 
> it was NIGHTLY, etc).
> It is making issues challenging/slower to debug for me on LUCENE-7185. In 
> general i have found debugging geo related issues is difficult, we should 
> invest more time to make this easier.
> I think we want to display:
> 1) original item (e.g. Rectangle, radius, polygon)
> 2) query.toString() <-- can be different in important ways!
> 3) how many total documents were wrong
> 4) info on up to N (say 5) wrong documents:
>   ID (not lucene docid) of doc.
>   Lat/Lon location(s) of doc
>   any relevant metric such as distance from origin
> 5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
> documents, the query itself, any additional stuff like bounding box that 
> might be useful plotted too.
> I think the wrong documents we should try for one-line (rather than many) and 
> we don't need to print stuff like deleted=false since these queries don't do 
> anything sneaky here around that.



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

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

[jira] [Resolved] (LUCENE-7190) Geo3d public classes have some unnecessary protected member methods and classes; this should be cleaned up

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7190.
-
   Resolution: Fixed
Fix Version/s: 6.x
   master

> Geo3d public classes have some unnecessary protected member methods and 
> classes; this should be cleaned up
> --
>
> Key: LUCENE-7190
> URL: https://issues.apache.org/jira/browse/LUCENE-7190
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
>
> The classes that were allowed to remain public in geo3d need to be reviewed 
> for protected fields, classes, and methods.  Some of these can be made 
> private without reducing the flexibility of the package much.



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

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

[jira] [Updated] (LUCENE-7168) Remove geo3d test leniency

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7168:
---
Attachment: LUCENE-7168.patch

Here's a new patch, simplifying the encode/decode, based on a good
idea that [~daddywri] suggested (over lunch!) to change decode to decode
to the center value.  This gets us our stability without having to
pick special double values, and it means we can use the full integer
space again, but I did need to add the same if that {{LatLonPoint}}
has about not being able to encode precisely the max value.


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7190) Geo3d public classes have some unnecessary protected member methods and classes; this should be cleaned up

[ASF subversion and git services (JIRA)]

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

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

Commit 48f1d56c7e39d718ddda5a2e9b5e4e45423222c5 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48f1d56 ]

LUCENE-7190: Make some methods private in public classes, and make a very few 
constants public.


> Geo3d public classes have some unnecessary protected member methods and 
> classes; this should be cleaned up
> --
>
> Key: LUCENE-7190
> URL: https://issues.apache.org/jira/browse/LUCENE-7190
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> The classes that were allowed to remain public in geo3d need to be reviewed 
> for protected fields, classes, and methods.  Some of these can be made 
> private without reducing the flexibility of the package much.



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

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

[jira] [Commented] (LUCENE-7190) Geo3d public classes have some unnecessary protected member methods and classes; this should be cleaned up

[ASF subversion and git services (JIRA)]

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

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

Commit 5e4777346a7a31c2c11af54707f03612e19c4c94 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5e47773 ]

LUCENE-7190: Make some methods private in public classes, and make a very few 
constants public.


> Geo3d public classes have some unnecessary protected member methods and 
> classes; this should be cleaned up
> --
>
> Key: LUCENE-7190
> URL: https://issues.apache.org/jira/browse/LUCENE-7190
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
>
> The classes that were allowed to remain public in geo3d need to be reviewed 
> for protected fields, classes, and methods.  Some of these can be made 
> private without reducing the flexibility of the package much.



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

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

[jira] [Created] (LUCENE-7190) Geo3d public classes have some unnecessary protected member methods and classes; this should be cleaned up

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7190:
---

 Summary: Geo3d public classes have some unnecessary protected 
member methods and classes; this should be cleaned up
 Key: LUCENE-7190
 URL: https://issues.apache.org/jira/browse/LUCENE-7190
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial3d
Affects Versions: master
Reporter: Karl Wright
Assignee: Karl Wright


The classes that were allowed to remain public in geo3d need to be reviewed for 
protected fields, classes, and methods.  Some of these can be made private 
without reducing the flexibility of the package much.




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

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

[jira] [Commented] (LUCENE-7173) Add Polygon... variant of newPolygonQuery() to Geo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit ecbf1a4d83d4816241679c37f196c1f5b3d1b88c in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ecbf1a4 ]

LUCENE-7173: Iterate at least 100 times each for polygon construction when 
testing.


> Add Polygon... variant of newPolygonQuery() to Geo3DPoint
> -
>
> Key: LUCENE-7173
> URL: https://issues.apache.org/jira/browse/LUCENE-7173
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7173.patch
>
>
> We need to add the Polygon... variant of newPolygonQuery() to Geo3DPoint to 
> support holes and also bring the Geo3DPoint API into agreement with the 2D 
> API's.



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

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

[jira] [Commented] (LUCENE-7173) Add Polygon... variant of newPolygonQuery() to Geo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit a06a6dfaad3e5591fd1c57f792ea830351e91b84 in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a06a6df ]

LUCENE-7173: Iterate at least 100 times each for polygon construction when 
testing.


> Add Polygon... variant of newPolygonQuery() to Geo3DPoint
> -
>
> Key: LUCENE-7173
> URL: https://issues.apache.org/jira/browse/LUCENE-7173
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7173.patch
>
>
> We need to add the Polygon... variant of newPolygonQuery() to Geo3DPoint to 
> support holes and also bring the Geo3DPoint API into agreement with the 2D 
> API's.



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

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

[jira] [Commented] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[ASF subversion and git services (JIRA)]

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

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

Commit 347b9f0d7f81ab881ac28b34b5f4477a82811321 in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=347b9f0 ]

LUCENE-7189: make it easier to write WebGL earth HTML for debugging geo failures


> Make BaseGeoPointTestCase more debuggable
> -
>
> Key: LUCENE-7189
> URL: https://issues.apache.org/jira/browse/LUCENE-7189
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This class tests queries (boxes, circles, polygons) against indexed documents 
> and fails if the query is wrong.
> Unfortunately it can be hard to debug (depending which test method failed, if 
> it was NIGHTLY, etc).
> It is making issues challenging/slower to debug for me on LUCENE-7185. In 
> general i have found debugging geo related issues is difficult, we should 
> invest more time to make this easier.
> I think we want to display:
> 1) original item (e.g. Rectangle, radius, polygon)
> 2) query.toString() <-- can be different in important ways!
> 3) how many total documents were wrong
> 4) info on up to N (say 5) wrong documents:
>   ID (not lucene docid) of doc.
>   Lat/Lon location(s) of doc
>   any relevant metric such as distance from origin
> 5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
> documents, the query itself, any additional stuff like bounding box that 
> might be useful plotted too.
> I think the wrong documents we should try for one-line (rather than many) and 
> we don't need to print stuff like deleted=false since these queries don't do 
> anything sneaky here around that.



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

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

[jira] [Commented] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[ASF subversion and git services (JIRA)]

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

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

Commit 07d99765f56265997aaa74d5e0eaa4401b667151 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=07d9976 ]

LUCENE-7189: make it easier to write WebGL earth HTML for debugging geo failures


> Make BaseGeoPointTestCase more debuggable
> -
>
> Key: LUCENE-7189
> URL: https://issues.apache.org/jira/browse/LUCENE-7189
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This class tests queries (boxes, circles, polygons) against indexed documents 
> and fails if the query is wrong.
> Unfortunately it can be hard to debug (depending which test method failed, if 
> it was NIGHTLY, etc).
> It is making issues challenging/slower to debug for me on LUCENE-7185. In 
> general i have found debugging geo related issues is difficult, we should 
> invest more time to make this easier.
> I think we want to display:
> 1) original item (e.g. Rectangle, radius, polygon)
> 2) query.toString() <-- can be different in important ways!
> 3) how many total documents were wrong
> 4) info on up to N (say 5) wrong documents:
>   ID (not lucene docid) of doc.
>   Lat/Lon location(s) of doc
>   any relevant metric such as distance from origin
> 5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
> documents, the query itself, any additional stuff like bounding box that 
> might be useful plotted too.
> I think the wrong documents we should try for one-line (rather than many) and 
> we don't need to print stuff like deleted=false since these queries don't do 
> anything sneaky here around that.



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

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

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-8933:
-

bq. I would just use the CloseShieldInputStream. The additional APIs provided 
by ServletInputStream or ServletOutputStream are not used by Solr. Actually we 
put some of them to the forbidden-apis list (because of stupidity and 
ISO-8859-1 defaults from earlier days). See 
lucene/tools/forbiddenApis/servlet-api.txt
Doesn't matter that we don't use the extra APIs, the type signature of 
{{ServletRequest::getInputStream}} still demands a {{ServletInputStream}} so 
that is what we have to return when wrapping the request object. The other 
option is to go even deeper down the hierarchy, cast to 
{{org.eclipse.jetty.server.Request}} and then manipulate the input stream 
directly from there, but that feels much more invasive and brittle.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Comment Edited] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8933 at 4/7/16 9:32 PM:
-

bq. Which IOUtils? I didn't see this in o.a.lucene.util or o.a.solr.common.util.

Sorry I was thinking of commons-io instead of IOUtils. Was a typo!

bq. CloseShieldServletInputStream inspired by the Apache commons-io 
CloseShieldInputStream which was almost good enough to use. 

I would just use the CloseShieldInputStream. The additional APIs provided by 
ServletInputStream or ServletOutputStream are not used by Solr. Actually we put 
some of them to the forbidden-apis list (because of stupidity and ISO-8859-1 
defaults from earlier days). See lucene/tools/forbiddenApis/servlet-api.txt

I looked at this. There is no penalty by the wrapping - so you can also do it 
by default (with CloseShieldInputStream, no specialization). This is just 
optimized away... A method that just delegates to another methods is *always* 
removed by the VM.


was (Author: thetaphi):
bq. Which IOUtils? I didn't see this in o.a.lucene.util or o.a.solr.common.util.

Sorry I meat commons-io instead of IOUtils. Was a typo!

bq. CloseShieldServletInputStream inspired by the Apache commons-io 
CloseShieldInputStream which was almost good enough to use. 

I would just use the CloseShieldInputStream. The additional APIs provided by 
ServletInputStream or ServletOutputStream are not used by Solr. Actually we put 
some of them to the forbidden-apis list (because of stupidity and ISO-8859-1 
defaults from earlier days). See lucene/tools/forbiddenApis/servlet-api.txt

I looked at this. There is no penalty by the wrapping - so you can also do it 
by default (with CloseShieldInputStream, no specialization). This is just 
optimized away... A method that just delegates to another methods is *always* 
removed by the VM.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8933:
-

bq. Which IOUtils? I didn't see this in o.a.lucene.util or o.a.solr.common.util.

Sorry I meat commons-io instead of IOUtils. Was a typo!

bq. CloseShieldServletInputStream inspired by the Apache commons-io 
CloseShieldInputStream which was almost good enough to use. 

I would just use the CloseShieldInputStream. The additional APIs provided by 
ServletInputStream or ServletOutputStream are not used by Solr. Actually we put 
some of them to the forbidden-apis list (because of stupidity and ISO-8859-1 
defaults from earlier days). See lucene/tools/forbiddenApis/servlet-api.txt

I looked at this. There is no penalty by the wrapping - so you can also do it 
by default (with CloseShieldInputStream, no specialization). This is just 
optimized away... A method that just delegates to another methods is *always* 
removed by the VM.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Updated] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8933:

Attachment: SOLR-8933.patch

bq. Ioutils has a wrapper for this!
Which IOUtils? I didn't see this in {{o.a.lucene.util}} or 
{{o.a.solr.common.util}}. I'm currently adding a new class 
{{CloseShieldServletInputStream}} inspired by the Apache commons-io 
{{CloseShieldInputStream}} which was almost good enough to use. There's maybe 
some clever way to handle this via generics, reflection, and proxies, but I 
think that suffers in terms of maintainability.

bq. Why not just enable it during "test mode"
Done. Originally I thought there was value in fine grained control to enable 
the warning, but at this point I'm not convinced that is true.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch, 
> SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Assigned] (SOLR-8922) DocSetCollector can allocate massive garbage on large indexes

[Yonik Seeley (JIRA)]

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

Yonik Seeley reassigned SOLR-8922:
--

Assignee: Yonik Seeley

> DocSetCollector can allocate massive garbage on large indexes
> -
>
> Key: SOLR-8922
> URL: https://issues.apache.org/jira/browse/SOLR-8922
> Project: Solr
>  Issue Type: Improvement
>Reporter: Jeff Wartes
>Assignee: Yonik Seeley
> Attachments: SOLR-8922.patch
>
>
> After reaching a point of diminishing returns tuning the GC collector, I 
> decided to take a look at where the garbage was coming from. To my surprise, 
> it turned out that for my index and query set, almost 60% of the garbage was 
> coming from this single line:
> https://github.com/apache/lucene-solr/blob/94c04237cce44cac1e40e1b8b6ee6a6addc001a5/solr/core/src/java/org/apache/solr/search/DocSetCollector.java#L49
> This is due to the simple fact that I have 86M documents in my shards. 
> Allocating a scratch array big enough to track a result set 1/64th of my 
> index (1.3M) is also almost certainly excessive, considering my 99.9th 
> percentile hit count is less than 56k.



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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+112-patched) - Build # 364 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/364/
Java: 32bit/jdk-9-ea+112-patched -server -XX:+UseG1GC -XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString

Error Message:
expected:<...at=0.772208221547936[6], lon=0.135607475210...> but 
was:<...at=0.772208221547936[7], lon=0.135607475210...>

Stack Trace:
org.junit.ComparisonFailure: expected:<...at=0.772208221547936[6], 
lon=0.135607475210...> but was:<...at=0.772208221547936[7], 
lon=0.135607475210...>
at 
__randomizedtesting.SeedInfo.seed([B6A3A1EBBF5B099:22FCE5E899072815]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString(TestGeo3DPoint.java:735)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)




Build Log:
[...truncated 8992 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.01s J1 | TestGeo3DPoint.testEncodeIsStableFromIntSide
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 

[jira] [Commented] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7189:


I can add my geojson string creator from luceneutil. Its great for simple 
geometry debugging on a 2D map. You just cut and paste the geojson string into 
http://geojson.io. For 3D we can continue to use the Earth GL string for a 
local globe viewer until a GeoJSON input pane is added to something like 
http://lucenegeo-iono.rhcloud.com/

> Make BaseGeoPointTestCase more debuggable
> -
>
> Key: LUCENE-7189
> URL: https://issues.apache.org/jira/browse/LUCENE-7189
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This class tests queries (boxes, circles, polygons) against indexed documents 
> and fails if the query is wrong.
> Unfortunately it can be hard to debug (depending which test method failed, if 
> it was NIGHTLY, etc).
> It is making issues challenging/slower to debug for me on LUCENE-7185. In 
> general i have found debugging geo related issues is difficult, we should 
> invest more time to make this easier.
> I think we want to display:
> 1) original item (e.g. Rectangle, radius, polygon)
> 2) query.toString() <-- can be different in important ways!
> 3) how many total documents were wrong
> 4) info on up to N (say 5) wrong documents:
>   ID (not lucene docid) of doc.
>   Lat/Lon location(s) of doc
>   any relevant metric such as distance from origin
> 5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
> documents, the query itself, any additional stuff like bounding box that 
> might be useful plotted too.
> I think the wrong documents we should try for one-line (rather than many) and 
> we don't need to print stuff like deleted=false since these queries don't do 
> anything sneaky here around that.



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

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

[jira] [Commented] (SOLR-8957) Query view generates incorrect param names

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-8957:
-

Please check trunk/6.0. I think you'll find this has been fixed already.

> Query view generates incorrect param names
> --
>
> Key: SOLR-8957
> URL: https://issues.apache.org/jira/browse/SOLR-8957
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>
> Following SOLR-8956 we discovered that options within a section are leading 
> to incorrect param-names.
> enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just 
> below) lead to a query containing {{hl=true=something}} obviously missing 
> the {{hl.}} prefix, same was true for {{hl.simple.pre}} as well as 
> {{hl.simple.post}}
> i didn't try but i guess that's true for all sections and not specific to the 
> highlighting. again, [~upayavira] might know where to look?



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

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

[jira] [Commented] (LUCENE-7173) Add Polygon... variant of newPolygonQuery() to Geo3DPoint

[ASF subversion and git services (JIRA)]

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

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

Commit 7289bc36f6eed387629f2a04ff140cc6d1f0959e in lucene-solr's branch 
refs/heads/apiv2 from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7289bc3 ]

LUCENE-7173: Bring polygon API into compliance with 2D version.


> Add Polygon... variant of newPolygonQuery() to Geo3DPoint
> -
>
> Key: LUCENE-7173
> URL: https://issues.apache.org/jira/browse/LUCENE-7173
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7173.patch
>
>
> We need to add the Polygon... variant of newPolygonQuery() to Geo3DPoint to 
> support holes and also bring the Geo3DPoint API into agreement with the 2D 
> API's.



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

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

[jira] [Commented] (LUCENE-7176) Geo3d GeoPath should have a factory and implementation should be package private

[ASF subversion and git services (JIRA)]

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

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

Commit e6fd37c4a1658813d4a272db2d93f4c8a372480b in lucene-solr's branch 
refs/heads/apiv2 from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6fd37c ]

LUCENE-7176: Hide GeoPath implementation in a factory/interface.


> Geo3d GeoPath should have a factory and implementation should be package 
> private
> 
>
> Key: LUCENE-7176
> URL: https://issues.apache.org/jira/browse/LUCENE-7176
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master
>
>
> GeoPath shapes are the only one that don't at the moment have a factory.  
> This should change because it allows us to limit API access to implementation 
> internals.



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

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

[jira] [Commented] (LUCENE-7157) Geo3DPoint implementation should pay attention to the ordering of lat/lon points

[ASF subversion and git services (JIRA)]

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

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

Commit 9bef6c000b913ea2ac1efe93aacf21d477178392 in lucene-solr's branch 
refs/heads/apiv2 from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9bef6c0 ]

LUCENE-7157: More javadoc fixes


> Geo3DPoint implementation should pay attention to the ordering of lat/lon 
> points
> 
>
> Key: LUCENE-7157
> URL: https://issues.apache.org/jira/browse/LUCENE-7157
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master
>
> Attachments: LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.diff, 
> LUCENE-7157.diff, LUCENE-7157.diff, LUCENE-7157.patch
>
>
> The LatLonPoint API implementation pays attention to the order of the points; 
> "clockwise" means one side of the polygon boundary, and "counterclockwise" 
> means the complement.  We need to use that in Geo3DPoint and convert into 
> whatever the underlying GeoPolygonFactory method requires.



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

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

[jira] [Commented] (LUCENE-7174) Upgrade randomizedtesting to 2.3.4

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7174: Upgrade randomizedtesting to 2.3.4


> Upgrade randomizedtesting to 2.3.4
> --
>
> Key: LUCENE-7174
> URL: https://issues.apache.org/jira/browse/LUCENE-7174
> Project: Lucene - Core
>  Issue Type: Test
>  Components: general/test
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: master, 6.1, 6.x
>
>
> The new version has better output of static leak detector, so you are able to 
> figure out which field caused the InaccessibleObjectException or 
> AccessControlException.
> https://github.com/randomizedtesting/randomizedtesting/releases/tag/release%2F2.3.4



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

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

[jira] [Commented] (SOLR-8750) Use lambdas in code where SAM type interfaces are used

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8750: replace anonymous inner class for callable, Runnable etc


> Use lambdas in code where SAM type interfaces are used
> --
>
> Key: SOLR-8750
> URL: https://issues.apache.org/jira/browse/SOLR-8750
> Project: Solr
>  Issue Type: Task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
> Fix For: 6.0
>
>




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

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

[jira] [Commented] (LUCENE-7167) Change select Geo3d classes to package private

[ASF subversion and git services (JIRA)]

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

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

Commit dc2f17483a92a73de3aaa75f5343e32cba8c5f5a in lucene-solr's branch 
refs/heads/apiv2 from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=dc2f174 ]

LUCENE-7167: Re-enable test I disabled because of the package-private changes.


> Change select Geo3d classes to package private
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master
>
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 31 - Still Failing

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.lucene.codecs.memory.TestMemoryDocValuesFormat.testBinaryVariableLengthVsStoredFields

Error Message:
Test abandoned because suite timeout was reached.

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


FAILED:  
junit.framework.TestSuite.org.apache.lucene.codecs.memory.TestMemoryDocValuesFormat

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

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




Build Log:
[...truncated 6656 lines...]
   [junit4] Suite: org.apache.lucene.codecs.memory.TestMemoryDocValuesFormat
   [junit4]   2> apr 07, 2016 5:07:52 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
   [junit4]   2> WARNING: Suite execution timed out: 
org.apache.lucene.codecs.memory.TestMemoryDocValuesFormat
   [junit4]   2>1) Thread[id=12, 
name=TEST-TestMemoryDocValuesFormat.testBinaryVariableLengthVsStoredFields-seed#[613E7B5CBABF0707],
 state=TIMED_WAITING, group=TGRP-TestMemoryDocValuesFormat]
   [junit4]   2> at java.lang.Object.wait(Native Method)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4328)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1802)
   [junit4]   2> at 
org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1736)
   [junit4]   2> at 
org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:421)
   [junit4]   2> at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestBinaryVsStoredFields(BaseDocValuesFormatTestCase.java:1392)
   [junit4]   2> at 
org.apache.lucene.index.BaseDocValuesFormatTestCase.testBinaryVariableLengthVsStoredFields(BaseDocValuesFormatTestCase.java:1419)
   [junit4]   2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]   2> at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]   2> at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]   2> at java.lang.reflect.Method.invoke(Method.java:498)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
   [junit4]   2> at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2> at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
   [junit4]   2> at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
   [junit4]   2> at 

[jira] [Commented] (SOLR-8957) Query view generates incorrect param names

[Max Loeb (JIRA)]

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

Max Loeb commented on SOLR-8957:


I just came here to report this, but I see you already got to it. Thanks much!

> Query view generates incorrect param names
> --
>
> Key: SOLR-8957
> URL: https://issues.apache.org/jira/browse/SOLR-8957
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>
> Following SOLR-8956 we discovered that options within a section are leading 
> to incorrect param-names.
> enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just 
> below) lead to a query containing {{hl=true=something}} obviously missing 
> the {{hl.}} prefix, same was true for {{hl.simple.pre}} as well as 
> {{hl.simple.post}}
> i didn't try but i guess that's true for all sections and not specific to the 
> highlighting. again, [~upayavira] might know where to look?



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_72) - Build # 16451 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data/index.20160407095712454,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data/index.20160407095712519]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data/index.20160407095712454,
 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_6E51A033899BAA54-001/solr-instance-024/./collection1/data/index.20160407095712519]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([6E51A033899BAA54:99224E6B4F7305B2]: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.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:816)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1246)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Resolved] (LUCENE-7184) Add GeoEncodingUtils to core

[Nicholas Knize (JIRA)]

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

Nicholas Knize resolved LUCENE-7184.

Resolution: Fixed
  Assignee: Nicholas Knize

> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Commented] (LUCENE-7184) Add GeoEncodingUtils to core

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7184: Refactor LatLonPoint encoding methods to new GeoEncodingUtils 
helper class in core geo package. Also refactors LatLonPointTests to 
TestGeoEncodingUtils.


> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Commented] (LUCENE-7184) Add GeoEncodingUtils to core

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7184: Refactor LatLonPoint encoding methods to new GeoEncodingUtils 
helper class in core geo package. Also refactors LatLonPointTests to 
TestGeoEncodingUtils.


> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Commented] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7189:


+1

I'll try to make the WebGL earth debugger easier to use ...

> Make BaseGeoPointTestCase more debuggable
> -
>
> Key: LUCENE-7189
> URL: https://issues.apache.org/jira/browse/LUCENE-7189
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> This class tests queries (boxes, circles, polygons) against indexed documents 
> and fails if the query is wrong.
> Unfortunately it can be hard to debug (depending which test method failed, if 
> it was NIGHTLY, etc).
> It is making issues challenging/slower to debug for me on LUCENE-7185. In 
> general i have found debugging geo related issues is difficult, we should 
> invest more time to make this easier.
> I think we want to display:
> 1) original item (e.g. Rectangle, radius, polygon)
> 2) query.toString() <-- can be different in important ways!
> 3) how many total documents were wrong
> 4) info on up to N (say 5) wrong documents:
>   ID (not lucene docid) of doc.
>   Lat/Lon location(s) of doc
>   any relevant metric such as distance from origin
> 5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
> documents, the query itself, any additional stuff like bounding box that 
> might be useful plotted too.
> I think the wrong documents we should try for one-line (rather than many) and 
> we don't need to print stuff like deleted=false since these queries don't do 
> anything sneaky here around that.



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

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

[jira] [Created] (LUCENE-7189) Make BaseGeoPointTestCase more debuggable

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7189:
---

 Summary: Make BaseGeoPointTestCase more debuggable
 Key: LUCENE-7189
 URL: https://issues.apache.org/jira/browse/LUCENE-7189
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


This class tests queries (boxes, circles, polygons) against indexed documents 
and fails if the query is wrong.

Unfortunately it can be hard to debug (depending which test method failed, if 
it was NIGHTLY, etc).

It is making issues challenging/slower to debug for me on LUCENE-7185. In 
general i have found debugging geo related issues is difficult, we should 
invest more time to make this easier.

I think we want to display:
1) original item (e.g. Rectangle, radius, polygon)
2) query.toString() <-- can be different in important ways!
3) how many total documents were wrong
4) info on up to N (say 5) wrong documents:
  ID (not lucene docid) of doc.
  Lat/Lon location(s) of doc
  any relevant metric such as distance from origin
5) GeoTestUtil.toWebGLEarth output of html to visualize those N wrong 
documents, the query itself, any additional stuff like bounding box that might 
be useful plotted too.

I think the wrong documents we should try for one-line (rather than many) and 
we don't need to print stuff like deleted=false since these queries don't do 
anything sneaky here around that.




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

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

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+112-patched) - Build # 363 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/363/
Java: 64bit/jdk-9-ea+112-patched -XX:+UseCompressedOops -XX:+UseSerialGC 
-XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString

Error Message:
expected:<...at=0.772208221547936[6], lon=0.135607475210...> but 
was:<...at=0.772208221547936[7], lon=0.135607475210...>

Stack Trace:
org.junit.ComparisonFailure: expected:<...at=0.772208221547936[6], 
lon=0.135607475210...> but was:<...at=0.772208221547936[7], 
lon=0.135607475210...>
at 
__randomizedtesting.SeedInfo.seed([B50EC455F7202A79:9C981BA3D5D2B2F5]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString(TestGeo3DPoint.java:735)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)




Build Log:
[...truncated 8989 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
-Dtests.method=testShapeQueryToString -Dtests.seed=B50EC455F7202A79 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=de-LU 
-Dtests.timezone=Asia/Oral 

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8933:
-

Why not just enable it during "test mode". So when a test executes, the wrapper 
is added. This can be done by a sysproperty, but we have one already: 
jetty.testmode or like that, which is set during running tests.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Updated] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8933:

Attachment: SOLR-8933.patch

Alright, here's another patch that adds the instrumentation hidden behind a 
system property.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Commented] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-8933:
---

bq. Unsure if it's worth the effort to be technically correct

I think we want to be technically correct here - we don't want to have to count 
on one specific impl protecting us from ourselves.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample

Error Message:
Expected 10 to be found in the testCloudExamplePrompt collection but only found 
2

Stack Trace:
java.lang.AssertionError: Expected 10 to be found in the testCloudExamplePrompt 
collection but only found 2
at 
__randomizedtesting.SeedInfo.seed([190FDDE0C9272EC3:C27E3D2AFE52EBA5]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.util.TestSolrCLIRunExample.testInteractiveSolrCloudExample(TestSolrCLIRunExample.java:457)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11184 lines...]
   [junit4] Suite: org.apache.solr.util.TestSolrCLIRunExample
   [junit4]   2> Creating dataDir: 

[jira] [Resolved] (SOLR-8938) add optional -excluderegex argument to ZkCLI

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-8938.
---
   Resolution: Fixed
Fix Version/s: 6.1
   master

> add optional -excluderegex argument to ZkCLI
> 
>
> Key: SOLR-8938
> URL: https://issues.apache.org/jira/browse/SOLR-8938
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master, 6.1
>
> Attachments: SOLR-8938.patch
>
>
> Add optional {{-excluderegex}} argument to 
> [ZkCLI.java|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/ZkCLI.java]
>  class.
> This change preserves existing behavior (files whose name starts with a . 
> will not be uploaded to ZK) if the new optional argument is not specified. If 
> an {{-excluderegex}} argument is specified then files matching the regular 
> expression won’t be uploaded to ZK.
> Additionally, {{ZkConfigManager.uploadToZK}} now info logs the names of the 
> files that were skipped from uploading to ZK.



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

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

[jira] [Updated] (SOLR-8933) SolrDispatchFilter::consumeInput logs "Stream Closed" IOException

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8933:

Affects Version/s: 4.10.3

Did some further research on why this error doesn't show up with Jetty. It 
appears that {{HttpInput::close()}} (the jetty-server implementation of 
ServletInputStream) is a no-op and takes care of the clean-up by calling 
{{recycle}} at some later point. Unsure if it's worth the effort to be 
_technically_ correct without producing any impact otherwise.

> SolrDispatchFilter::consumeInput logs "Stream Closed" IOException
> -
>
> Key: SOLR-8933
> URL: https://issues.apache.org/jira/browse/SOLR-8933
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Mike Drob
>Assignee: Mark Miller
> Attachments: SOLR-8933.patch, SOLR-8933.patch
>
>
> After SOLR-8453 we started seeing some IOExceptions coming out of 
> SolrDispatchFilter with "Stream Closed" messages.
> It looks like we are indeed closing the request stream in several places when 
> we really need to be letting the web container handle their life cycle. I've 
> got a preliminary patch ready and am working on testing it to make sure there 
> are no regressions.
> A very strange piece of this is that I have been entirely unable to reproduce 
> it on a unit test, but have seen it on cluster deployment quite consistently.



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

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

[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

[Fabio Batista da Silva (JIRA)]

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

Fabio Batista da Silva commented on SOLR-7495:
--

I had fresh SOLR install

> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
> 
> 
> 
> 
> 
> 
>  multiValued="false" required="true"/>
>  multiValued="false" required="true"/>
> 
> 
>  stored="true"/>
> 
> 
> 
>  />
>  sortMissingLast="true"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  precisionStep="0" positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
> 
> id
> name
> 
> 
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at 
> 

[jira] [Commented] (SOLR-8938) add optional -excluderegex argument to ZkCLI

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8938: Add optional -excluderegex argument to ZkCLI.

(Resolved conflicts for solr/CHANGES.txt file and added back ZkCLI's 
OnReconnect import which was removed in branch_6x and master but is still 
needed in branch_5x.)


> add optional -excluderegex argument to ZkCLI
> 
>
> Key: SOLR-8938
> URL: https://issues.apache.org/jira/browse/SOLR-8938
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8938.patch
>
>
> Add optional {{-excluderegex}} argument to 
> [ZkCLI.java|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/ZkCLI.java]
>  class.
> This change preserves existing behavior (files whose name starts with a . 
> will not be uploaded to ZK) if the new optional argument is not specified. If 
> an {{-excluderegex}} argument is specified then files matching the regular 
> expression won’t be uploaded to ZK.
> Additionally, {{ZkConfigManager.uploadToZK}} now info logs the names of the 
> files that were skipped from uploading to ZK.



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

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

[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7495:


Did you reindex? Just adding the parameter to the field definition is not 
enough.

> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
> 
> 
> 
> 
> 
> 
>  multiValued="false" required="true"/>
>  multiValued="false" required="true"/>
> 
> 
>  stored="true"/>
> 
> 
> 
>  />
>  sortMissingLast="true"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  precisionStep="0" positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
> 
> id
> name
> 
> 
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at 
> 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7188:
--

Wow. The F-that part was uncalled for; I wish you could keep your cool and 
respectively disagree with me.  What do you think of my analysis of the bug?

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, _9x.nvm, _9x.si, 
> 

[JENKINS] Lucene-Solr-6.0-Windows (64bit/jdk1.8.0_72) - Build # 9 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.0-Windows/9/
Java: 64bit/jdk1.8.0_72 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
There are still nodes recoverying - waited for 45 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 45 
seconds
at 
__randomizedtesting.SeedInfo.seed([25F6A6B592851C5E:ADA2996F3C7971A6]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:174)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java: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:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[JENKINS] Lucene-Solr-SmokeRelease-6.0 - Build # 8 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.0/8/

No tests ran.

Build Log:
[...truncated 40030 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (14.6 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.5 MB in 0.03 sec (816.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 62.9 MB in 0.12 sec (525.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 73.6 MB in 0.07 sec (1125.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6045 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6045 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.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 215 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.01 sec (24.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.0.0-src.tgz...
   [smoker] 37.5 MB in 0.83 sec (45.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.tgz...
   [smoker] 131.5 MB in 3.02 sec (43.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.zip...
   [smoker] 139.9 MB in 4.19 sec (33.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.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-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.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-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.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-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]  
   [smoker] Started 

[jira] [Updated] (SOLR-6465) CDCR: fall back to whole-index replication when tlogs are insufficient

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-6465:

Attachment: SOLR-6465.patch

Changes:

# Refactored bootstrap status runnable to an inner class called 
BootstrapStatusRunnable
# BootstrapStatusRunnable is closed when either CDCR is disabled via API or 
when the current core is no longer the leadder. It will cancel waiting for 
bootstrap if cdcr is stopped or if the current core is no longer the leader.
# Removed the unused BootstrapService from CdcrRequestHandler
# Added a CANCEL_BOOTSTRAP action in CdcrRequestHandler which will make a best 
effort to cancel a running bootstrap operation.
# If CDCR is disabled on the source cluster of if the leader loses leadership 
then a cancel bootstrap message is sent to the target cluster.

bq. why the double lock in...

This has been removed to only use tryLock.

> CDCR: fall back to whole-index replication when tlogs are insufficient
> --
>
> Key: SOLR-6465
> URL: https://issues.apache.org/jira/browse/SOLR-6465
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Yonik Seeley
> Attachments: SOLR-6465.patch, SOLR-6465.patch
>
>
> When the peer-shard doesn't have transaction logs to forward all the needed 
> updates to bring a peer up to date, we need to fall back to normal 
> replication.



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

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

[jira] [Resolved] (SOLR-8958) OutOfMemoryError while processing search results

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8958.
--
Resolution: Won't Fix

This is overwhelmingly likely to be a configuration issue on your part. Please 
raise this kind of question on the user's list first, you'll get more eyes on 
the problem.

Java starts with a defined amount of memory. This error usually means you're 
trying to cram too much stuff into too little memory. You have to tell us a lot 
more information before we can make any suggestions.

When you move the question to the user's list, you need to include:
How much memory are you allocating to your JVM? What query are you running? How 
many docs in the index? What are the _rest_ of the parameters you use to start 
your Solr instance? What are the docs like in terms of size and fields? You 
might review:

http://wiki.apache.org/solr/UsingMailingLists

And if we determine that it really _is_ a bug, we can open the appropriate JIRA.

> OutOfMemoryError while processing search results
> 
>
> Key: SOLR-8958
> URL: https://issues.apache.org/jira/browse/SOLR-8958
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 5.5
> Environment: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 
> (2016-03-06) x86_64 GNU/Linux
> Java 1.8.0_77-b03
>Reporter: Alexander Veit
>Priority: Critical
>
> When searching is happens that OutOfMemoryErrors occur.
> This is probably a known issue:
> {code:title=ByteUtils.java|borderStyle=solid}
>   /** Convert UTF8 bytes into UTF16 characters. */
>   public static void UTF8toUTF16(byte[] utf8, int offset, int len, CharArr 
> out) {
> // TODO: do in chunks if the input is large
> out.reserve(len);
> int n = UTF8toUTF16(utf8, offset, len, out.getArray(), out.getEnd());
> out.setEnd(out.getEnd() + n);
>   }
> {code}
> These are stack traces from the generated hprof file.
> {noformat}
> WebConnectorWorker-localhost:8102-2
>   at org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BII[CI)I 
> (ByteUtils.java:60)
>   at 
> org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BIILorg/noggit/CharArr;)V 
> (ByteUtils.java:69)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
>  (JavaBinCodec.java:664)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/String;
>  (JavaBinCodec.java:653)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:215)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocument(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocument;
>  (JavaBinCodec.java:411)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:254)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocumentList;
>  (JavaBinCodec.java:425)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:256)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readOrderedMap(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/util/SimpleOrderedMap;
>  (JavaBinCodec.java:154)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:223)
>   at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(Ljava/io/InputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:145)
>   at 
> org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (BinaryResponseParser.java:50)
>   at 
> 

[GitHub] lucene-solr pull request: Upgrade jackson to 2.7

[vdumitrescu]

GitHub user vdumitrescu opened a pull request:

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

Upgrade jackson to 2.7



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

$ git pull https://github.com/vdumitrescu/lucene-solr jackson2.7

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

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

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

This closes #27


commit 5081b7b228114be7aebeb330c8303c9767f3e7b6
Author: Val Dumitrescu 
Date:   2016-04-04T09:29:33Z

Upgraded jackson to 2.7




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7188:
-

fuck that. This is the correct change: since the leniency around directory 
creation was removed in that very issue, it was the correct place to remove the 
leniency.

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, _9x.nvd, 

[jira] [Commented] (LUCENE-7185) fix random number generation used for spatial tests

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7185: fix tie-breaker sort bug


> fix random number generation used for spatial tests
> ---
>
> Key: LUCENE-7185
> URL: https://issues.apache.org/jira/browse/LUCENE-7185
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7185.patch, LUCENE-7185_sorting.patch
>
>
> The current method is not very good for testing. 
> * It will only rarely or never return edge cases like -180/180/-90/90
> * It will only rarely return 0
> * There are many possible doubles within the ranges (-180..180/-90..90) it 
> will never return



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

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

[jira] [Commented] (LUCENE-7185) fix random number generation used for spatial tests

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7185: fix tie-breaker sort bug


> fix random number generation used for spatial tests
> ---
>
> Key: LUCENE-7185
> URL: https://issues.apache.org/jira/browse/LUCENE-7185
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7185.patch, LUCENE-7185_sorting.patch
>
>
> The current method is not very good for testing. 
> * It will only rarely or never return edge cases like -180/180/-90/90
> * It will only rarely return 0
> * There are many possible doubles within the ranges (-180..180/-90..90) it 
> will never return



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

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

[jira] [Commented] (SOLR-7785) Segments API returning java.lang.IllegalStateException

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-7785:


I think this is a duplicate of LUCENE-7188 (I just moved it from Solr to 
Lucene), not just a "relates to".  There is nothing to be fixed in the 
SegmentsInfoRequestHandler if the underlying directory throws this exception.

> Segments API returning java.lang.IllegalStateException
> --
>
> Key: SOLR-7785
> URL: https://issues.apache.org/jira/browse/SOLR-7785
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2.1
>Reporter: Upayavira
>Priority: Minor
>
> A call to this URL: 
> http://localhost:8983/solr/images/admin/segments?_=1436792214599=json
> periodically returns the following exception:
> ERROR - 2015-07-13 12:57:39.962; [   images] 
> org.apache.solr.common.SolrException; null:java.lang.IllegalStateException: 
> file: MMapDirectory@/.some-path/images/data/index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@76180de2 appears both 
> in delegate and in cache: cache=[_pst.fdx, _pst.fdt, pending_segments_n82, 
> _pst_Lucene50_0.dvd, _pst.si, _pst_Lucene50_0.doc, _pst_Lucene50_0.tim, 
> _pst.fnm, _pst_Lucene50_0.dvm, _pst_Lucene50_0.tip],delegate=[_9no.fdt, 
> _9no.fdx, _9no.fnm, _9no.si, _9no_Lucene50_0.doc, _9no_Lucene50_0.dvd, 
> _9no_Lucene50_0.dvm, _9no_Lucene50_0.tim, _9no_Lucene50_0.tip, _akr.cfe, 
> _akr.cfs, _akr.si, _bkw.fdt, _bkw.fdx, _bkw.fnm, _bkw.si, 
> _bkw_Lucene50_0.doc, _bkw_Lucene50_0.dvd, _bkw_Lucene50_0.dvm, 
> _bkw_Lucene50_0.tim, _bkw_Lucene50_0.tip, _che.cfe, _che.cfs, _che.si, 
> _dg5.fdt, _dg5.fdx, _dg5.fnm, _dg5.si, _dg5_Lucene50_0.doc, 
> _dg5_Lucene50_0.dvd, _dg5_Lucene50_0.dvm, _dg5_Lucene50_0.tim, 
> _dg5_Lucene50_0.tip, _ebj.cfe, _ebj.cfs, _ebj.si, _f8m.cfe, _f8m.cfs, 
> _f8m.si, _gap.cfe, _gap.cfs, _gap.si, _h5j.cfe, _h5j.cfs, _h5j.si, _iao.cfe, 
> _iao.cfs, _iao.si, _j62.cfe, _j62.cfs, _j62.si, _jlm.cfe, _jlm.cfs, _jlm.si, 
> _kha.fdt, _kha.fdx, _kha_Lucene50_0.doc, _kha_Lucene50_0.tim, 
> _kha_Lucene50_0.tip, _led.cfe, _led.cfs, _led.si, _md3.cfe, _md3.cfs, 
> _md3.si, _n8h.cfe, _n8h.cfs, _n8h.si, _nec.cfe, _nec.cfs, _nec.si, _njm.cfe, 
> _njm.cfs, _njm.si, _o77.cfe, _o77.cfs, _o77.si, _od2.cfe, _od2.cfs, _od2.si, 
> _ot5.cfe, _ot5.cfs, _ot5.si, _ox1.cfe, _ox1.cfs, _ox1.si, _oyz.cfe, _oyz.cfs, 
> _oyz.si, _p4u.cfe, _p4u.cfs, _p4u.si, _pa4.cfe, _pa4.cfs, _pa4.si, _peu.cfe, 
> _peu.cfs, _peu.si, _pj0.cfe, _pj0.cfs, _pj0.si, _pm1.cfe, _pm1.cfs, _pm1.si, 
> _poj.cfe, _poj.cfs, _poj.si, _pqh.cfe, _pqh.cfs, _pqh.si, _psf.cfe, _psf.cfs, 
> _psf.si, _psj.fdt, _psj.fdx, _psj.fnm, _psj.si, _psj_Lucene50_0.doc, 
> _psj_Lucene50_0.dvd, _psj_Lucene50_0.dvm, _psj_Lucene50_0.tim, 
> _psj_Lucene50_0.tip, _psk.fdt, _psk.fdx, _psk.fnm, _psk.si, 
> _psk_Lucene50_0.doc, _psk_Lucene50_0.dvd, _psk_Lucene50_0.dvm, 
> _psk_Lucene50_0.tim, _psk_Lucene50_0.tip, _psp.cfe, _psp.cfs, _psp.si, 
> _psq.fdt, _psq.fdx, _psq.fnm, _psq.si, _psq_Lucene50_0.doc, 
> _psq_Lucene50_0.dvd, _psq_Lucene50_0.dvm, _psq_Lucene50_0.tim, 
> _psq_Lucene50_0.tip, _psr.fdt, _psr.fdx, _psr.fnm, _psr.si, 
> _psr_Lucene50_0.doc, _psr_Lucene50_0.dvd, _psr_Lucene50_0.dvm, 
> _psr_Lucene50_0.tim, _psr_Lucene50_0.tip, _pss.fdt, _pss.fdx, _pss.fnm, 
> _pss.si, _pss_Lucene50_0.doc, _pss_Lucene50_0.dvd, _pss_Lucene50_0.dvm, 
> _pss_Lucene50_0.tim, _pss_Lucene50_0.tip, pending_segments_n82, segments_n81, 
> write.lock]
> at 
> org.apache.lucene.store.NRTCachingDirectory.listAll(NRTCachingDirectory.java:103)
> at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:641)
> at 
> org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:612)
> at 
> org.apache.lucene.index.SegmentInfos.readLatestCommit(SegmentInfos.java:442)
> at 
> org.apache.solr.handler.admin.SegmentsInfoRequestHandler.getSegmentsInfo(SegmentsInfoRequestHandler.java:60)
> at 
> org.apache.solr.handler.admin.SegmentsInfoRequestHandler.handleRequestBody(SegmentsInfoRequestHandler.java:52)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+112-patched) - Build # 362 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/362/
Java: 64bit/jdk-9-ea+112-patched -XX:+UseCompressedOops -XX:+UseG1GC 
-XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString

Error Message:
expected:<...at=0.772208221547936[6], lon=0.135607475210...> but 
was:<...at=0.772208221547936[7], lon=0.135607475210...>

Stack Trace:
org.junit.ComparisonFailure: expected:<...at=0.772208221547936[6], 
lon=0.135607475210...> but was:<...at=0.772208221547936[7], 
lon=0.135607475210...>
at 
__randomizedtesting.SeedInfo.seed([C0A70D57C9F8A591:E931D2A1EB0A3D1D]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString(TestGeo3DPoint.java:735)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)




Build Log:
[...truncated 9010 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.01s J2 | TestGeo3DPoint.testRandomBig
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4] IGNOR/A 0.00s J2 | TestGeo3DPoint.testEncodeIsStableFromIntSide
   [junit4]> Assumption #1: 

[jira] [Commented] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7188:
--

(I converted this to a a Lucene issue in JIRA)

bq. Stuff is broken if NRTCachingDirectory thinks a file is both cached in ram 
and on disk, the file is "in two places"

Makes sense, though the circumstance seems benign for listAll().  It appears 
there is a race condition between listAll() and unCache().  Notice listAll() 
syncs on "this".  unCache only synchronizes on "this" to delete the file form 
the cache _after_ it has already written to the real backing directory.  

bq.  it was no mistake or "WIP"

Next time, unless it's a trivial change (e.g. formatting, docs, ...) please 
create separate issues for changes that aren't within the scope of the issue 
you're including it on.  Possibly as a required-by if there is a dependency.


> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, 

[jira] [Commented] (LUCENE-7184) Add GeoEncodingUtils to core

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7184:


+1

> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Moved] (LUCENE-7188) IllegalStateException in NRTCachingDirectory.listAll

[David Smiley (JIRA)]

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

David Smiley moved SOLR-8630 to LUCENE-7188:


Affects Version/s: (was: 5.2.1)
   5.2.1
Lucene Fields: New
  Key: LUCENE-7188  (was: SOLR-8630)
  Project: Lucene - Core  (was: Solr)

> IllegalStateException in NRTCachingDirectory.listAll
> 
>
> Key: LUCENE-7188
> URL: https://issues.apache.org/jira/browse/LUCENE-7188
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 5.2.1
> Environment: Production, QA
>Reporter: Semion Mc Alice
>
> Hey,
> we are getting IllegalStateException in 2 different circumstances. The first 
> one is on Status calls:
> {noformat}
> ERROR - 2016-02-01 22:32:43.164; [   ] org.apache.solr.common.SolrException; 
> org.apache.solr.common.SolrException: Error handling 'status' action 
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleStatusAction(CoreAdminHandler.java:748)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestInternal(CoreAdminHandler.java:228)
>   at 
> org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:193)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>   at 
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:660)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:431)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at 
> org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:95)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1129)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
>   at org.eclipse.jetty.server.Server.handle(Server.java:497)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
>   at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.IllegalStateException: file: 
> MMapDirectory@D:\Solr\server\solr\Prod_Core1_shard1_replica2\data\index 
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@65d307e5 appears both 
> in delegate and in cache: cache=[_a0.fdt, _9t_7.liv, _a0.fdx, 
> _a0_Lucene50_0.tip, _a0.nvm, _a0_Lucene50_0.doc, _a0_Lucene50_0.tim, _a0.fnm, 
> _a0_Lucene50_0.pos, _a0.si],delegate=[pending_segments_93, segments_92, 
> write.lock, _9t.fdt, _9t.fdx, _9t.fnm, _9t.nvd, _9t.nvm, _9t.si, _9t_6.liv, 
> _9t_Lucene50_0.doc, _9t_Lucene50_0.pos, _9t_Lucene50_0.tim, 
> _9t_Lucene50_0.tip, _9u.fdt, _9u.fdx, _9u.fnm, _9u.nvd, _9u.nvm, _9u.si, 
> _9u_Lucene50_0.doc, _9u_Lucene50_0.pos, _9u_Lucene50_0.tim, 
> _9u_Lucene50_0.tip, _9v.fdt, _9v.fdx, _9v.fnm, _9v.nvd, _9v.nvm, _9v.si, 
> _9v_Lucene50_0.doc, _9v_Lucene50_0.pos, _9v_Lucene50_0.tim, 
> _9v_Lucene50_0.tip, _9w.fdt, _9w.fdx, _9w.fnm, _9w.nvd, _9w.nvm, _9w.si, 
> _9w_Lucene50_0.doc, _9w_Lucene50_0.pos, _9w_Lucene50_0.tim, 
> _9w_Lucene50_0.tip, _9x.fdt, _9x.fdx, _9x.fnm, 

[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

[Fabio Batista da Silva (JIRA)]

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

Fabio Batista da Silva commented on SOLR-7495:
--

IRC I tried *docValues="true"* and got the same results

> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
> 
> 
> 
> 
> 
> 
>  multiValued="false" required="true"/>
>  multiValued="false" required="true"/>
> 
> 
>  stored="true"/>
> 
> 
> 
>  />
>  sortMissingLast="true"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  precisionStep="0" positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
> 
> id
> name
> 
> 
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
> at 
> 

[JENKINS-EA] Lucene-Solr-6.0-Linux (32bit/jdk-9-ea+112-patched) - Build # 37 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.0-Linux/37/
Java: 32bit/jdk-9-ea+112-patched -server -XX:+UseG1GC -XX:-CompactStrings

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_replica3","base_url":"http://127.0.0.1:40931/_pwm","node_name":"127.0.0.1:40931__pwm","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={   "replicationFactor":"3",   
"shards":{"shard1":{   "range":"8000-7fff",   "state":"active", 
  "replicas":{ "core_node1":{   
"core":"c8n_1x3_lf_shard1_replica1",   
"base_url":"http://127.0.0.1:33242/_pwm;,   
"node_name":"127.0.0.1:33242__pwm",   "state":"down"}, 
"core_node2":{   "state":"down",   
"base_url":"http://127.0.0.1:42109/_pwm;,   
"core":"c8n_1x3_lf_shard1_replica2",   
"node_name":"127.0.0.1:42109__pwm"}, "core_node3":{   
"core":"c8n_1x3_lf_shard1_replica3",   
"base_url":"http://127.0.0.1:40931/_pwm;,   
"node_name":"127.0.0.1:40931__pwm",   "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_replica3","base_url":"http://127.0.0.1:40931/_pwm","node_name":"127.0.0.1:40931__pwm","state":"active","leader":"true"}];
 clusterState: DocCollection(c8n_1x3_lf)={
  "replicationFactor":"3",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"c8n_1x3_lf_shard1_replica1",
  "base_url":"http://127.0.0.1:33242/_pwm;,
  "node_name":"127.0.0.1:33242__pwm",
  "state":"down"},
"core_node2":{
  "state":"down",
  "base_url":"http://127.0.0.1:42109/_pwm;,
  "core":"c8n_1x3_lf_shard1_replica2",
  "node_name":"127.0.0.1:42109__pwm"},
"core_node3":{
  "core":"c8n_1x3_lf_shard1_replica3",
  "base_url":"http://127.0.0.1:40931/_pwm;,
  "node_name":"127.0.0.1:40931__pwm",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([241F2D7E1C1E3E37:AC4B12A4B2E253CF]: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:170)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
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:809)
   

[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet

[Matt Hilt (JIRA)]

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

Matt Hilt commented on SOLR-7495:
-

We had this problem using Solr 5.1 on an index that was *not sharded*. The 
fields in question did not have docValues set however.

> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year' 
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
> 
> 
> 
> 
> 
> 
>  multiValued="false" required="true"/>
>  multiValued="false" required="true"/>
> 
> 
>  stored="true"/>
> 
> 
> 
>  />
>  sortMissingLast="true"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  precisionStep="0" positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  positionIncrementGap="100">
> 
> 
>  words="stopwords.txt" />
> 
>  maxGramSize="15"/>
> 
> 
> 
>  words="stopwords.txt" />
>  synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
> 
> 
> 
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" 
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
> 
> id
> name
> 
> 
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at 
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at 
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at 
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at 
> 

[jira] [Updated] (LUCENE-7184) Add GeoEncodingUtils to core

[Nicholas Knize (JIRA)]

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

Nicholas Knize updated LUCENE-7184:
---
Attachment: LUCENE-7184.patch

I had to rebase from master to catch the test and encoding changes since the 
patch was posted.  Here's one last patch to double check nothing was missed in 
the rebase. 

> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Commented] (SOLR-8938) add optional -excluderegex argument to ZkCLI

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8938: Add optional -excluderegex argument to ZkCLI.


> add optional -excluderegex argument to ZkCLI
> 
>
> Key: SOLR-8938
> URL: https://issues.apache.org/jira/browse/SOLR-8938
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8938.patch
>
>
> Add optional {{-excluderegex}} argument to 
> [ZkCLI.java|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/ZkCLI.java]
>  class.
> This change preserves existing behavior (files whose name starts with a . 
> will not be uploaded to ZK) if the new optional argument is not specified. If 
> an {{-excluderegex}} argument is specified then files matching the regular 
> expression won’t be uploaded to ZK.
> Additionally, {{ZkConfigManager.uploadToZK}} now info logs the names of the 
> files that were skipped from uploading to ZK.



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

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

[jira] [Commented] (LUCENE-7184) Add GeoEncodingUtils to core

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7184:


+1

> Add GeoEncodingUtils to core
> 
>
> Key: LUCENE-7184
> URL: https://issues.apache.org/jira/browse/LUCENE-7184
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Fix For: master, 6.1
>
> Attachments: LUCENE-7184.patch, LUCENE-7184.patch
>
>
> This is part 1 for LUCENE-7165. This task will add a {{GeoEncodingUtils}} 
> helper class to {{o.a.l.geo}} in the core module for reusing lat/lon encoding 
> methods. Existing encoding methods in {{LatLonPoint}} will be refactored to 
> the new helper class so a new numerically stable morton encoding can be added 
> that reuses the same encoding methods.



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

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

[jira] [Commented] (SOLR-8958) OutOfMemoryError while processing search results

[Alexander Veit (JIRA)]

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

Alexander Veit commented on SOLR-8958:
--

According to the admin the value is 50.

> OutOfMemoryError while processing search results
> 
>
> Key: SOLR-8958
> URL: https://issues.apache.org/jira/browse/SOLR-8958
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 5.5
> Environment: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 
> (2016-03-06) x86_64 GNU/Linux
> Java 1.8.0_77-b03
>Reporter: Alexander Veit
>Priority: Critical
>
> When searching is happens that OutOfMemoryErrors occur.
> This is probably a known issue:
> {code:title=ByteUtils.java|borderStyle=solid}
>   /** Convert UTF8 bytes into UTF16 characters. */
>   public static void UTF8toUTF16(byte[] utf8, int offset, int len, CharArr 
> out) {
> // TODO: do in chunks if the input is large
> out.reserve(len);
> int n = UTF8toUTF16(utf8, offset, len, out.getArray(), out.getEnd());
> out.setEnd(out.getEnd() + n);
>   }
> {code}
> These are stack traces from the generated hprof file.
> {noformat}
> WebConnectorWorker-localhost:8102-2
>   at org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BII[CI)I 
> (ByteUtils.java:60)
>   at 
> org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BIILorg/noggit/CharArr;)V 
> (ByteUtils.java:69)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
>  (JavaBinCodec.java:664)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/String;
>  (JavaBinCodec.java:653)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:215)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocument(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocument;
>  (JavaBinCodec.java:411)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:254)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocumentList;
>  (JavaBinCodec.java:425)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:256)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readOrderedMap(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/util/SimpleOrderedMap;
>  (JavaBinCodec.java:154)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:223)
>   at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(Ljava/io/InputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:145)
>   at 
> org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (BinaryResponseParser.java:50)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(Lorg/apache/http/client/methods/HttpRequestBase;Lorg/apache/solr/client/solrj/ResponseParser;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:551)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Lorg/apache/solr/client/solrj/ResponseParser;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:229)
>   at 
> org.apache.solr.client.solrj.SolrRequest.process(Lorg/apache/solr/client/solrj/SolrClient;Ljava/lang/String;)Lorg/apache/solr/client/solrj/SolrResponse;
>  (SolrRequest.java:149)
>   at 
> 

[RESULT] Lucene/Solr 6.0.0 RC2 Release Vote

[Nicholas Knize]

The release vote has passed. I will now publish.

Thanks to everyone that voted and helped me with the release process!

- Nick Knize

[JENKINS] Lucene-Solr-Tests-master - Build # 1059 - Still Failing

[Apache Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<2> but was:<5>
at 
__randomizedtesting.SeedInfo.seed([D5E7B39AF4FA1AE6:5DB38C405A06771E]: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.AliasIntegrationTest.test(AliasIntegrationTest.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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[ASF subversion and git services (JIRA)]

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

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

Commit 16c6dd9a2d67d88e18a43f24ff636a4ddca0f123 in lucene-solr's branch 
refs/heads/branch_6x from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=16c6dd9 ]

LUCENE-7168: fix ceil/floor decode to match encode


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[ASF subversion and git services (JIRA)]

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

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

Commit df07e0c30ff0d90f9052dd411f027c0dfcc3fb88 in lucene-solr's branch 
refs/heads/master from Mike McCandless
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=df07e0c ]

LUCENE-7168: fix ceil/floor decode to match encode


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (SOLR-8938) add optional -excluderegex argument to ZkCLI

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8938: Add optional -excluderegex argument to ZkCLI.


> add optional -excluderegex argument to ZkCLI
> 
>
> Key: SOLR-8938
> URL: https://issues.apache.org/jira/browse/SOLR-8938
> Project: Solr
>  Issue Type: Improvement
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8938.patch
>
>
> Add optional {{-excluderegex}} argument to 
> [ZkCLI.java|https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/cloud/ZkCLI.java]
>  class.
> This change preserves existing behavior (files whose name starts with a . 
> will not be uploaded to ZK) if the new optional argument is not specified. If 
> an {{-excluderegex}} argument is specified then files matching the regular 
> expression won’t be uploaded to ZK.
> Additionally, {{ZkConfigManager.uploadToZK}} now info logs the names of the 
> files that were skipped from uploading to ZK.



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

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

[jira] [Commented] (SOLR-8958) OutOfMemoryError while processing search results

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-8958:
-

This OutOfMemory is happening on the client while parsing the returned 
documents. What is the value of "rows" in your search query?

> OutOfMemoryError while processing search results
> 
>
> Key: SOLR-8958
> URL: https://issues.apache.org/jira/browse/SOLR-8958
> Project: Solr
>  Issue Type: Bug
>  Components: clients - java
>Affects Versions: 5.5
> Environment: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 
> (2016-03-06) x86_64 GNU/Linux
> Java 1.8.0_77-b03
>Reporter: Alexander Veit
>Priority: Critical
>
> When searching is happens that OutOfMemoryErrors occur.
> This is probably a known issue:
> {code:title=ByteUtils.java|borderStyle=solid}
>   /** Convert UTF8 bytes into UTF16 characters. */
>   public static void UTF8toUTF16(byte[] utf8, int offset, int len, CharArr 
> out) {
> // TODO: do in chunks if the input is large
> out.reserve(len);
> int n = UTF8toUTF16(utf8, offset, len, out.getArray(), out.getEnd());
> out.setEnd(out.getEnd() + n);
>   }
> {code}
> These are stack traces from the generated hprof file.
> {noformat}
> WebConnectorWorker-localhost:8102-2
>   at org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BII[CI)I 
> (ByteUtils.java:60)
>   at 
> org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BIILorg/noggit/CharArr;)V 
> (ByteUtils.java:69)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
>  (JavaBinCodec.java:664)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/String;
>  (JavaBinCodec.java:653)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:215)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocument(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocument;
>  (JavaBinCodec.java:411)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:254)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
>  (JavaBinCodec.java:543)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:221)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocumentList;
>  (JavaBinCodec.java:425)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:256)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readOrderedMap(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/util/SimpleOrderedMap;
>  (JavaBinCodec.java:154)
>   at 
> org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:223)
>   at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(Ljava/io/InputStream;)Ljava/lang/Object;
>  (JavaBinCodec.java:145)
>   at 
> org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (BinaryResponseParser.java:50)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(Lorg/apache/http/client/methods/HttpRequestBase;Lorg/apache/solr/client/solrj/ResponseParser;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:551)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Lorg/apache/solr/client/solrj/ResponseParser;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:240)
>   at 
> org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
>  (HttpSolrClient.java:229)
>   at 
> 

[jira] [Resolved] (LUCENE-7173) Add Polygon... variant of newPolygonQuery() to Geo3DPoint

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7173.
-
   Resolution: Fixed
Fix Version/s: 6.x

> Add Polygon... variant of newPolygonQuery() to Geo3DPoint
> -
>
> Key: LUCENE-7173
> URL: https://issues.apache.org/jira/browse/LUCENE-7173
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Affects Versions: master
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: master, 6.x
>
> Attachments: LUCENE-7173.patch
>
>
> We need to add the Polygon... variant of newPolygonQuery() to Geo3DPoint to 
> support holes and also bring the Geo3DPoint API into agreement with the 2D 
> API's.



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

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

[jira] [Updated] (SOLR-8958) OutOfMemoryError while processing search results

[Alexander Veit (JIRA)]

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

Alexander Veit updated SOLR-8958:
-
Description: 
When searching is happens that OutOfMemoryErrors occur.

This is probably a known issue:

{code:title=ByteUtils.java|borderStyle=solid}
  /** Convert UTF8 bytes into UTF16 characters. */
  public static void UTF8toUTF16(byte[] utf8, int offset, int len, CharArr out) 
{
// TODO: do in chunks if the input is large
out.reserve(len);
int n = UTF8toUTF16(utf8, offset, len, out.getArray(), out.getEnd());
out.setEnd(out.getEnd() + n);
  }
{code}

These are stack traces from the generated hprof file.

{noformat}
WebConnectorWorker-localhost:8102-2
  at org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BII[CI)I 
(ByteUtils.java:60)
  at 
org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BIILorg/noggit/CharArr;)V 
(ByteUtils.java:69)
  at 
org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
 (JavaBinCodec.java:664)
  at 
org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/String;
 (JavaBinCodec.java:653)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:215)
  at 
org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
 (JavaBinCodec.java:543)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:221)
  at 
org.apache.solr.common.util.JavaBinCodec.readSolrDocument(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocument;
 (JavaBinCodec.java:411)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:254)
  at 
org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
 (JavaBinCodec.java:543)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:221)
  at 
org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocumentList;
 (JavaBinCodec.java:425)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:256)
  at 
org.apache.solr.common.util.JavaBinCodec.readOrderedMap(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/util/SimpleOrderedMap;
 (JavaBinCodec.java:154)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:223)
  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(Ljava/io/InputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:145)
  at 
org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (BinaryResponseParser.java:50)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(Lorg/apache/http/client/methods/HttpRequestBase;Lorg/apache/solr/client/solrj/ResponseParser;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:551)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Lorg/apache/solr/client/solrj/ResponseParser;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:240)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:229)
  at 
org.apache.solr.client.solrj.SolrRequest.process(Lorg/apache/solr/client/solrj/SolrClient;Ljava/lang/String;)Lorg/apache/solr/client/solrj/SolrResponse;
 (SolrRequest.java:149)
  at 
org.apache.solr.client.solrj.SolrClient.query(Ljava/lang/String;Lorg/apache/solr/common/params/SolrParams;)Lorg/apache/solr/client/solrj/response/QueryResponse;
 (SolrClient.java:942)
{noformat}

Another one:

{noformat}
WebConnectorWorker-localhost:8102-8
  at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)
  at java.util.Arrays.copyOfRange([CII)[C (Arrays.java:3664)
  at java.lang.String.([CII)V (String.java:207)
  at org.noggit.CharArr.toString()Ljava/lang/String; (CharArr.java:168)
  at 
org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
 (JavaBinCodec.java:665)
  at 

[jira] [Created] (SOLR-8958) OutOfMemoryError while processing search results

[Alexander Veit (JIRA)]

Alexander Veit created SOLR-8958:


 Summary: OutOfMemoryError while processing search results
 Key: SOLR-8958
 URL: https://issues.apache.org/jira/browse/SOLR-8958
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 5.5
 Environment: Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 
(2016-03-06) x86_64 GNU/Linux
Java 1.8.0_77-b03
Reporter: Alexander Veit
Priority: Critical


When searching is happens that an OutOfMemoryError occurs.

This is probably a known issue:

{code:title=ByteUtils.java|borderStyle=solid}
  /** Convert UTF8 bytes into UTF16 characters. */
  public static void UTF8toUTF16(byte[] utf8, int offset, int len, CharArr out) 
{
// TODO: do in chunks if the input is large
out.reserve(len);
int n = UTF8toUTF16(utf8, offset, len, out.getArray(), out.getEnd());
out.setEnd(out.getEnd() + n);
  }
{code}

These are stack traces from the generated hprof file.

{noformat}
WebConnectorWorker-localhost:8102-2
  at org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BII[CI)I 
(ByteUtils.java:60)
  at 
org.apache.solr.common.util.ByteUtils.UTF8toUTF16([BIILorg/noggit/CharArr;)V 
(ByteUtils.java:69)
  at 
org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;Lorg/apache/solr/common/util/JavaBinCodec$StringCache;)Ljava/lang/String;
 (JavaBinCodec.java:664)
  at 
org.apache.solr.common.util.JavaBinCodec.readStr(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/String;
 (JavaBinCodec.java:653)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:215)
  at 
org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
 (JavaBinCodec.java:543)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:221)
  at 
org.apache.solr.common.util.JavaBinCodec.readSolrDocument(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocument;
 (JavaBinCodec.java:411)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:254)
  at 
org.apache.solr.common.util.JavaBinCodec.readArray(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/util/List;
 (JavaBinCodec.java:543)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:221)
  at 
org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/SolrDocumentList;
 (JavaBinCodec.java:425)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:256)
  at 
org.apache.solr.common.util.JavaBinCodec.readOrderedMap(Lorg/apache/solr/common/util/DataInputInputStream;)Lorg/apache/solr/common/util/SimpleOrderedMap;
 (JavaBinCodec.java:154)
  at 
org.apache.solr.common.util.JavaBinCodec.readVal(Lorg/apache/solr/common/util/DataInputInputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:223)
  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(Ljava/io/InputStream;)Ljava/lang/Object;
 (JavaBinCodec.java:145)
  at 
org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(Ljava/io/InputStream;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (BinaryResponseParser.java:50)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(Lorg/apache/http/client/methods/HttpRequestBase;Lorg/apache/solr/client/solrj/ResponseParser;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:551)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Lorg/apache/solr/client/solrj/ResponseParser;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:240)
  at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(Lorg/apache/solr/client/solrj/SolrRequest;Ljava/lang/String;)Lorg/apache/solr/common/util/NamedList;
 (HttpSolrClient.java:229)
  at 
org.apache.solr.client.solrj.SolrRequest.process(Lorg/apache/solr/client/solrj/SolrClient;Ljava/lang/String;)Lorg/apache/solr/client/solrj/SolrResponse;
 (SolrRequest.java:149)
  at 
org.apache.solr.client.solrj.SolrClient.query(Ljava/lang/String;Lorg/apache/solr/common/params/SolrParams;)Lorg/apache/solr/client/solrj/response/QueryResponse;
 (SolrClient.java:942)
{noformat}

Another one:

{noformat}
WebConnectorWorker-localhost:8102-8
  at java.lang.OutOfMemoryError.()V (OutOfMemoryError.java:48)
  at java.util.Arrays.copyOfRange([CII)[C (Arrays.java:3664)
  at java.lang.String.([CII)V (String.java:207)
  

Re: Apache Solr and Tika used to index Panama Papers

[Erik Hatcher]

Also of note, Blacklight was used for the Solr-based UI - 
http://projectblacklight.org

And another link about the data analysis process - 
https://ijnet.org/en/blog/how-icij-pulled-large-scale-cross-border-investigative-collaboration

"Layered on top was the shiny interface, built using Blacklight, another open 
source development."



> On Apr 6, 2016, at 04:45, Uwe Schindler  wrote:
> 
> Hi all,
> 
> I just wanted to repost the following by Chris Mattman on the TIKA list:
> 
> If you have been following the news you’ve seen the Panama papers and how the 
> world’s rich and elite have been storing all their money offshore to hide it. 
> Two of the ASF’s key technologies were used in uncovering that story and 
> showing the world what was going on: Apache Tika and Apache Solr.
> 
> Solr was used for making the Terabytes of Panama Papers available to 
> journalists. The preprocessing of the documents for indexing was done with 
> Tika (maybe through the contrib/extraction module).
> 
> Here is the article by Forbes about that:
> http://www.forbes.com/sites/thomasbrewster/2016/04/05/panama-papers-amazon-encryption-epic-leak
> 
> Uwe
> 
> -
> Uwe Schindler
> uschind...@apache.org 
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[jira] [Updated] (LUCENE-7187) Block join queries' weight impl should implement extractTerms(...)

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-7187:
--
Attachment: LUCENE_7187.patch

Attached patch that changes the block join queries to delegate to the child 
queries extractTerms(...)

> Block join queries' weight impl should implement extractTerms(...)
> --
>
> Key: LUCENE-7187
> URL: https://issues.apache.org/jira/browse/LUCENE-7187
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Martijn van Groningen
>Priority: Minor
> Attachments: LUCENE_7187.patch
>
>
> In the case the distribute document frequencies need to be computed for block 
> join queries, the child query is ignored.



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

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

[jira] [Created] (LUCENE-7187) Block join queries' weight impl should implement extractTerms(...)

[Martijn van Groningen (JIRA)]

Martijn van Groningen created LUCENE-7187:
-

 Summary: Block join queries' weight impl should implement 
extractTerms(...)
 Key: LUCENE-7187
 URL: https://issues.apache.org/jira/browse/LUCENE-7187
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Martijn van Groningen
Priority: Minor


In the case the distribute document frequencies need to be computed for block 
join queries, the child query is ignored.



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

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+112-patched) - Build # 16448 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16448/
Java: 32bit/jdk-9-ea+112-patched -server -XX:+UseSerialGC -XX:-CompactStrings

1 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString

Error Message:
expected:<...at=0.772208221547936[6], lon=0.135607475210...> but 
was:<...at=0.772208221547936[7], lon=0.135607475210...>

Stack Trace:
org.junit.ComparisonFailure: expected:<...at=0.772208221547936[6], 
lon=0.135607475210...> but was:<...at=0.772208221547936[7], 
lon=0.135607475210...>
at 
__randomizedtesting.SeedInfo.seed([5F3DE38F5B937931:76AB3C797961E1BD]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testShapeQueryToString(TestGeo3DPoint.java:738)
at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(java.base@9-ea/Thread.java:804)




Build Log:
[...truncated 9012 lines...]
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
-Dtests.method=testShapeQueryToString -Dtests.seed=5F3DE38F5B937931 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=hy 
-Dtests.timezone=Africa/Accra -Dtests.asserts=true 

[jira] [Created] (SOLR-8957) Query view generates incorrect param names

[Stefan Matheis (steffkes) (JIRA)]

Stefan Matheis (steffkes) created SOLR-8957:
---

 Summary: Query view generates incorrect param names
 Key: SOLR-8957
 URL: https://issues.apache.org/jira/browse/SOLR-8957
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 5.5, 5.4, master
Reporter: Stefan Matheis (steffkes)


Following SOLR-8956 we discovered that options within a section are leading to 
incorrect param-names.

enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just below) 
lead to a query containing {{hl=true=something}} obviously missing the 
{{hl.}} prefix, same was true for {{hl.simple.pre}} as well as 
{{hl.simple.post}}

i didn't try but i guess that's true for all sections and not specific to the 
highlighting. again, [~upayavira] might know where to look?



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

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

[jira] [Updated] (SOLR-8956) Highlight missing in Analysis View

[Stefan Matheis (steffkes) (JIRA)]

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

Stefan Matheis (steffkes) updated SOLR-8956:

Attachment: Solr+Admin+2016-04-06+12-09-23.png
Solr+Admin+2016-04-06+12-03-36.png

> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
> Attachments: Solr+Admin+2016-04-06+12-03-36.png, 
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots 
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked 
> about highlighting in general - questioning a few things has gotten us to the 
> analysis view for debugging purposes. not seeing any highlights given the 
> index/query data - i've asked him to try the very same in the old admin ui 
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where 
> / at what to look?



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

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

[jira] [Created] (SOLR-8956) Highlight missing in Analysis View

[Stefan Matheis (steffkes) (JIRA)]

Stefan Matheis (steffkes) created SOLR-8956:
---

 Summary: Highlight missing in Analysis View
 Key: SOLR-8956
 URL: https://issues.apache.org/jira/browse/SOLR-8956
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis, web gui
Affects Versions: 5.5, 5.4, master
Reporter: Stefan Matheis (steffkes)


the new analysis view is missing the highlighting for matches. screenshots 
appended to show the difference.

this was reported by user {{mloeb}} on #solr yesterday. initially he asked 
about highlighting in general - questioning a few things has gotten us to the 
analysis view for debugging purposes. not seeing any highlights given the 
index/query data - i've asked him to try the very same in the old admin ui 
where it worked.

i haven't dived in the code yet, probably [~upayavira] can give a hint where / 
at what to look?



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

Patch looks good! +1 for the latest

> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7168) Remove geo3d test leniency

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

Phew.

Yes, I now vaguely recall that we had this discussion early.  I'm glad you 
found the issue before I went nuts repeating last year's logic. :-)


> Remove geo3d test leniency
> --
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
> Fix For: master, 6.1
>
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch, 
> LUCENE-7168.patch, LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization 
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
> but don't quantize query shapes.



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

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