[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7906:
--

Hi [~daddywri],

The problem with convex polygons is that the whole plane is within the shape 
and therefore if you try to bound the intersection with the convex polygon you 
get OVERLAP when the shape is actually WITHIN. What it holds true is that the 
bounds for an intersection for convex polygons are the ones defined by the 
convex counter part. Therefore I need to invert the shape to bound the 
intersection. The class variable is to cash the object so it is only created 
once. Does it make sense?

I will try to implement randomized tests as well but it will take a bit longer 
because I have never used the framework and I am actually having problems 
running those tests (environment issues).

Finally, I want to go back to the idea of moving GeoArea down to GeoShape. If 
the implementation for polygons is valid, it means that any shape that can 
implement the new interface method intersects(GeoShape geoShape) can implement 
GeoArea. You were concerned about circle intersection but I think it is a 
trivial implementation. We only need to add the interface GeoOutsideDistance to 
GeoShape which is free as all shapes already implement the interface. Then 
intersection is trivial by calculating the distance of the shape to the center 
of the circle. What do you think?

Cheers,

Ignacio

  



> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-9-ea+178) - Build # 61 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/61/
Java: 64bit/jdk-9-ea+178 -XX:+UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([CF15504DBB35199E:7694869297DF1D14]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:14==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 39 more




Build Log:
[...truncated 11534 lines...]
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4]   2> 

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 11 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/11/

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

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:53743/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:41534/solr/test_col_shard1_replica_n2: Server Error
request: 
http://127.0.0.1:41534/solr/test_col_shard1_replica_n2/update?update.distrib=TOLEADER=http%3A%2F%2F127.0.0.1%3A53743%2Fsolr%2Ftest_col_shard1_replica_n1%2F=javabin=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:53743/solr/test_col_shard1_replica_n1/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@789642e

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



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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([30D23C0E6EA0E56A:BBF5EFDF2FA64EEE]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:183)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:907)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:436)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Updated] (SOLR-10916) Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4/SolrCloudTestCase

[Steve Rowe (JIRA)]

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

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

WIP patch with just TestSolrCloudWithKerberosAlt converted to extend 
SolrCloudTestCase so far.

> Any Solr test using MiniSolrCloud or Solr Core's should extend 
> SolrTestCaseJ4/SolrCloudTestCase
> ---
>
> Key: SOLR-10916
> URL: https://issues.apache.org/jira/browse/SOLR-10916
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Attachments: SOLR-10916.patch
>
>
> We have a non-trivial number of tests  that extend LuceneTestCase directly.
> For "utility" method minded tests, this is fine - but for any test that wants 
> to instantiate re-use shared config files to instantiate SolrCores, or 
> instances of MiniSolrCloudCluster, this makes these tests really cumbersome 
> to maintain and deal with because htye don't leverage the existing 
> randomization setup logic in SolrTestCaseJ4.
> we should fix these tests where applicable



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10916) Any Solr test using MiniSolrCloud or Solr Core's should extend SolrTestCaseJ4/SolrCloudTestCase

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-10916:
-

Assignee: Steve Rowe

> Any Solr test using MiniSolrCloud or Solr Core's should extend 
> SolrTestCaseJ4/SolrCloudTestCase
> ---
>
> Key: SOLR-10916
> URL: https://issues.apache.org/jira/browse/SOLR-10916
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
>
> We have a non-trivial number of tests  that extend LuceneTestCase directly.
> For "utility" method minded tests, this is fine - but for any test that wants 
> to instantiate re-use shared config files to instantiate SolrCores, or 
> instances of MiniSolrCloudCluster, this makes these tests really cumbersome 
> to maintain and deal with because htye don't leverage the existing 
> randomization setup logic in SolrTestCaseJ4.
> we should fix these tests where applicable



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913_fixTests.patch

Oops!
My patch on Solr 6.6.0 makes these 3 tests fail :
org.apache.solr.search.TestSmileRequest.testDistribJsonRequest
org.apache.solr.search.json.TestJsonRequest.testLocalJsonRequest
org.apache.solr.search.json.TestJsonRequest.testDistribJsonRequest

Adding SOLR-7913_fixTests.patch, to be applied on top of SOLR-7913.patch 
(2017-07-20).
It contains a ridiculous, horrifying hack.  But the advantage is that the 3 
search tests listed above pass, and it also allows to re-enable 
org.apache.solr.request.TestRemoteStreaming.testNoUrlAccess(). A boolean to 
filter only MLT with stream.body has a lot less impact everywhere else.

I ran all solr tests, this time ;)



> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
> Attachments: SOLR-7913_fixTests.patch, SOLR-7913.patch, 
> SOLR-7913.patch, SOLR-7913.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-10835:
-
Priority: Major  (was: Blocker)

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
>  Labels: numeric-tries-to-points
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10835-fixtest.patch, SOLR-10835.patch, 
> SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 25696 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (41.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-8.0.0-src.tgz...
   [smoker] 28.9 MB in 0.02 sec (1239.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.tgz...
   [smoker] 68.9 MB in 0.06 sec (1234.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-8.0.0.zip...
   [smoker] 79.2 MB in 0.06 sec (1251.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-8.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6128 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-8.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] 
   [smoker] command "export JAVA_HOME="/home/jenkins/tools/java/latest1.8" 
PATH="/home/jenkins/tools/java/latest1.8/bin:$PATH" 
JAVACMD="/home/jenkins/tools/java/latest1.8/bin/java"; ant clean test 
-Dtests.slow=false" failed:
   [smoker] Buildfile: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build.xml
   [smoker] 
   [smoker] clean:
   [smoker][delete] Deleting directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/build
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: Apache Ivy 2.3.0 - 20130110142753 :: 
http://ant.apache.org/ivy/ ::
   [smoker] [ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] resolve-groovy:
   [smoker] [ivy:cachepath] :: resolving dependencies :: 
org.codehaus.groovy#groovy-all-caller;working
   [smoker] [ivy:cachepath] confs: [default]
   [smoker] [ivy:cachepath] found org.codehaus.groovy#groovy-all;2.4.8 in 
public
   [smoker] [ivy:cachepath] :: resolution report :: resolve 148ms :: artifacts 
dl 9ms
   [smoker] 
-
   [smoker] |  |modules||   
artifacts   |
   [smoker] |   conf   | number| search|dwnlded|evicted|| 
number|dwnlded|
   [smoker] 
-
   [smoker] |  default |   1   |   0   |   0   |   0   ||   1   |   
0   |
   [smoker] 
-
   [smoker] 
   [smoker] -init-totals:
   [smoker] 
   [smoker] test-core:
   [smoker] 
   [smoker] -clover.disable:
   [smoker] 
   [smoker] ivy-availability-check:
   [smoker] 
   [smoker] ivy-fail:
   [smoker] 
   [smoker] ivy-configure:
   [smoker] [ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/lucene-8.0.0/top-level-ivy-settings.xml
   [smoker] 
   [smoker] -clover.load:
   [smoker] 
   [smoker] -clover.classpath:
   [smoker] 
   [smoker] -clover.setup:
   [smoker] 
   [smoker] clover:
   [smoker] 
   [smoker] -check-git-state:
   [smoker] 
   [smoker] -git-cleanroot:
   [smoker] 
   [smoker] -copy-git-state:
   [smoker] 
   [smoker] git-autoclean:
   [smoker] 
   [smoker] resolve:
   

[jira] [Commented] (SOLR-10949) analytics component has hard coded assumptions about Trie numeric fields -- tests fail with randomized point fields

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-10949:


Assumptions abo

> analytics component has hard coded assumptions about Trie numeric fields -- 
> tests fail with randomized point fields
> ---
>
> Key: SOLR-10949
> URL: https://issues.apache.org/jira/browse/SOLR-10949
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
>
> Found as part of SOLR-10947... attempting to use numeric PointFields in 
> contrib/analytics tests cause problems in some tests due to classes like 
> StatsCollectorSupplierFactory, RangeEndpointCalculator, and AnalyticsParsers 
> having hard coded assumptions about using Trie based numeric fields (via 
> instanceof and clas equality checks)
> (It's not immediately obvious if replacing these checks with inspection of 
> {{FieldType.getNumberType()}} would solve all the problems, or if other 
> assumptions are made down stream in the code)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10949) analytics component has hard coded assumptions about Trie numeric fields -- tests fail with randomized point fields

[Dennis Gove (JIRA)]

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

Dennis Gove edited comment on SOLR-10949 at 7/20/17 11:52 PM:
--

Assumptions about Trie numeric fields in the Analytics component has been 
resolved as part of SOLR-10123. That assumption is no longer being made.


was (Author: dpgove):
Assumptions abo

> analytics component has hard coded assumptions about Trie numeric fields -- 
> tests fail with randomized point fields
> ---
>
> Key: SOLR-10949
> URL: https://issues.apache.org/jira/browse/SOLR-10949
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
>
> Found as part of SOLR-10947... attempting to use numeric PointFields in 
> contrib/analytics tests cause problems in some tests due to classes like 
> StatsCollectorSupplierFactory, RangeEndpointCalculator, and AnalyticsParsers 
> having hard coded assumptions about using Trie based numeric fields (via 
> instanceof and clas equality checks)
> (It's not immediately obvious if replacing these checks with inspection of 
> {{FieldType.getNumberType()}} would solve all the problems, or if other 
> assumptions are made down stream in the code)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10949) analytics component has hard coded assumptions about Trie numeric fields -- tests fail with randomized point fields

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-10949:


Assumptions abo

> analytics component has hard coded assumptions about Trie numeric fields -- 
> tests fail with randomized point fields
> ---
>
> Key: SOLR-10949
> URL: https://issues.apache.org/jira/browse/SOLR-10949
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>  Labels: numeric-tries-to-points
>
> Found as part of SOLR-10947... attempting to use numeric PointFields in 
> contrib/analytics tests cause problems in some tests due to classes like 
> StatsCollectorSupplierFactory, RangeEndpointCalculator, and AnalyticsParsers 
> having hard coded assumptions about using Trie based numeric fields (via 
> instanceof and clas equality checks)
> (It's not immediately obvious if replacing these checks with inspection of 
> {{FieldType.getNumberType()}} would solve all the problems, or if other 
> assumptions are made down stream in the code)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-10123) Analytics Component 2.0

[Dennis Gove (JIRA)]

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

Dennis Gove closed SOLR-10123.
--
Resolution: Fixed

Work related to this ticket is complete.

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-10123:


I thought it might be something related to the cloud not yet being ready, but 
QueryFacetCloudTest extends AbstractAnalyticsFacetCloudTest and calls 
[`setupCluster`|https://github.com/apache/lucene-solr/blob/master/solr/contrib/analytics/src/test/org/apache/solr/analytics/facet/QueryFacetCloudTest.java#L44]
 which calls 
[`AbstractDistribZkTestBase.waitForRecoveriesToFinish`|https://github.com/apache/lucene-solr/blob/master/solr/contrib/analytics/src/test/org/apache/solr/analytics/facet/AbstractAnalyticsFacetCloudTest.java#L59].

I think after that call the cloud is ready for documents to be added.

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 55 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/55/

2 tests failed.
FAILED:  org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml

Error Message:
expected:<565> but was:<555>

Stack Trace:
java.lang.AssertionError: expected:<565> but was:<555>
at 
__randomizedtesting.SeedInfo.seed([A547C8A661FDED25:EA57150E3FBF448]: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.client.solrj.TestSolrJErrorHandling.doThreads(TestSolrJErrorHandling.java:185)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.doIt(TestSolrJErrorHandling.java:200)
at 
org.apache.solr.client.solrj.TestSolrJErrorHandling.testWithXml(TestSolrJErrorHandling.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Commented] (SOLR-10697) Improve defaults for maxConnectionsPerHost

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-10697:
--

Hi [~elyograg] [~markrmil...@gmail.com] ,

Any comments on this behaviour? 

I am inclined to remove {{HttpShardHandlerFactory#maxConnections}} ,  
{{HttpShardHandlerFactory#maxConnectionsPerHost}} and use 
{{HttpClientUtil.PROP_MAX_CONNECTIONS}} and 
{{HttpClientUtil.PROP_MAX_CONNECTIONS_PER_HOST}}



> Improve defaults for maxConnectionsPerHost
> --
>
> Key: SOLR-10697
> URL: https://issues.apache.org/jira/browse/SOLR-10697
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Minor
>
> Twice recently I've increased 
> {{HttpShardHandlerFactory#maxConnectionsPerHost}} at a client and it helped 
> improve query latencies a lot.
> Should we increase the default to say 100 ?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-10893) SolrClients used by streaming should support setting max connections

[Varun Thacker (JIRA)]

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

Varun Thacker closed SOLR-10893.

Resolution: Not A Problem

In 7.0 and master when we create a HttpSolrClient and CloudSolrClient without 
providing a default httpclient both max connections and max connections per 
host is set to 10k . This was not the case in the 6.x line of code though.


> SolrClients used by streaming should support setting max connections
> 
>
> Key: SOLR-10893
> URL: https://issues.apache.org/jira/browse/SOLR-10893
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>
> All the streaming expressions , SQL queries use a common SolrClientCache for 
> issuing the underlying queries. 
> Today we use a default HttpClient while creating this which means if we 
> running many parallel stream queries or deeply nested queries we can exhaust 
> this.
> We should allow users to set higher defaults for max connections, max 
> connections per route etc.
> Today since we use a default HttpClient does Streaming work with auth enabled 
> or in kerberos mode? I'll look into this and confirm.
> My idea is we could probably refactor in a way that CoreContainer keeps an 
> object of SolrClientCache which uses the httpclient that is currently used 
> for searches ( HttpShardHandlerFactory ) . This means we don't need to 
> introduce more settings . 
> Thoughts? Do we want to keep search threads and streaming threads part of 
> separate pools? 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10123:
-

i have no opinions -- i just wanted to make sure it didn't get lost in the 
shuffle.

FWIW: If the failure is coming from a cloud based test when trying to add the 
initial data, then a very likely possibility is that the main tests thread is 
trying to add docs before the all the nodes have fully come online ... many 
cloud tests use a helper method (waitForThingsToLevelOut i think?) to check for 
this first.

something to consider.

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

Hi [~ivera], I had a more detailed look a this patch.

I note that there is a symmetry difference between GeoConcavePolygon and 
GeoConvexPolygon that I don't understand.  GeoConcavePolygon has the following 
lazy-init'd member variable:

{code}
+  /** Convex polygon counter part used for bounding intersections. Lazy 
initialized */
+  protected GeoPolygon convexPolygon=null;
+
{code}

GeoConvexPolygon has no similar member variable.  Can you explain why one has 
the converse shape, and the other doesn't?  What is the code trying to do here?

I also worry a bit when a direct shape inversion is used, because points that 
are *on* a shape edge will be members of both the shape and its inverse.  That 
may not be what you want.

The tests look good so far, but you really want to consider adding a randomized 
test as well.  Have a look at extending some of the randomized Geo3d testing 
classes under spatial-extras to include testing intersections against polygons:

{code}
06/29/2017  01:39 PM10,420 Geo3dRptTest.java
06/29/2017  01:39 PM 9,563 Geo3dShapeRectRelationTestCase.java
04/17/2016  03:38 PM 3,418 
Geo3dShapeSphereModelRectRelationTest.java
04/05/2016  06:10 AM 6,144 Geo3dShapeWGS84ModelRectRelationTest.java
03/31/2016  08:08 PM10,239 RandomizedShapeTestCase.java
{code}



> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-11023:

Attachment: SOLR-11023.patch

step#0: refactor the init logic and xml parsing into an EnumMapping class.

I was initially thinking we could follow in the steps of CurrencyField and 
inject a new superclass above EnumField (which would default to points) and the 
(legacy) EnumField could subclass it and override as needed to use 
LegacyNumeric support where needed ... but the more i look at it the more of a 
pain in the ass that appears to be.

the problem being I suspect we'll really want the "new" field type to extend 
PointField (or maybe even IntPointField?) but we definitely don't want the 
legacy EnumField to transitively extend PointField.

Alternative that's occuring to me now: make the new field type work a *lot* 
like CurrencyField, where it wraps a concrete (int) fieldtype and delegates to 
for create/sort/etc -- only handling the int/string converstion before/after.  
then the legacy type just overrides what fieldtype that hidden inner field uses?

frankly... EnumField has enough weird little quirks about it, that since we 
_know_ we want to deprecate it and remove it in 8, I'm tempted to leave it 
alone as much as possible and take the "i feel dirty" hit of cut/pasting all 
the bits we do really need to keep into a new class that has nothing in common 
with it other then that they are both FieldTypes.

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: numeric-tries-to-points
> Attachments: SOLR-11023.patch
>
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11132) Refactor common getSortField logic in various FieldTypes

[Hoss Man (JIRA)]

Hoss Man created SOLR-11132:
---

 Summary: Refactor common getSortField logic in various FieldTypes
 Key: SOLR-11132
 URL: https://issues.apache.org/jira/browse/SOLR-11132
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Hoss Man
Assignee: Hoss Man


This pattern exists a lot w/ some minor fluxuations in copy/paste variation...

{code}
  @Override
  public SortField getSortField(SchemaField field, boolean top) {
field.checkSortability();

Object missingValue = null;
boolean sortMissingLast = field.sortMissingLast();
boolean sortMissingFirst = field.sortMissingFirst();

if (sortMissingLast) {
  missingValue = top ? SOMECLASS.MIN_VALUE : SOMECLASS.MAX_VALUE;
} else if (sortMissingFirst) {
  missingValue = top ? SOMECLASS.MAX_VALUE : SOMECLASS.MIN_VALUE;
}
SortField sf = new SortField(field.getName(), SortField.Type.SOMETYPE, top);
sf.setMissingValue(missingValue);
return sf;
  }
{code}

We should refactor it into a helper method along the lines of...

{code}
  @Override
  public static SortField getSortField(SchemaField field, boolean top, 
SortField.Type sortType, 
   Object missingLow, Object missingHigh) {

field.checkSortability();

Object missingValue = null;
boolean sortMissingLast = field.sortMissingLast();
boolean sortMissingFirst = field.sortMissingFirst();

if (sortMissingLast) {
  missingValue = top ? missingLow : missingHigh;
} else if (sortMissingFirst) {
  missingValue = top ? missingHigh : missingLow;
}
SortField sf = new SortField(field.getName(), sortType, top);
sf.setMissingValue(missingValue);
return sf;
  }
{code}

So it can be re-used via...


{code}
  @Override
  public SortField getSortField(SchemaField field, boolean top) {
return getSortField(field, top, SortField.Type.SOMETIME, 
SOMECLASS.MIN_VALUE, SOMECLASS.MAX_VALUE);
  }
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-7864) timeAllowed causing ClassCastException

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere updated SOLR-7864:
---
Attachment: SOLR-7864_extra.patch

Attaching an extra fix, for Solr 6.6.0, rediscovered in our code base ;)

Apply SOLR-7864 on July 7th, 2017, first, then the extra.

> timeAllowed causing ClassCastException
> --
>
> Key: SOLR-7864
> URL: https://issues.apache.org/jira/browse/SOLR-7864
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2
>Reporter: Markus Jelsma
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7864_extra.patch, SOLR-7864.patch, SOLR-7864.patch
>
>
> If timeAllowed kicks in, following exception is thrown and user gets HTTP 500.
> {code}
> 65219 [qtp2096057945-19] ERROR org.apache.solr.servlet.SolrDispatchFilter  [  
>  search] – null:java.lang.ClassCastException: 
> org.apache.solr.response.ResultContext cannot be cast to 
> org.apache.solr.common.SolrDocumentList
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:275)
> 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 
> 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: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(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-10835:
-
Attachment: SOLR-10835-fixtest.patch

I think this is a silly test bug, related to the fact that Tries deduplicate 
while Points don't. Here is a patch that fixes this particular seed. Will run 
the tests some times and commit if I see no more failures. 

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
>  Labels: numeric-tries-to-points
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10835-fixtest.patch, SOLR-10835.patch, 
> SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere commented on SOLR-7913:


One more note about the patch for Solr 6.6.0, that I just attached:

CloudMLTQParser contains the changes done in the patch for SOLR-8604.  If, for 
some strange reason, you don't want support for the "collection" parameter in 
MLT queries, just ignore in patch SOLR-7913 the changes to method 
CloudMLTQParser.getDocument(String,String), so that you keep the previous 
version, with just one parameter.

If you do want support for the "collection" parameter in MLT queries, then you 
need to apply SOLR-8604 too.

It's easier to weed out SOLR-8604 from SOLR-7913 than the reverse !

[~upayavira] : this patch is not as messy as the previous, I did not 
incorporate the useless layout changes.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-7913) Add stream.body support to MLT QParser

[Isabelle Giguere (JIRA)]

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

Isabelle Giguere updated SOLR-7913:
---
Attachment: SOLR-7913.patch

Patch SOLR-7913, updated to Solr 6.6.0.

Adding unit tests.

First 2 unit tests in CloudMLTQParserTest look scary, because the results are 
so different, between the MLT query with id, and the "equivalent" query with 
stream.body.

I tested locally, to compare results with Solr 5.4.1 + patch (in our product, 
currently) and Solr 6.6.0 + patch, and there is no important difference, when 
comparing results of MLT with stream.body between Solr versions.  That's the 
important thing for us... Your opinion may differ.

I'm actually more puzzled that SimpleMLTQParser retrieves exactly the same 
results with id, and with stream.body!  How does it know what document to 
remove?

One note about that weird "TODO" in RequestUtils : why not let the handler 
propagate the content-type it expects, if any, instead of trying to guess in 
the utility method?  I'm not sure exactly where/how to do that, and how much 
impact it would have.

> Add stream.body support to MLT QParser
> --
>
> Key: SOLR-7913
> URL: https://issues.apache.org/jira/browse/SOLR-7913
> Project: Solr
>  Issue Type: Improvement
>Reporter: Anshum Gupta
> Attachments: SOLR-7913.patch, SOLR-7913.patch, SOLR-7913.patch
>
>
> Continuing from 
> https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011.
> It'd be good to have stream.body be supported by the mlt qparser.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-5927) EnumField thinks DocValue support requires a default value or that the field be required

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-5927:
---
Attachment: SOLR-5927.patch

the code in question seems to have been fixed/removed by [~shalinmangar] in 
SOLR-5846 (see 059e5259c68287033b28588f85f1bf5fcdd3f991) but the 
fieldType+copyField permutations in {{schema-sorts.xml}} were left commented 
out with the citation pointing to this jira.

In the attached patch all i've done is uncomment them -- 
TestRandomCollapseQParserPlugin and all the the Cursor tests (which use this 
schema and expect to be able to sort on any field specified) all _seem_ to pass?





> EnumField thinks DocValue support requires a default value or that the field 
> be required
> 
>
> Key: SOLR-5927
> URL: https://issues.apache.org/jira/browse/SOLR-5927
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: SOLR-5927.patch
>
>
> {noformat}  
>   @Override
>   public void checkSchemaField(final SchemaField field) {
> if (field.hasDocValues() && !field.multiValued() && !(field.isRequired() 
> || field.getDefaultValue() != null)) {
>   throw new IllegalStateException("Field " + this + " has single-valued 
> doc values enabled, but has no default value and is not required");
> }
>   }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"

[JIRA]

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

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

[~ichattopadhyaya], [~ysee...@gmail.com], you did a lot of work related to this 
in SOLR-8082. Would you mind reviewing?

> DocValues range query behaves different than Trie/Point range queries for 
> Float/Double "Infinity"
> -
>
> Key: SOLR-11070
> URL: https://issues.apache.org/jira/browse/SOLR-11070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, 
> SOLR-11070.patch, SOLR-11070.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[JIRA]

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

Jan Høydahl commented on SOLR-10494:


So, any progress on this so we have a chance of getting it into 7.0.0? I don't 
have the chance to work on it the next 4 weeks :(

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11013) remove /v2/c alias in favour of /v2/collections only

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11013:
-
Component/s: v2 API

> remove /v2/c alias in favour of /v2/collections only
> 
>
> Key: SOLR-11013
> URL: https://issues.apache.org/jira/browse/SOLR-11013
> Project: Solr
>  Issue Type: Wish
>  Components: v2 API
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11013.patch
>
>
> (Perhaps this has already been considered previously elsewhere or on the 
> mailing list and I just missed it then and couldn't find it now, in which 
> case happy to withdraw this ticket.)
> Would like propose that {{/v2/c}} be removed in favour of {{/v2/collections}} 
> only:
> * there being two ways to do the same thing is potentially confusing
> * {{/v2/c}} is short but _c_ could stand not only for _collections_ but also 
> for _cores_ or _cluster_ or _config_ or _cloud_ etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10888) almost self-generating python script(s) to access V2 APIs

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10888:
-
Component/s: v2 API

> almost self-generating python script(s) to access V2 APIs
> -
>
> Key: SOLR-10888
> URL: https://issues.apache.org/jira/browse/SOLR-10888
> Project: Solr
>  Issue Type: New Feature
>  Components: v2 API
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-10888.patch
>
>
> The V2 API supports introspection and the results of such introspection(s) 
> can be used to automatically on-the-fly generate a (nested) 
> {{argparse.ArgumentParser}} in a python script and then to again 
> automatically transform the script arguments into a url and http call to the 
> V2 API.
> Illustrative patch and sample output to follow.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10407) v2 API introspect output: availableSubPaths should be sorted

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10407:
-
Component/s: v2 API

> v2 API introspect output: availableSubPaths should be sorted
> 
>
> Key: SOLR-10407
> URL: https://issues.apache.org/jira/browse/SOLR-10407
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Steve Rowe
>
> This makes it hard to find things, since you have to read through the whole 
> (possibly lengthy) list to find what you're looking for.
> E.g. after {{bin/solr start -e cloud -noprompt}}, {{curl 
> "http://localhost:8983/v2/c/gettingstarted/_introspect?indent=on"}} returns:
> {noformat}
> {
>   "spec":[ [...] ],
> [...]
>   "availableSubPaths":{
> "/c/gettingstarted/shards/{shard}":["DELETE",
>   "POST",
>   "GET"],
> "/c/gettingstarted/shards":["POST",
>   "GET"],
> "/c/gettingstarted/shards/{shard}/{replica}":["DELETE",
>   "GET"],
> "/c/gettingstarted/browse":["POST",
>   "GET"],
> "/c/gettingstarted/schema/fieldtypes/{name}":["GET"],
> "/c/gettingstarted/schema/name":["GET"],
> "/c/gettingstarted/config/requestDispatcher":["GET"],
> "/c/gettingstarted/schema/zkversion":["GET"],
> "/c/gettingstarted/config/znodeVersion":["GET"],
> "/c/gettingstarted/schema/uniquekey":["GET"],
> "/c/gettingstarted/schema/version":["GET"],
> "/c/gettingstarted/schema/dynamicfields/{name}":["GET"],
> "/c/gettingstarted/config/params":["POST",
>   "GET"],
> "/c/gettingstarted/schema/similarity":["GET"],
> "/c/gettingstarted/select":["POST",
>   "GET"],
> "/c/gettingstarted/schema/solrqueryparser":["GET"],
> "/c/gettingstarted/config":["POST",
>   "GET"],
> "/c/gettingstarted/schema":["POST",
>   "GET"],
> "/c/gettingstarted/config/overlay":["GET"],
> "/c/gettingstarted/config/query":["GET"],
> "/c/gettingstarted/config/jmx":["GET"],
> "/c/gettingstarted/export":["POST",
>   "GET"],
> "/c/gettingstarted/schema/dynamicfields":["GET"],
> "/c/gettingstarted/config/{plugin}":["GET"],
> "/c/gettingstarted/get":["GET"],
> "/c/gettingstarted/schema/fieldtypes":["GET"],
> "/c/gettingstarted/config/params/{params_set}":["GET"],
> "/c/gettingstarted/query":["POST",
>   "GET"],
> "/c/gettingstarted/schema/solrqueryparser/defaultoperator":["GET"],
> "/c/gettingstarted/schema/copyfields":["GET"],
> "/c/gettingstarted/schema/fields":["GET"],
> "/c/gettingstarted/schema/fields/{name}":["GET"],
> "/c/gettingstarted/admin/ping":["POST",
>   "GET"],
> "/c/gettingstarted/update/json/commands":["POST"],
> "/c/gettingstarted/update/xml":["POST"],
> "/c/gettingstarted/update/json":["POST"],
> "/c/gettingstarted/update/csv":["POST"],
> "/c/gettingstarted/update/bin":["POST"],
> "/c/gettingstarted/update":["POST"]}}
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11033) Move out multi language field and fieldType to a separate example

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11033:
-
Component/s: examples

> Move out multi language field and fieldType to a separate example 
> --
>
> Key: SOLR-11033
> URL: https://issues.apache.org/jira/browse/SOLR-11033
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Reporter: Varun Thacker
>
> The bulk of the schema file in the default configset has fieldType and 
> dynamic field definition for  different languages.  Based on the discussion 
> on SOLR-10967 if we move it to a separate config set and keep the default 
> configset english only then the size will be dramatically reduced and make 
> the schema file much more readable.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11047) Add ebeMultiply Stream Evaluator

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-11047:
-
Component/s: streaming expressions

> Add ebeMultiply Stream Evaluator
> 
>
> Key: SOLR-11047
> URL: https://issues.apache.org/jira/browse/SOLR-11047
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> The ebeMultiply Stream Evaluator will perform and element-by-element 
> multiplication of two arrays.
> {code}
> a = ebeMultiply(b, c)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Add "Streaming Expressions" to component(s) list in JIRA

[Cassandra Targett]

I'm +1 on this, so I added it. Sorry for the delay Susheel.

On Fri, Jun 23, 2017 at 3:31 PM, Susheel Kumar  wrote:
> While filing JIRA for streaming expressions, there is no such component to
> selelct.  Can we add "Streaming Expressions" to the components list.
>
> Thanks,
> Susheel

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

[jira] [Commented] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[JIRA]

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

Jan Høydahl commented on SOLR-11131:


I wrote the assertTool and added it to bin/solr but did not advertise it since 
it was a bit work in progress and mostly not an end-user tool but rather for 
script developers. I'm happy to have more eyes on the code and make it official 
:)

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch, SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10410) /v2/_introspect doesn't work

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10410.
---
   Resolution: Fixed
Fix Version/s: 6.7
   7.0

> /v2/_introspect doesn't work
> 
>
> Key: SOLR-10410
> URL: https://issues.apache.org/jira/browse/SOLR-10410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Affects Versions: 6.5
>Reporter: Steve Rowe
>Priority: Minor
> Fix For: 7.0, 6.7
>
>
> I think it should be possible to get v2 API introspect output from the 
> top-level, i.e. at {{/v2/_introspect}}.
> After {{bin/solr start -e cloud -noprompt}}, {{curl 
> http://localhost:8983/v2/_introspect}} returns:
> {noformat}
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10410) /v2/_introspect doesn't work

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10410:
---

bq. Besides the URL being out of date, is this sufficient?

+1.

Once people start trying to use the v2 API more, it may become more clear 
whether more info should go here, and at that point we can revisit.

> /v2/_introspect doesn't work
> 
>
> Key: SOLR-10410
> URL: https://issues.apache.org/jira/browse/SOLR-10410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Affects Versions: 6.5
>Reporter: Steve Rowe
>Priority: Minor
>
> I think it should be possible to get v2 API introspect output from the 
> top-level, i.e. at {{/v2/_introspect}}.
> After {{bin/solr start -e cloud -noprompt}}, {{curl 
> http://localhost:8983/v2/_introspect}} returns:
> {noformat}
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-10433) automatically map collection admin calls from V1 to V2

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-10433.
---
   Resolution: Fixed
 Assignee: Noble Paul
Fix Version/s: 7.0

> automatically map collection admin calls from V1 to V2
> --
>
> Key: SOLR-10433
> URL: https://issues.apache.org/jira/browse/SOLR-10433
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, v2 API
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.0
>
> Attachments: SOLR-10433.patch, SOLR-10433.patch, SOLR-10433.patch, 
> SOLR-10433.patch, SOLR-10433.patch
>
>
> There are some bugs in v2 api that I would like to solve in other tickets :
> - DELETE method doest not support body ( we can't pass async id )
> - V2HttpCall should {{override getAuthCtx()}} to support 
> {{RuleBasedAuthorizationPlugin}}
> - with create collection, when user send this request
> {code}
> {
> "properties" : {"solr.tests.maxBufferedDocs" : 100}
> }
> {code}
> the v2 api can not resolve the value for 
> "properties.solr.tests.maxBufferedDocs"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-10123:


In my opinion this ticket is done and can be marked as such. The feature is in. 
I'm not convinced that the test failure above ([~steve_rowe]) is related. And, 
while additional tests would be nice, I believe they should be added under 
another ticket all together.

[~hossman], what are your thoughts on me closing this ticket?

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10494) Switch Solr's Default Response Type from XML to JSON

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10494:
-
Component/s: Response Writers

> Switch Solr's Default Response Type from XML to JSON
> 
>
> Key: SOLR-10494
> URL: https://issues.apache.org/jira/browse/SOLR-10494
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Response Writers
>Affects Versions: 7.0
>Reporter: Trey Grainger
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10494, SOLR-10494, SOLR-10494.patch, 
> SOLR-10494-withdocs.patch, SOLR-10494-withdocs.patch
>
>
> Solr's default response format is still XML, despite the fact that Solr has 
> supported the JSON response format for over a decade, developer mindshare has 
> clearly shifted toward JSON over the years, and most modern/competing systems 
> also use JSON format now by default.
> In fact, Solr's admin UI even explicitly adds wt=json to the request (by 
> default in the UI) to override the default of wt=xml, so Solr's Admin UI 
> effectively has a different default than the API.
> We have now introduced things like the JSON faceting API, and the new more 
> modern /V2 apis assume JSON for the areas of Solr they cover, so clearly 
> we're moving in the direction of JSON anyway.
> I'd like propose that we switch the default response writer to JSON (wt=json) 
> instead of XML for Solr 7.0, as this seems to me like the right direction and 
> a good time to make this change with the next major version.
> Based upon feedback from the Lucene Dev's mailing list, we want to:
> 1) Change the default response writer type to "wt=json" and also change to 
> "indent=on" by default
> 2) Make no changes on the update handler side; it already works as desired 
> (it returns the response in the same content-type as the request unless the 
> "wt" is passed in explicitly).
> 3) Keep the /query request handler around since people have already used it 
> for years to do JSON queries
> 4) Add a commented-out "wt=xml" to the solrconfig.xml as a reminder for folks 
> on how to change (back) the response format.
> The default format change, plus the addition of "indent=on" are back compat 
> changes, so we need to make sure we doc those clearly in the CHANGES.txt. 
> There will also need to be significant adjustments to the Solr Ref Guide, 
> Tutorial, etc.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-10410) /v2/_introspect doesn't work

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-10410 at 7/20/17 7:31 PM:
---

As of SOLR-10715, this now returns:

{code}
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"documentation": 
"https://cwiki.apache.org/confluence/display/solr/v2+API;,
"description": "V2 API root path"
}
{code}

Besides the URL being out of date, is this sufficient?


was (Author: ctargett):
As of SOLR-10715, this now outputs:

{code}
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"documentation": 
"https://cwiki.apache.org/confluence/display/solr/v2+API;,
"description": "V2 API root path"
}
{code}

Besides the URL being out of date, is this sufficient?

> /v2/_introspect doesn't work
> 
>
> Key: SOLR-10410
> URL: https://issues.apache.org/jira/browse/SOLR-10410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Affects Versions: 6.5
>Reporter: Steve Rowe
>Priority: Minor
>
> I think it should be possible to get v2 API introspect output from the 
> top-level, i.e. at {{/v2/_introspect}}.
> After {{bin/solr start -e cloud -noprompt}}, {{curl 
> http://localhost:8983/v2/_introspect}} returns:
> {noformat}
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10410) /v2/_introspect doesn't work

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10410:
--

As of SOLR-10715, this now outputs:

{code}
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"documentation": 
"https://cwiki.apache.org/confluence/display/solr/v2+API;,
"description": "V2 API root path"
}
{code}

Besides the URL being out of date, is this sufficient?

> /v2/_introspect doesn't work
> 
>
> Key: SOLR-10410
> URL: https://issues.apache.org/jira/browse/SOLR-10410
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Affects Versions: 6.5
>Reporter: Steve Rowe
>Priority: Minor
>
> I think it should be possible to get v2 API introspect output from the 
> top-level, i.e. at {{/v2/_introspect}}.
> After {{bin/solr start -e cloud -noprompt}}, {{curl 
> http://localhost:8983/v2/_introspect}} returns:
> {noformat}
> 
> 
> 
> Error 404 Not Found
> 
> HTTP ERROR 404
> Problem accessing /solr/v2/_introspect. Reason:
> Not Found
> 
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10848) V2 API _introspect should point to the new reference guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10848:
--

I assigned this to myself & then thought better of it because while I could 
update all the links in specs to point to a generic URL for documentation that 
would redirect to the latest version, I don't know how to modify the specs 
themselves to dynamically insert the proper version (at build time I guess?) so 
the links point to the right version of docs.

If we're OK with these links going to a generic URL that will always take the 
user to the _latest_ docs, I can do that.

> V2 API _introspect should point to the new reference guide
> --
>
> Key: SOLR-10848
> URL: https://issues.apache.org/jira/browse/SOLR-10848
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, v2 API
>Reporter: Tomás Fernández Löbbe
> Fix For: 7.0
>
>
> It would be nice if we can point to the specific version of the documentation 
> for this particular version of Solr



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10848) V2 API _introspect should point to the new reference guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-10848:


Assignee: (was: Cassandra Targett)

> V2 API _introspect should point to the new reference guide
> --
>
> Key: SOLR-10848
> URL: https://issues.apache.org/jira/browse/SOLR-10848
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, v2 API
>Reporter: Tomás Fernández Löbbe
> Fix For: 7.0
>
>
> It would be nice if we can point to the specific version of the documentation 
> for this particular version of Solr



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10848) V2 API _introspect should point to the new reference guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-10848:
-
Component/s: documentation

> V2 API _introspect should point to the new reference guide
> --
>
> Key: SOLR-10848
> URL: https://issues.apache.org/jira/browse/SOLR-10848
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, v2 API
>Reporter: Tomás Fernández Löbbe
> Fix For: 7.0
>
>
> It would be nice if we can point to the specific version of the documentation 
> for this particular version of Solr



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10848) V2 API _introspect should point to the new reference guide

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-10848:


Assignee: Cassandra Targett

> V2 API _introspect should point to the new reference guide
> --
>
> Key: SOLR-10848
> URL: https://issues.apache.org/jira/browse/SOLR-10848
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, v2 API
>Reporter: Tomás Fernández Löbbe
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> It would be nice if we can point to the specific version of the documentation 
> for this particular version of Solr



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Houston Putman (JIRA)]

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

Houston Putman commented on SOLR-10123:
---

[~hossman] and [~steve_rowe],

I've been trying to reproduce this failure using the test command given above 
but I can't. I also can't really solve it without reproduction, because it 
seems like the error has nothing to do with the analytics component. The error 
comes from filling a test collection with data before running analytics on that 
data. If the test fails because of this, it stands to reason that a lot of 
other tests would also fail for similar reasons. Especially the other analytics 
tests. I think this was a one-off failure that didn't have to do with the 
analytics component.

On a side note, I have a lot of new tests I can push out sometime next week 
that will provide a lot assurance that the component is "done". 

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-7312) "REST" API is not REST

[Cassandra Targett (JIRA)]

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

Cassandra Targett updated SOLR-7312:

Component/s: documentation

> "REST" API is not REST
> --
>
> Key: SOLR-7312
> URL: https://issues.apache.org/jira/browse/SOLR-7312
> Project: Solr
>  Issue Type: Improvement
>  Components: documentation, Server
>Affects Versions: 5.0
>Reporter: Mark Haase
>Assignee: Noble Paul
>
> The documentation refers to a "REST" API over and over, and yet I don't see a 
> REST API. I see an HTTP API but not a REST API. Here are a few things the 
> HTTP API does that are not RESTful:
> * Offers RPC verbs instead of resources/nouns. (E.g. schema API has commands 
> like "add-field", "add-copy-field", etc.)
> * Tunnels non-idempotent requests (like creating a core) through idempotent 
> HTTP verb (GET).
> * Tunnels deletes through HTTP GET.
> * PUT/POST confusion, POST used to update a named resource, such as the Blob 
> API.
> * Returns `200 OK` HTTP code even when the command fails. (Try adding a field 
> to your schema that already exists. You get `200 OK` and an error message 
> hidden in the payload. Try calling a collections API when you're using 
> non-cloud mode: `200 OK` and an error message in the payload. Gah.)
> * Does not provide link relations.
> * HTTP status line contains a JSON payload (!) and no 'Content-Type' header 
> for some failed commands, like `curl -X DELETE 
> http://solr:8983/solr/admin/cores/foo`
> * Content negotiation is done via query parameter (`wt=json`), instead of 
> `Accept` header.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (64bit/jdk1.8.0_131) - Build # 55 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/55/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestPullReplica.testKillLeader

Error Message:
Replica state not updated in cluster state null Live Nodes: 
[127.0.0.1:33129_solr, 127.0.0.1:32903_solr] Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
   "pullReplicas":"1",   "replicationFactor":"1",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   
"core":"pull_replica_test_kill_leader_shard1_replica_n1",   
"base_url":"http://127.0.0.1:32903/solr;,   
"node_name":"127.0.0.1:32903_solr",   "state":"down",   
"type":"NRT",   "leader":"true"}, "core_node2":{   
"core":"pull_replica_test_kill_leader_shard1_replica_p1",   
"base_url":"http://127.0.0.1:33129/solr;,   
"node_name":"127.0.0.1:33129_solr",   "state":"active",   
"type":"PULL",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"100",   "autoAddReplicas":"false",   "nrtReplicas":"1",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: Replica state not updated in cluster state
null
Live Nodes: [127.0.0.1:33129_solr, 127.0.0.1:32903_solr]
Last available state: 
DocCollection(pull_replica_test_kill_leader//collections/pull_replica_test_kill_leader/state.json/6)={
  "pullReplicas":"1",
  "replicationFactor":"1",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"pull_replica_test_kill_leader_shard1_replica_n1",
  "base_url":"http://127.0.0.1:32903/solr;,
  "node_name":"127.0.0.1:32903_solr",
  "state":"down",
  "type":"NRT",
  "leader":"true"},
"core_node2":{
  "core":"pull_replica_test_kill_leader_shard1_replica_p1",
  "base_url":"http://127.0.0.1:33129/solr;,
  "node_name":"127.0.0.1:33129_solr",
  "state":"active",
  "type":"PULL",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"100",
  "autoAddReplicas":"false",
  "nrtReplicas":"1",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([16AE97088DDDCF06:5FB863BCEF665B50]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:269)
at 
org.apache.solr.cloud.TestPullReplica.doTestNoLeader(TestPullReplica.java:401)
at 
org.apache.solr.cloud.TestPullReplica.testKillLeader(TestPullReplica.java:290)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 

[jira] [Assigned] (SOLR-11023) Need SortedNumerics/Points version of EnumField

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-11023:
---

Assignee: Hoss Man

I'm going to start working on this, but i'm still unclear if "points" is the 
best way to go for the "very low cardinality + all values are small positive 
ints" situation.

[~mikemccand] & [~jpountz]: In terms of disk usage/search performance do you 
have any sense of what makes more sense for enum type usecases?  using (int) 
dimensional Points vs just using simple indexed terms Terms?  (I frankly don't 
understand the points "encoding" and segment merging costs well enough to make 
any educated assumptions)

> Need SortedNumerics/Points version of EnumField
> ---
>
> Key: SOLR-11023
> URL: https://issues.apache.org/jira/browse/SOLR-11023
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: numeric-tries-to-points
>
> although it's not a subclass of TrieField, EnumField does use 
> "LegacyIntField" to index the int value associated with each of the enum 
> values, in addition to using SortedSetDocValuesField when {{docValues="true" 
> multivalued="true"}}.
> I have no idea if Points would be better/worse then Terms for low cardinality 
> usecases like EnumField, but either way we should think about a new variant 
> of EnumField that doesn't depend on 
> LegacyIntField/LegacyNumericUtils.intToPrefixCoded and uses 
> SortedNumericDocValues.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([A6C3DE6D385B1AF1:1C11B115BB75F4E4]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:353)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more




Build Log:
[...truncated 11812 lines...]
   [junit4] Suite: 

[jira] [Commented] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-11131:
---

[~anshumg]

Anshum: I only assigned it to myself to not lose track of it. There's no chance 
I'll be able to get to it before tomorrow and perhaps this weekend. So please 
take it.

Erick

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch, SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Jason Gerlowski (JIRA)]

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

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

I've made the corresponding change to bin/solr.cmd as Anshum suggested, and I 
took a stab at a small ref-guide section for {{assert}} as well.  I'd view the 
ref-guide section skeptically, but it's at least something to build off of if 
people don't like it.

Tests and precommit pass.

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch, SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 54 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/54/

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testMaxTime

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([117A45E6A0C262F6:8B8E38043E58FECA]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testMaxTime(AutoCommitTest.java:270)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more


FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 

[jira] [Updated] (SOLR-11070) DocValues range query behaves different than Trie/Point range queries for Float/Double "Infinity"

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11070:
-
Attachment: SOLR-11070.patch

Cleanup test. Beasted random test and saw no failures

> DocValues range query behaves different than Trie/Point range queries for 
> Float/Double "Infinity"
> -
>
> Key: SOLR-11070
> URL: https://issues.apache.org/jira/browse/SOLR-11070
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-11070.patch, SOLR-11070.patch, SOLR-11070.patch, 
> SOLR-11070.patch, SOLR-11070.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[JIRA]

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

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

Yes, sorry I didn't respond earlier. I'll take a look

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10338:


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

SOLR-10338: Fix CHANGES entry


> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_131) - Build # 112 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/112/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 13289 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/temp/junit4-J0-20170720_165906_7792816925507350289421.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/heapdumps/java_pid22246.hprof ...
   [junit4] Heap dump file created [335493037 bytes in 0.563 secs]
   [junit4] <<< JVM J0: EOF 

[...truncated 7529 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:810: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:762: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid22246.hprof

Total time: 66 minutes 14 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10338:


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

SOLR-10338: Configure SecureRandom non blocking for tests.


> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-10123) Analytics Component 2.0

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-10123:
---

Assignee: Dennis Gove
Priority: Blocker  (was: Major)

setting as blocker since this issue is still listed as "open" but work has 
already been committed to the 7.0 branch but: 1) it's not clear if this feature 
is considered "done"; 2) the new tests have some concerning test failures as 
noted by sarowe.

[~dpgove] can you please assess the state of this issue? (and the linked 
SOLR-10949)

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>Assignee: Dennis Gove
>Priority: Blocker
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-10949) analytics component has hard coded assumptions about Trie numeric fields -- tests fail with randomized point fields

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10949:
-

i _think_ this is being addressed as part of SOLR-10123?

> analytics component has hard coded assumptions about Trie numeric fields -- 
> tests fail with randomized point fields
> ---
>
> Key: SOLR-10949
> URL: https://issues.apache.org/jira/browse/SOLR-10949
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>
> Found as part of SOLR-10947... attempting to use numeric PointFields in 
> contrib/analytics tests cause problems in some tests due to classes like 
> StatsCollectorSupplierFactory, RangeEndpointCalculator, and AnalyticsParsers 
> having hard coded assumptions about using Trie based numeric fields (via 
> instanceof and clas equality checks)
> (It's not immediately obvious if replacing these checks with inspection of 
> {{FieldType.getNumberType()}} would solve all the problems, or if other 
> assumptions are made down stream in the code)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-10835) ExportWriter only works with TrieFooFields, not FooPointFields

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10835:

Priority: Blocker  (was: Major)

setting as blocker since the test failures now leave this "fix" in an amorphous 
state for the purposes of tracking against 7.0

[~tomasflobbe]: can you please dig in and figure out if these test failures 
represent a failure in the code added as part of this issue that should also be 
resolved as part of this issue, or a test bug introduced by this issue that can 
be fixedup easily, or a distinct previously unknown bug that was surfaced by 
your increased test coverage that should be tracked/prioritized in it's own new 
jira?

> ExportWriter only works with TrieFooFields, not FooPointFields
> --
>
> Key: SOLR-10835
> URL: https://issues.apache.org/jira/browse/SOLR-10835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Tomás Fernández Löbbe
>Priority: Blocker
> Fix For: 7.0, 6.7
>
> Attachments: SOLR-10835.patch, SOLR-10835.patch, SOLR-10835.patch
>
>
> ExportWriter explicitly fails hard if you attempt to use it with any of the 
> new Numeric Points based fields.
> The current failures come from explicit {{if (fieldType instanceof 
> TrieFooField)}} checks in {{ExportWriter.getFieldWriters}} -- those could 
> probably be replaced with {{instanceof FooValueFieldType}} (the numeric 
> marker interfaces) or {{getNumericType()}} but i suspect in the multivalued 
> case other problems will arise due to how ExportWriter dips into the guts of 
> DocValues and assumes SortedSetDocValues 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 57 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/57/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([25C80F0FBFFDE041:8DFE91D2209C0B1B]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1139)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:822)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-11131:
-

[~gerlowskija] can you also add this to solr.cmd ?

[~erickerickson] I didn't realize you've assigned this to yourself. If you are 
done with running the tests and want to go ahead and commit this, please go 
ahead.

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11131:
--

Also this was never added to the Ref Guide, not sure why, but for completeness 
sake it probably should be.

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Erick Erickson (JIRA)]

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

Erick Erickson reassigned SOLR-11131:
-

Assignee: Erick Erickson

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-11131:
-

I'll run the tests and commit this. Thanks [~gerlowskija]

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Assignee: Erick Erickson
>Priority: Trivial
> Attachments: SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Jason Gerlowski (JIRA)]

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

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

This is so trivial I almost feel it's not worth the JIRA mailing list noise it 
generates, but I was worried it'd get forgotten about otherwise, and the tool 
looks useful for people to know about.

Attached patch amends the help text.  Tests and precommit pass.

> bin/solr help doesn't mention "assert" as a COMMAND option
> --
>
> Key: SOLR-11131
> URL: https://issues.apache.org/jira/browse/SOLR-11131
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-compliant environment.
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11131.patch
>
>
> The root help/usage text for {{bin/solr}} looks like:
> {noformat}
> [~/c/l/solr] $ bin/solr
> Usage: solr COMMAND OPTIONS
>where COMMAND is one of: start, stop, restart, status, healthcheck, 
> create, create_core, create_collection, delete, version, zk, auth
>   Standalone server example (start Solr running in the background on port 
> 8984):
> ./solr start -p 8984
>   SolrCloud example (start Solr running in SolrCloud mode using 
> localhost:2181 to connect to Zookeeper, with 1g max heap size and remote Java 
> debug options enabled):
> ./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
> -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"
> Pass -help after any COMMAND to see command-specific usage information,
>   such as:./solr start -help or ./solr stop -help
> {noformat}
> The list of valid commands near the top leaves off {{assert}}, a tool created 
> back in SOLR-9610
> The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11131) bin/solr help doesn't mention "assert" as a COMMAND option

[Jason Gerlowski (JIRA)]

Jason Gerlowski created SOLR-11131:
--

 Summary: bin/solr help doesn't mention "assert" as a COMMAND option
 Key: SOLR-11131
 URL: https://issues.apache.org/jira/browse/SOLR-11131
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: scripts and tools
Affects Versions: master (8.0)
 Environment: Any POSIX-compliant environment.
Reporter: Jason Gerlowski
Priority: Trivial


The root help/usage text for {{bin/solr}} looks like:

{noformat}
[~/c/l/solr] $ bin/solr

Usage: solr COMMAND OPTIONS
   where COMMAND is one of: start, stop, restart, status, healthcheck, 
create, create_core, create_collection, delete, version, zk, auth

  Standalone server example (start Solr running in the background on port 8984):

./solr start -p 8984

  SolrCloud example (start Solr running in SolrCloud mode using localhost:2181 
to connect to Zookeeper, with 1g max heap size and remote Java debug options 
enabled):

./solr start -c -m 1g -z localhost:2181 -a "-Xdebug 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044"

Pass -help after any COMMAND to see command-specific usage information,
  such as:./solr start -help or ./solr stop -help
{noformat}

The list of valid commands near the top leaves off {{assert}}, a tool created 
back in SOLR-9610

The usage text should be amended to include assert in the list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Apache Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:40457/aip/w/control_collection: Expected 
mime type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/aip/w/control_collection/update. Reason: Can not find: 
/aip/w/control_collection/update http://eclipse.org/jetty;>Powered by Jetty:// 9.3.14.v20161028 
  

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


Error 404 


HTTP ERROR: 404
Problem accessing /aip/w/control_collection/update. Reason:
Can not find: /aip/w/control_collection/update
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:588)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1580)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:656)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-11002) Error while posting data

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11002:
-

It would be better to ask this in solr-users mailing list to get more audience 
to help you out. Open a JIRA only when there's something actionable or we have 
specific insights on what is going wrong.

http://lucene.apache.org/solr/community.html

With the looks of it, it looks like some of the nodes are down. Also you opened 
the JIRA under solrj sub category so insights into the client code you are 
running will be helpful too.

> Error while posting data
> 
>
> Key: SOLR-11002
> URL: https://issues.apache.org/jira/browse/SOLR-11002
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.2
> Environment: linux redhat 7, solr 6.2
>Reporter: Naveen Kumar Gundala
> Fix For: 6.2.2
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> we regularly go exception while we running solrj jobs , coluld you please 
> help me to resolve this.
> 2017-06-30 17:51:19.985 ERROR (qtp2012232625-241329) [c:mbrdaily s:shard12 
> r:core_node18 x:mbrdaily_shard12_replica1] o.a.s.h.RequestHandlerBase 
> org.apache.solr.common.SolrException: Invalid Number:
> BCC:u...@nribv5mhrrxuxztht34ek6ztnkteh6au1kojc8.burpcollaborator.net
> edm: a
> at 
> org.apache.solr.schema.TrieField.readableToIndexed(TrieField.java:537)
> at org.apache.solr.schema.FieldType.getFieldQuery(FieldType.java:753)
> at org.apache.solr.schema.TrieField.getFieldQuery(TrieField.java:496)
> at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:737)
> at 
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:385)
> at 
> org.apache.solr.parser.SolrQueryParserBase.handleQuotedTerm(SolrQueryParserBase.java:544)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:419)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:186)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:140)
> at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:153)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:50)
> at org.apache.solr.search.QParser.getQuery(QParser.java:141)
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:162)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:267)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:156)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2036)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:657)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:464)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at 
> 

[jira] [Comment Edited] (SOLR-7105) Running Solr as a windows service

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-7105 at 7/20/17 3:40 PM:
-

bq. Any problems with using nssm over Commons Dameon? I'm not familiar with the 
latter.

Without naming names, I am aware of at least one company (which uses Solr) that 
prohibits the use of NSSM in its products / solutions because they don't want 
to be associated with something that advertises itself with the words "nssm is 
a service helper which doesn't suck. srvany and other service helper programs 
suck...".

Whether or not other companies would have a similar issue with NSSM, I cannot 
say, but Commons Daemon doesn't have that issue and is widely used and fairly 
straightforward once you get going with it.


was (Author: cjcowie):
bq. Any problems with using nssm over Commons Dameon? I'm not familiar with the 
latter.

Without naming names, I am aware of at least one company that prohibits the use 
of NSSM in its products / solutions because they don't want to be associated 
with something that advertises itself with the words "nssm is a service helper 
which doesn't suck. srvany and other service helper programs suck...".

Whether or not other companies would have a similar issue with NSSM, I cannot 
say, but Commons Daemon doesn't have that issue and is widely used and fairly 
straightforward once you get going with it.

> Running Solr as a windows service
> -
>
> Key: SOLR-7105
> URL: https://issues.apache.org/jira/browse/SOLR-7105
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
> Fix For: 7.0
>
>
> Since we moved away from shipping a war, it's useful to have scripts to start 
> Solr as a service.
> In 5.0 we already added a script for unix systems, we should also add one for 
> windows.
> The Commons Daemon project seems like a good way to implement it - 
> http://commons.apache.org/proper/commons-daemon/procrun.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-7105) Running Solr as a windows service

[Colvin Cowie (JIRA)]

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

Colvin Cowie edited comment on SOLR-7105 at 7/20/17 3:38 PM:
-

bq. Any problems with using nssm over Commons Dameon? I'm not familiar with the 
latter.

Without naming names, I am aware of at least one company that prohibits the use 
of NSSM in its products / solutions because they don't want to be associated 
with something that advertises itself with the words "nssm is a service helper 
which doesn't suck. srvany and other service helper programs suck...".

Whether or not other companies would have a similar issue with NSSM, I cannot 
say, but Commons Daemon doesn't have that issue and is widely used and fairly 
straightforward once you get going with it.


was (Author: cjcowie):
bq. Any problems with using nssm over Commons Dameon? I'm not familiar with the 
latter.

Without naming names, I am aware of at least one company that prohibits the use 
of NSSM in its products / solutions because they don't want to be using 
something that advertises itself with the words "nssm is a service helper which 
doesn't suck. srvany and other service helper programs suck...".

Whether or not other companies would have a similar issue with NSSM, I cannot 
say, but Commons Daemon doesn't have that issue and is widely used and fairly 
straightforward once you get going with it.

> Running Solr as a windows service
> -
>
> Key: SOLR-7105
> URL: https://issues.apache.org/jira/browse/SOLR-7105
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
> Fix For: 7.0
>
>
> Since we moved away from shipping a war, it's useful to have scripts to start 
> Solr as a service.
> In 5.0 we already added a script for unix systems, we should also add one for 
> windows.
> The Commons Daemon project seems like a good way to implement it - 
> http://commons.apache.org/proper/commons-daemon/procrun.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7105) Running Solr as a windows service

[Colvin Cowie (JIRA)]

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

Colvin Cowie commented on SOLR-7105:


bq. Any problems with using nssm over Commons Dameon? I'm not familiar with the 
latter.

Without naming names, I am aware of at least one company that prohibits the use 
of NSSM in its products / solutions because they don't want to be using 
something that advertises itself with the words "nssm is a service helper which 
doesn't suck. srvany and other service helper programs suck...".

Whether or not other companies would have a similar issue with NSSM, I cannot 
say, but Commons Daemon doesn't have that issue and is widely used and fairly 
straightforward once you get going with it.

> Running Solr as a windows service
> -
>
> Key: SOLR-7105
> URL: https://issues.apache.org/jira/browse/SOLR-7105
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
> Fix For: 7.0
>
>
> Since we moved away from shipping a war, it's useful to have scripts to start 
> Solr as a service.
> In 5.0 we already added a script for unix systems, we should also add one for 
> windows.
> The Commons Daemon project seems like a good way to implement it - 
> http://commons.apache.org/proper/commons-daemon/procrun.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Windows (64bit/jdk1.8.0_131) - Build # 30 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Windows/30/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.TestTlogReplica

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore, 
MockDirectoryWrapper] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:478)  
at org.apache.solr.core.SolrCore.(SolrCore.java:928)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:969)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:904)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:91)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:384)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:389)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:174)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
  at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:745)  
at 
org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:726)  
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:507)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:139)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1699)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:395)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134) 
 at org.eclipse.jetty.server.Server.handle(Server.java:534)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:202)  at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
  at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)  at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) 
 at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
  at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:349)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:709)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:934)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:843)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:969)  at 
org.apache.solr.core.CoreContainer.create(CoreContainer.java:904)  at 

[jira] [Updated] (SOLR-10665) POC for a PF4J based plugin system

[JIRA]

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

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

Attaching a patch of current POC state. Don't mind the patch size, this is not 
meant for commit but for producing a runnable proof of concept.

I have also produced a "release" tarball for easier consumption, see design 
[doc appendix 
A|https://docs.google.com/document/d/1567P8EaLqzmKdtEMu5NVv9Tty_feihGUcnit6TM5V3A/edit#heading=h.c373ixkvhajg]
{noformat}
curl -O http://people.apache.org/~janhoy/dist/solr-8.0.0-SNAPSHOT.tgz
tar -xvzf solr-8.0.0-SNAPSHOT.tgz
cd solr-8.0.0-SNAPSHOT
bin/solr start
bin/solr create -c test
bin/post -c test example/exampledocs/*.xml
curl -s http://localhost:8983/solr/test/browse | grep ClassNotFoundException
bin/solr plugin search vel
bin/solr plugin install velocity
bin/solr restart
curl -s http://localhost:8983/solr/test/browse | grep ClassNotFoundException
curl -s http://localhost:8983/solr/test/browse | grep "Solr Admin"
{noformat}

Enjoy :)

> POC for a PF4J based plugin system
> --
>
> Key: SOLR-10665
> URL: https://issues.apache.org/jira/browse/SOLR-10665
> Project: Solr
>  Issue Type: New Feature
>  Components: Plugin system
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: pf4j, plugins
> Fix For: master (8.0)
>
> Attachments: SOLR-10665.patch
>
>
> In SOLR-5103 we have been discussing improvements to Solr plugin system, with 
> ability to bundle a plugin as zip, and easily install from shell or Admin UI.
> This task aims to create a working POC to demonstrate how PF4J (Plugin 
> Framework4J) can be used to bring a very simple plugin packaging and 
> installation system to Solr with a minimum of effort. Code speaks louder than 
> words :)
> The POC effort is a quite large patch and will be cutting some corners to get 
> the feature in the hands of people who can test and evaluate. If there is 
> consensus to add this to Solr, there will be other sub tasks to split up the 
> elephant into committable chunks.
> The design document is located here: https://s.apache.org/solr-plugin (Google 
> Doc) - comments are welcome in the document or here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (64bit/jdk1.8.0_131) - Build # 54 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/54/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<1000>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1000>
at 
__randomizedtesting.SeedInfo.seed([92D316DF116F1590:4B85471B120B06DA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithSourceCluster(CdcrBootstrapTest.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 11001 lines...]
   [junit4] Suite: 

[jira] [Updated] (SOLR-10665) POC for a PF4J based plugin system

[JIRA]

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

Jan Høydahl updated SOLR-10665:
---
Description: 
In SOLR-5103 we have been discussing improvements to Solr plugin system, with 
ability to bundle a plugin as zip, and easily install from shell or Admin UI.

This task aims to create a working POC to demonstrate how PF4J (Plugin 
Framework4J) can be used to bring a very simple plugin packaging and 
installation system to Solr with a minimum of effort. Code speaks louder than 
words :)

The POC effort is a quite large patch and will be cutting some corners to get 
the feature in the hands of people who can test and evaluate. If there is 
consensus to add this to Solr, there will be other sub tasks to split up the 
elephant into committable chunks.

The design document is located here: https://s.apache.org/solr-plugin (Google 
Doc) - comments are welcome in the document or here.

  was:
In SOLR-5103 we have been discussing improvements to Solr plugin system, with 
ability to bundle a plugin as zip, and easily install from shell or Admin UI.

This first sub task aims to create a working POC to demonstrate how PF4J can be 
used to bring a very simple plugin packaging and installation system to Solr 
with a minimum of effort. Code speaks louder than words :)

The POC effort will be a quite large patch and will be cutting some corners to 
get the feature in the hands of people who can test and evaluate. If there is 
consensus to add this to Solr, there will be other sub tasks to split up the 
elephant into committable chunks.


> POC for a PF4J based plugin system
> --
>
> Key: SOLR-10665
> URL: https://issues.apache.org/jira/browse/SOLR-10665
> Project: Solr
>  Issue Type: New Feature
>  Components: Plugin system
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: pf4j, plugins
> Fix For: master (8.0)
>
>
> In SOLR-5103 we have been discussing improvements to Solr plugin system, with 
> ability to bundle a plugin as zip, and easily install from shell or Admin UI.
> This task aims to create a working POC to demonstrate how PF4J (Plugin 
> Framework4J) can be used to bring a very simple plugin packaging and 
> installation system to Solr with a minimum of effort. Code speaks louder than 
> words :)
> The POC effort is a quite large patch and will be cutting some corners to get 
> the feature in the hands of people who can test and evaluate. If there is 
> consensus to add this to Solr, there will be other sub tasks to split up the 
> elephant into committable chunks.
> The design document is located here: https://s.apache.org/solr-plugin (Google 
> Doc) - comments are welcome in the document or here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: (was: LUCENE-7906.patch)

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: LUCENE-7906.patch

Move the getRelationship method down to the GeoBasePolygon. 

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-9555) Leader incorrectly publishes state for replica when it puts replica into LIR.

[Mano Kovacs (JIRA)]

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

Mano Kovacs updated SOLR-9555:
--
Attachment: lir-9555-problem.png

Attaching explanation diagram of the first problem.

> Leader incorrectly publishes state for replica when it puts replica into LIR.
> -
>
> Key: SOLR-9555
> URL: https://issues.apache.org/jira/browse/SOLR-9555
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Alan Woodward
> Attachments: lir-9555-problem.png, SOLR-9555.patch, SOLR-9555.patch, 
> SOLR-9555.patch, SOLR-9555-WIP-2.patch, SOLR-9555-WIP-3.patch, 
> SOLR-9555-WIP.patch
>
>
> See 
> https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17888/consoleFull 
> for an example



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Reopened] (SOLR-11011) Assign.buildCoreName can lead to error in creating a new core when legacyCloud=false

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat reopened SOLR-11011:
-

> Assign.buildCoreName can lead to error in creating a new core when 
> legacyCloud=false
> 
>
> Key: SOLR-11011
> URL: https://issues.apache.org/jira/browse/SOLR-11011
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11011.patch, SOLR-11011.patch, SOLR-11011.patch, 
> SOLR-11011.patch
>
>
> Here are the case
> {code}
> shard1 : {
> node1 : shard1_replica1,
> node2 : shard1_replica2
> }
> {code}
> node2 go down, autoAddReplicasPlanAction is executed
> {code}
> shard1 : {
> node1 : shard1_replica1,
> node3 : shard1_replica3
> }
> {code}
> node2 back alive, because shard1_replica2 is removed from {{states.json}} so 
> that core won't be loaded ( but it won't be removed neither ). Then node1 go 
> down, Assign.buildCoreName will create a core with name=shard1_replica2 which 
> lead to a failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: (was: LUCENE-7906.patch)

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: LUCENE-7906.patch

Yes, you are right.

I fixed the spelling mistake and improve coding style.

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch, LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7906:
-

[~ivera], I had a quick glance at the newer patch.  So far, so good, but have a 
care for spelling and for code style.  Have a look here:

{code}
+  private boolean instersectsEdge(GeoShape other,Edge currentEdge,Edge 
firstEdge){
+if (currentEdge == firstEdge){
+  return false;
+}
+if 
(other.intersects(currentEdge.plane,currentEdge.notablePoints,currentEdge.startPlane,currentEdge.endPlane))
 {
+  return  true;
+}
+if (firstEdge == null){
+  firstEdge = currentEdge;
+}
+return instersectsEdge(other,currentEdge.next,firstEdge);
+  }
{code}

First note: "instersectsEdge" is misspelled; let's fix that before proceeding 
to commit.
Second, the style guide for Lucene states that there's a space after commas in 
argument lists for methods.

Minor details, but important.  I'll have a longer look this evening.



> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7892) LatLonDocValuesField methods should be clearly marked as slow

[ASF subversion and git services (JIRA)]

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

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

Commit c270f780b1612ede6254aa92ba90cfd4dcc1b92d in lucene-solr's branch 
refs/heads/branch_7x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c270f78 ]

LUCENE-7892: Add missing "Slow" to doc-value query factory methods.


> LatLonDocValuesField methods should be clearly marked as slow
> -
>
> Key: LUCENE-7892
> URL: https://issues.apache.org/jira/browse/LUCENE-7892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 7.0, master (8.0)
>
>
> It is very trappy that LatLonDocValuesField has stuff like 
> newBoxQuery/newDistanceQuery.
> Users bring this up on the user list and are confused as to why the resulting 
> queries are slow.
> Here, we hurt the typical use case, to try to slightly speed up an esoteric 
> one (sparse stuff). Its a terrible tradeoff for the API.
> If we truly must have such slow methods in the public API, then they should 
> have {{slow}} in their name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7892) LatLonDocValuesField methods should be clearly marked as slow

[ASF subversion and git services (JIRA)]

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

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

Commit cf4c324c6465acd1974f565d5d00592e55c7c15d in lucene-solr's branch 
refs/heads/branch_7_0 from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf4c324 ]

LUCENE-7892: Add missing "Slow" to doc-value query factory methods.


> LatLonDocValuesField methods should be clearly marked as slow
> -
>
> Key: LUCENE-7892
> URL: https://issues.apache.org/jira/browse/LUCENE-7892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 7.0, master (8.0)
>
>
> It is very trappy that LatLonDocValuesField has stuff like 
> newBoxQuery/newDistanceQuery.
> Users bring this up on the user list and are confused as to why the resulting 
> queries are slow.
> Here, we hurt the typical use case, to try to slightly speed up an esoteric 
> one (sparse stuff). Its a terrible tradeoff for the API.
> If we truly must have such slow methods in the public API, then they should 
> have {{slow}} in their name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7892) LatLonDocValuesField methods should be clearly marked as slow

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7892: Add missing "Slow" to doc-value query factory methods.


> LatLonDocValuesField methods should be clearly marked as slow
> -
>
> Key: LUCENE-7892
> URL: https://issues.apache.org/jira/browse/LUCENE-7892
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Fix For: 7.0, master (8.0)
>
>
> It is very trappy that LatLonDocValuesField has stuff like 
> newBoxQuery/newDistanceQuery.
> Users bring this up on the user list and are confused as to why the resulting 
> queries are slow.
> Here, we hurt the typical use case, to try to slightly speed up an esoteric 
> one (sparse stuff). Its a terrible tradeoff for the API.
> If we truly must have such slow methods in the public API, then they should 
> have {{slow}} in their name.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: (was: LUCENE-7906.patch)

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: LUCENE-7906.patch

Yes, adding a new interface method to the polygon interface does the trick. I 
have added the method GeoPolygon.intersects(Geshape geoshape) and it is working 
as expected. Patch attached

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7906:
-
Attachment: (was: LUCENE-7906-test.patch)

> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between 
> them I came accross a big limitation when trying to solve the relationship 
> between two geopolygons. This object does not expose the internal structure. 
> In particular at some point, it is necessary to check if one polygon 
> intersects the edges of the other polygon which currently is not possible as 
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I 
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the 
> edges) adding getters in the GeoPolygon interface. Easy to implement and 
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make 
> the spatial relationship. 
> 3) Extends GeoShape  interface so all shapes can infer the spatial 
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there 
> might be some cases which what I propose cannot be implemented or are againts 
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 53 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/53/

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([63754E73D7D603A6:D9A7210B54F8EDB3]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more




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

[jira] [Commented] (SOLR-10282) bin/solr support for enabling Kerberos security

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10282:
-

Reference guide documentation work remains.

> bin/solr support for enabling Kerberos security
> ---
>
> Key: SOLR-10282
> URL: https://issues.apache.org/jira/browse/SOLR-10282
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Fix For: 7.0
>
> Attachments: SOLR-10282.patch, SOLR-10282.patch
>
>
> This is in the same spirit as SOLR-8440.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11128) Fix 'No such file or directory' in "bin/solr auth" usage output

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-11128:

Fix Version/s: master (8.0)
   7.0

> Fix 'No such file or directory' in "bin/solr auth" usage output
> ---
>
> Key: SOLR-11128
> URL: https://issues.apache.org/jira/browse/SOLR-11128
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-complaint machine that can run the "bin/solr" 
> script.
>Reporter: Jason Gerlowski
>Assignee: Ishan Chattopadhyaya
>Priority: Trivial
> Fix For: 7.0, master (8.0)
>
> Attachments: SOLR-11128.patch
>
>
> The usage/help text for {{bin/solr auth}} currently contains two error 
> messages that are output as part of echo commands:
> {noformat}
> [~/c/l/solr] $ bin/solr auth
> Usage: solr auth enable [-type basicAuth] -credentials user:pass 
> [-blockUnknown ] [-updateIncludeFileOnly ]
>solr auth enable [-type basicAuth] -prompt  [-blockUnknown 
> ] [-updateIncludeFileOnly ]
> bin/solr: line 558: kerberos: No such file or directory
>solr auth disable [-updateIncludeFileOnly ]
>   -typeThe authentication mechanism 
> (basicAuth or kerberos) to enable. Defaults to 'basicAuth'.
>   -credentialsThe username and password of the 
> initial user. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> bin/solr: line 566: configs: No such file or directory
>   -prompt    Prompts the user to provide the 
> credentials. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> ...
> {noformat}
> These "No such file or directory" errors making their way into the output 
> come from unescaped double quotes in the echo commands outputing those lines.
> They can be fixed by either escaping the double quotes, or changing them to 
> single quotes on the two lines mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11128) Fix 'No such file or directory' in "bin/solr auth" usage output

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-11128.
-
Resolution: Fixed

Thanks Jason!

> Fix 'No such file or directory' in "bin/solr auth" usage output
> ---
>
> Key: SOLR-11128
> URL: https://issues.apache.org/jira/browse/SOLR-11128
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-complaint machine that can run the "bin/solr" 
> script.
>Reporter: Jason Gerlowski
>Assignee: Ishan Chattopadhyaya
>Priority: Trivial
> Attachments: SOLR-11128.patch
>
>
> The usage/help text for {{bin/solr auth}} currently contains two error 
> messages that are output as part of echo commands:
> {noformat}
> [~/c/l/solr] $ bin/solr auth
> Usage: solr auth enable [-type basicAuth] -credentials user:pass 
> [-blockUnknown ] [-updateIncludeFileOnly ]
>solr auth enable [-type basicAuth] -prompt  [-blockUnknown 
> ] [-updateIncludeFileOnly ]
> bin/solr: line 558: kerberos: No such file or directory
>solr auth disable [-updateIncludeFileOnly ]
>   -typeThe authentication mechanism 
> (basicAuth or kerberos) to enable. Defaults to 'basicAuth'.
>   -credentialsThe username and password of the 
> initial user. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> bin/solr: line 566: configs: No such file or directory
>   -prompt    Prompts the user to provide the 
> credentials. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> ...
> {noformat}
> These "No such file or directory" errors making their way into the output 
> come from unescaped double quotes in the echo commands outputing those lines.
> They can be fixed by either escaping the double quotes, or changing them to 
> single quotes on the two lines mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 12 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/12/

No tests ran.

Build Log:
[...truncated 25708 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (41.2 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.1.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1228.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.tgz...
   [smoker] 69.0 MB in 0.06 sec (1136.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.zip...
   [smoker] 79.3 MB in 0.06 sec (1229.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.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 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (285.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.1.0-src.tgz...
   [smoker] 50.2 MB in 0.05 sec (975.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.tgz...
   [smoker] 141.7 MB in 0.12 sec (1173.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.zip...
   [smoker] 142.7 MB in 0.13 sec (1123.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.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=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8
   [smoker] Creating Solr home directory 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]  
   [smoker] Started Solr server on port 8983 

[jira] [Created] (SOLR-11130) SolrJ routes V2Request to wrong nodes and such nodes are not able to forward these requests correctly

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-11130:


 Summary: SolrJ routes V2Request to wrong nodes and such nodes are 
not able to forward these requests correctly
 Key: SOLR-11130
 URL: https://issues.apache.org/jira/browse/SOLR-11130
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ, v2 API
Affects Versions: 6.6, master (8.0)
Reporter: Shalin Shekhar Mangar


I am trying to use V2Request to invoke the config API with SolrJ. Sometimes, I 
see a weird NullPointerException:

{code}
5396 ERROR (qtp1277924867-37) [n:127.0.0.1:33527_solr] o.a.s.s.HttpSolrCall 
null:java.lang.NullPointerException
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:518)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:378)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:322)
{code}
and the corresponding exception on the solrj client was:
{code}
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException: 
Error from server at http://127.0.0.1:33527/solr: Unknown Error

at 
__randomizedtesting.SeedInfo.seed([33AAA14CC3DE7EE3:BBFE9E966D22131B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteExecutionException.create(HttpSolrClient.java:812)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:602)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.TestCloudSearcherWarming.test(TestCloudSearcherWarming.java:68)
{code}

The code used to invoke the api was:
{code}
V2Request request = new V2Request.Builder("/c/" + collectionName + 
"/config").withMethod(SolrRequest.METHOD.POST).withPayload(addListenerCommand).build();
solrClient.request(request);
{code}

This exception happens when the config API call is sent to a Solr node which 
does not have any replica for the collection. Now in v1 API, solrj would refuse 
to send the request and complain that no default collection is set but the 
V2Request does not do that.

So there are two bugs here:
# V2Request tries to send request for collection X to a random node without 
caring for correct routing
# The node receiving such request is not able to forward it to the right node 
and fails with a NPE.

To solve 1, our options are:
# Either we start requiring the same for V2 i.e. user must set default 
collection
# We detect that users are trying to invoke a collection specific v2 api and we 
add a new method in V2RequestBuilder to specify a collection name and ensure 
that the user calls it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11128) Fix 'No such file or directory' in "bin/solr auth" usage output

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11128:


Commit 592bd1553dbae6496a6a3a472373decfc771f845 in lucene-solr's branch 
refs/heads/branch_7_0 from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=592bd15 ]

SOLR-11128: Escape script usage strings containing quotes


> Fix 'No such file or directory' in "bin/solr auth" usage output
> ---
>
> Key: SOLR-11128
> URL: https://issues.apache.org/jira/browse/SOLR-11128
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-complaint machine that can run the "bin/solr" 
> script.
>Reporter: Jason Gerlowski
>Assignee: Ishan Chattopadhyaya
>Priority: Trivial
> Attachments: SOLR-11128.patch
>
>
> The usage/help text for {{bin/solr auth}} currently contains two error 
> messages that are output as part of echo commands:
> {noformat}
> [~/c/l/solr] $ bin/solr auth
> Usage: solr auth enable [-type basicAuth] -credentials user:pass 
> [-blockUnknown ] [-updateIncludeFileOnly ]
>solr auth enable [-type basicAuth] -prompt  [-blockUnknown 
> ] [-updateIncludeFileOnly ]
> bin/solr: line 558: kerberos: No such file or directory
>solr auth disable [-updateIncludeFileOnly ]
>   -typeThe authentication mechanism 
> (basicAuth or kerberos) to enable. Defaults to 'basicAuth'.
>   -credentialsThe username and password of the 
> initial user. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> bin/solr: line 566: configs: No such file or directory
>   -prompt    Prompts the user to provide the 
> credentials. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> ...
> {noformat}
> These "No such file or directory" errors making their way into the output 
> come from unescaped double quotes in the echo commands outputing those lines.
> They can be fixed by either escaping the double quotes, or changing them to 
> single quotes on the two lines mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11128) Fix 'No such file or directory' in "bin/solr auth" usage output

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11128:


Commit b0f9a7697727ddc876d7e9ee84830e3cf2fd5482 in lucene-solr's branch 
refs/heads/branch_7x from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b0f9a76 ]

SOLR-11128: Escape script usage strings containing quotes


> Fix 'No such file or directory' in "bin/solr auth" usage output
> ---
>
> Key: SOLR-11128
> URL: https://issues.apache.org/jira/browse/SOLR-11128
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-complaint machine that can run the "bin/solr" 
> script.
>Reporter: Jason Gerlowski
>Assignee: Ishan Chattopadhyaya
>Priority: Trivial
> Attachments: SOLR-11128.patch
>
>
> The usage/help text for {{bin/solr auth}} currently contains two error 
> messages that are output as part of echo commands:
> {noformat}
> [~/c/l/solr] $ bin/solr auth
> Usage: solr auth enable [-type basicAuth] -credentials user:pass 
> [-blockUnknown ] [-updateIncludeFileOnly ]
>solr auth enable [-type basicAuth] -prompt  [-blockUnknown 
> ] [-updateIncludeFileOnly ]
> bin/solr: line 558: kerberos: No such file or directory
>solr auth disable [-updateIncludeFileOnly ]
>   -typeThe authentication mechanism 
> (basicAuth or kerberos) to enable. Defaults to 'basicAuth'.
>   -credentialsThe username and password of the 
> initial user. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> bin/solr: line 566: configs: No such file or directory
>   -prompt    Prompts the user to provide the 
> credentials. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> ...
> {noformat}
> These "No such file or directory" errors making their way into the output 
> come from unescaped double quotes in the echo commands outputing those lines.
> They can be fixed by either escaping the double quotes, or changing them to 
> single quotes on the two lines mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11128) Fix 'No such file or directory' in "bin/solr auth" usage output

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11128:


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

SOLR-11128: Escape script usage strings containing quotes


> Fix 'No such file or directory' in "bin/solr auth" usage output
> ---
>
> Key: SOLR-11128
> URL: https://issues.apache.org/jira/browse/SOLR-11128
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: master (8.0)
> Environment: Any POSIX-complaint machine that can run the "bin/solr" 
> script.
>Reporter: Jason Gerlowski
>Assignee: Ishan Chattopadhyaya
>Priority: Trivial
> Attachments: SOLR-11128.patch
>
>
> The usage/help text for {{bin/solr auth}} currently contains two error 
> messages that are output as part of echo commands:
> {noformat}
> [~/c/l/solr] $ bin/solr auth
> Usage: solr auth enable [-type basicAuth] -credentials user:pass 
> [-blockUnknown ] [-updateIncludeFileOnly ]
>solr auth enable [-type basicAuth] -prompt  [-blockUnknown 
> ] [-updateIncludeFileOnly ]
> bin/solr: line 558: kerberos: No such file or directory
>solr auth disable [-updateIncludeFileOnly ]
>   -typeThe authentication mechanism 
> (basicAuth or kerberos) to enable. Defaults to 'basicAuth'.
>   -credentialsThe username and password of the 
> initial user. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> bin/solr: line 566: configs: No such file or directory
>   -prompt    Prompts the user to provide the 
> credentials. Applicable for basicAuth only.
>  Note: only one of -prompt or 
> -credentials must be provided
> ...
> {noformat}
> These "No such file or directory" errors making their way into the output 
> come from unescaped double quotes in the echo commands outputing those lines.
> They can be fixed by either escaping the double quotes, or changing them to 
> single quotes on the two lines mentioned above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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