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

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-7157 at 4/4/16 6:15 AM:
-

Here's the latest; not much different from before but iterates over the 
directional test to be sure its inherent pole choice algorithm is not a factor.

Beasting passes for me too.



was (Author: kwri...@metacarta.com):
Here's the latest; not much different from before but iterates over the 
directional test to be sure its inherent pole choice algorithm is not a factor.

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7157:

Attachment: LUCENE-7157.diff

Here's the latest; not much different from before but iterates over the 
directional test to be sure its inherent pole choice algorithm is not a factor.

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7157:
-

bq. Just like I don't think users need to deal with radians, I don't think they 
should know about concaveness either. I understand that geo3d is different, but 
it needs to not unload the challenges of 3d-ness onto the user but instead use 
it behind the scenes.

While I agree in general, there *is* a specification problem, which is that if 
you describe any polygon on the face of the earth by a series of points, there 
are two possible areas you are in fact describing -- one on one side of the 
polygon, and one on the other.  Geo3D has always required some means of 
specifying which area the user means, but through ways that were difficult to 
use.  ESRI uses clockwise/counterclockwise to allow the user to describe which 
area the user means, which is a lot cleaner, and that is what this ticket is 
about.

The Lucene API's will need to make similar functionality available somehow.  I 
had thought that they adhered to the ESRI mechanism but I'm now confused 
whether this was what you actually intended to do.  I would love to have some 
confirmation one way or another before proceeding to manifest the 
clockwise/counterclockwise functionality into the official Geo3DPoint API.

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



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

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

[jira] [Updated] (SOLR-8937) bin/post (SimplePostTool) should stream/chunk if size not known

[David Smiley (JIRA)]

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

David Smiley updated SOLR-8937:
---
Attachment: SOLR_8937_post_streaming.patch

> bin/post (SimplePostTool) should stream/chunk if size not known
> ---
>
> Key: SOLR-8937
> URL: https://issues.apache.org/jira/browse/SOLR-8937
> Project: Solr
>  Issue Type: Improvement
>  Components: SimplePostTool
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_8937_post_streaming.patch
>
>
> {{SimplePostTool.postData()}} takes a {{Long length}} arg that is sometimes 
> null -- for stdin and for processing some web pages for links.  If it's null, 
> we should this on the underlying HttpURLConnection:
> {{urlc.setChunkedStreamingMode(-1);}}.  I have found that I can't use 
> bin/post to stream large files from stdin since it the JDK's implementation 
> wants to put the whole thing in memory first.  Sadly this is true of {{curl}} 
> as well.  When I set chunk mode, it works.  (FYI -1 tells it to use its 
> default chunk size -- 4k).
> FYI I'm using stdin because I've got massive JSON files zipped up.



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

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

[jira] [Created] (SOLR-8937) bin/post (SimplePostTool) should stream/chunk if size not known

[David Smiley (JIRA)]

David Smiley created SOLR-8937:
--

 Summary: bin/post (SimplePostTool) should stream/chunk if size not 
known
 Key: SOLR-8937
 URL: https://issues.apache.org/jira/browse/SOLR-8937
 Project: Solr
  Issue Type: Improvement
  Components: SimplePostTool
Reporter: David Smiley
Assignee: David Smiley


{{SimplePostTool.postData()}} takes a {{Long length}} arg that is sometimes 
null -- for stdin and for processing some web pages for links.  If it's null, 
we should this on the underlying HttpURLConnection:
{{urlc.setChunkedStreamingMode(-1);}}.  I have found that I can't use bin/post 
to stream large files from stdin since it the JDK's implementation wants to put 
the whole thing in memory first.  Sadly this is true of {{curl}} as well.  When 
I set chunk mode, it works.  (FYI -1 tells it to use its default chunk size -- 
4k).

FYI I'm using stdin because I've got massive JSON files zipped up.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 117 - Still Failing

[Apache Jenkins Server]

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

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([E803AA8F53A80CAB:52D1C5F7D086E2BE]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:775)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529&qt=standard&start=0&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:768)
... 40 more




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

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

[Policeman Jenkins Server]

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

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

Error Message:
document count mismatch.  control=372 sum(shards)=371 cloudClient=371

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=372 sum(shards)=371 
cloudClient=371
at 
__randomizedtesting.SeedInfo.seed([557F640CDCDF0D2B:DD2B5BD6722360D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1317)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotse

[jira] [Commented] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Greg Pendlebury (JIRA)]

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

Greg Pendlebury commented on SOLR-8812:
---

[~erickerickson], personally, I am ambivalent with regards to timing and 
versions. I am still not convinced there is actually an issue here, but I don't 
want to be a dick and dismiss it out-of-hand.

The patches provided are simply about choosing default parameter values that 
disrupt the least number of users who did not have mm set to an appropriate 
value. Any user (risky, broad generalisation incoming) who puts a boolean OR 
operator into an edismax query string would not want mm=100%, but that is what 
is happening here.

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Assignee: Erick Erickson
>Priority: Blocker
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8812-barbie.patch, SOLR-8812.patch, SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



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

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

[jira] [Updated] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Greg Pendlebury (JIRA)]

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

Greg Pendlebury updated SOLR-8812:
--
Attachment: SOLR-8812-barbie.patch

Adding a 'hair ties -barbie' example to unit tests. Not sure it demonstrates 
anything new, but it does work as I would expect.

I can't get git to generate a combined patch the way I would have in svn... my 
git-fu is weak.

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Assignee: Erick Erickson
>Priority: Blocker
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8812-barbie.patch, SOLR-8812.patch, SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



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

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

[JENKINS-EA] Lucene-Solr-6.0-Linux (64bit/jdk-9-ea+111-patched) - Build # 10 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.0-Linux/10/
Java: 64bit/jdk-9-ea+111-patched -XX:+UseCompressedOops -XX:+UseParallelGC 
-XX:-CompactStrings

All tests passed

Build Log:
[...truncated 11867 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.0-Linux/solr/build/solr-core/test/temp/junit4-J1-20160403_232950_687.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7fe1d2644e90, pid=11260, tid=11283
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (9.0+111) (build 
9-ea+111)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (9-ea+111, mixed mode, 
tiered, compressed oops, parallel gc, linux-amd64)
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0xb77e90]  
PSRootsClosure::do_oop(oopDesc**)+0x30
   [junit4] #
   [junit4] # No core dump will be written. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/home/jenkins/workspace/Lucene-Solr-6.0-Linux/solr/build/solr-core/test/J1/hs_err_pid11260.log
   [junit4] Compiled method (c2) 1170931 35546   !   4   
org.apache.solr.update.SolrCmdDistributor::submit (301 bytes)
   [junit4]  total in heap  [0x7fe1bdbedc90,0x7fe1bdbfb918] = 56456
   [junit4]  relocation [0x7fe1bdbeddd0,0x7fe1bdbee840] = 2672
   [junit4]  main code  [0x7fe1bdbee840,0x7fe1bdbf5760] = 28448
   [junit4]  stub code  [0x7fe1bdbf5760,0x7fe1bdbf5c08] = 1192
   [junit4]  oops   [0x7fe1bdbf5c08,0x7fe1bdbf5cc0] = 184
   [junit4]  metadata   [0x7fe1bdbf5cc0,0x7fe1bdbf64e8] = 2088
   [junit4]  scopes data[0x7fe1bdbf64e8,0x7fe1bdbf90a8] = 11200
   [junit4]  scopes pcs [0x7fe1bdbf90a8,0x7fe1bdbfa5e8] = 5440
   [junit4]  dependencies   [0x7fe1bdbfa5e8,0x7fe1bdbfa858] = 624
   [junit4]  handler table  [0x7fe1bdbfa858,0x7fe1bdbfb6f8] = 3744
   [junit4]  nul chk table  [0x7fe1bdbfb6f8,0x7fe1bdbfb918] = 544
   [junit4] Compiled method (c2) 1170932 35546   !   4   
org.apache.solr.update.SolrCmdDistributor::submit (301 bytes)
   [junit4]  total in heap  [0x7fe1bdbedc90,0x7fe1bdbfb918] = 56456
   [junit4]  relocation [0x7fe1bdbeddd0,0x7fe1bdbee840] = 2672
   [junit4]  main code  [0x7fe1bdbee840,0x7fe1bdbf5760] = 28448
   [junit4]  stub code  [0x7fe1bdbf5760,0x7fe1bdbf5c08] = 1192
   [junit4]  oops   [0x7fe1bdbf5c08,0x7fe1bdbf5cc0] = 184
   [junit4]  metadata   [0x7fe1bdbf5cc0,0x7fe1bdbf64e8] = 2088
   [junit4]  scopes data[0x7fe1bdbf6
   [junit4] 4e8,0x7fe1bdbf90a8] = 11200
   [junit4]  scopes pcs [0x7fe1bdbf90a8,0x7fe1bdbfa5e8] = 5440
   [junit4]  dependencies   [0x7fe1bdbfa5e8,0x7fe1bdbfa858] = 624
   [junit4]  handler table  [0x7fe1bdbfa858,0x7fe1bdbfb6f8] = 3744
   [junit4]  nul chk table  [0x7fe1bdbfb6f8,0x7fe1bdbfb918] = 544
   [junit4] Compiled method (c2) 1170932 35546   !   4   
org.apache.solr.update.SolrCmdDistributor::submit (301 bytes)
   [junit4]  total in heap  [0x7fe1bdbedc90,0x7fe1bdbfb918] = 56456
   [junit4]  relocation [0x7fe1bdbeddd0,0x7fe1bdbee840] = 2672
   [junit4]  main code  [0x7fe1bdbee840,0x7fe1bdbf5760] = 28448
   [junit4]  stub code  [0x7fe1bdbf5760,0x7fe1bdbf5c08] = 1192
   [junit4]  oops   [0x7fe1bdbf5c08,0x7fe1bdbf5cc0] = 184
   [junit4]  metadata   [0x7fe1bdbf5cc0,0x7fe1bdbf64e8] = 2088
   [junit4]  scopes data[0x7fe1bdbf64e8,0x7fe1bdbf90a8] = 11200
   [junit4]  scopes pcs [0x7fe1bdbf90a8,0x7fe1bdbfa5e8] = 5440
   [junit4]  dependencies   [0x7fe1bdbfa5e8,0x7fe1bdbfa858] = 624
   [junit4]  handler table  [0x7fe1bdbfa858,0x7fe1bdbfb6f8] = 3744
   [junit4]  nul chk table  [0x7fe1bdbfb6f8,0x7fe1bdbfb918] = 544
   [junit4] Compiled method (c2) 1170932 35546   !   4   
org.apache.solr.update.SolrCmdDistributor::submit (301 bytes)
   [junit4]  total in heap  [0x7fe1bdbedc90,0x7fe1bdbfb918] = 56456
   [junit4]  relocation [0x7fe1bdbeddd0,0x7fe1bdbee840] = 2672
   [junit4]  main code  [0x7fe1bdbee840,0x7fe1bdbf5760] = 28448
   [junit4]  stub code  [0x7fe1bdbf5760,0x7fe1bdbf5c08] = 1192
   [junit4]  oops   [0x7fe1bdbf5c08,0x7fe1bdbf5cc0] = 184
   [junit4]  metadata   [0x7fe1bdbf5cc0,0x7fe1bdbf64e8] = 2088
   [junit4]  scopes data[0x7fe1bdbf64e8,0x7fe1bdbf90a8] = 11200
   [junit4]  scopes pcs [0x7fe1bdbf90a8,0x7fe1bdbfa5e8] = 5440
   [junit4]  dependencies   [0x7fe1bdbfa5e8,0x7fe1bdbfa858] = 624
   

[jira] [Commented] (LUCENE-7155) Script addVersion.py does not detect the new naming convention for bugfix branches

[JIRA]

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

Jan Høydahl commented on LUCENE-7155:
-

But scriptutil.py#find_branch_type() never returns the string "major"?

> Script addVersion.py does not detect the new naming convention for bugfix 
> branches
> --
>
> Key: LUCENE-7155
> URL: https://issues.apache.org/jira/browse/LUCENE-7155
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: -tools
>Affects Versions: 5.5, master, 6.0, 6.x
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 5.5, master
>
> Attachments: LUCENE-7155-improve.patch, LUCENE-7155.patch
>
>
> Spinoff from LUCENE-6938. Earlier we named release branches 
> {{lucene_solr_X_Y}} while now we name them {{branch_X_Y}}.



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

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

[jira] [Comment Edited] (SOLR-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-8208 at 4/3/16 8:49 PM:


it seems like param tracing can be done with {{logParamsList}}
{noformat}
...Request [collection1]  webapp=null path=null 
params={q=name_s:dave&subq1.rows=6&indent=true&fl=*,depts:[subquery+prefix%3Dsubq1+]&rows=2&subq1.indent=true&subq1.logParamsList=q,fl,rows,subq1.row.dept_ss_dv&wt=xml&subq1.fl=text_t&subq1.q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}}
 hits=2 status=0 QTime=9979
...Request [collection1]  webapp=null path=null 
params={q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}&subq1.row.dept_ss_dv=Support,Engineering&fl=text_t&rows=6}
 hits=6 status=0 QTime=60740
{noformat}


was (Author: mkhludnev):
it seems like param tracing can be done with {{logParamsList}}
{quote}
...Request [collection1]  webapp=null path=null 
params={q=name_s:dave&subq1.rows=6&indent=true&fl=*,depts:[subquery+prefix%3Dsubq1+]&rows=2&subq1.indent=true&subq1.logParamsList=q,fl,rows,subq1.row.dept_ss_dv&wt=xml&subq1.fl=text_t&subq1.q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}}
 hits=2 status=0 QTime=9979
...Request [collection1]  webapp=null path=null 
params={q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}&subq1.row.dept_ss_dv=Support,Engineering&fl=text_t&rows=6}
 hits=6 status=0 QTime=60740
{quote}

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call them sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can allow to specify subquery parameter prefix:
> {code}
> ..&fl=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..&subq1.q={!term f=child_id 
> v=$subq1.row.id}&subq1.rows=3&subq1.sort=price&..
> {code}   
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * the itchiest one is to reference to document field from subquery 
> parameters, here I propose to use local param {{v}} and param deference 
> {{v=$param}} thus every document field implicitly introduces parameter for 
> subquery $\{paramPrefix\}row.$\{fieldName\}, thus above subquery is 
> q=child_id:, presumably we can drop "row." in the middle 
> (reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields. 
> * \[subquery\], or \[query\], or ? 
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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

[jira] [Commented] (SOLR-8208) DocTransformer executes sub-queries

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8208:


it seems like param tracing can be done with {{logParamsList}}
{quote}
...Request [collection1]  webapp=null path=null 
params={q=name_s:dave&subq1.rows=6&indent=true&fl=*,depts:[subquery+prefix%3Dsubq1+]&rows=2&subq1.indent=true&subq1.logParamsList=q,fl,rows,subq1.row.dept_ss_dv&wt=xml&subq1.fl=text_t&subq1.q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}}
 hits=2 status=0 QTime=9979
...Request [collection1]  webapp=null path=null 
params={q={!terms+f%3Ddept_id_s+v%3D$subq1.row.dept_ss_dv+separator%3D,}&subq1.row.dept_ss_dv=Support,Engineering&fl=text_t&rows=6}
 hits=6 status=0 QTime=60740
{quote}

> DocTransformer executes sub-queries
> ---
>
> Key: SOLR-8208
> URL: https://issues.apache.org/jira/browse/SOLR-8208
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>  Labels: features, newbie
> Attachments: SOLR-8208.diff, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, SOLR-8208.patch, 
> SOLR-8208.patch, SOLR-8208.patch
>
>
> The initial idea was to return "from" side of query time join via 
> doctransformer. I suppose it isn't  query-time join specific, thus let to 
> specify any query and parameters for them, let's call them sub-query. But it 
> might be problematic to escape subquery parameters, including local ones, 
> e.g. what if subquery needs to specify own doctransformer in &fl=\[..\] ?
> I suppose we can allow to specify subquery parameter prefix:
> {code}
> ..&fl=id,[subquery paramPrefix=subq1. 
> fromIndex=othercore],score,..&subq1.q={!term f=child_id 
> v=$subq1.row.id}&subq1.rows=3&subq1.sort=price&..
> {code}   
> * {{paramPrefix=subq1.}} shifts parameters for subquery: {{subq1.q}} turns to 
> {{q}} for subquery, {{subq1.rows}} to {{rows}}
> * {{fromIndex=othercore}} optional param allows to run subquery on other 
> core, like it works on query time join
> * the itchiest one is to reference to document field from subquery 
> parameters, here I propose to use local param {{v}} and param deference 
> {{v=$param}} thus every document field implicitly introduces parameter for 
> subquery $\{paramPrefix\}row.$\{fieldName\}, thus above subquery is 
> q=child_id:, presumably we can drop "row." in the middle 
> (reducing to v=$subq1.id), until someone deal with {{rows}}, {{sort}} fields. 
> * \[subquery\], or \[query\], or ? 
> Caveat: it should be a way slow; it handles only search result page, not 
> entire result set. 



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

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

RE: [VOTE] Release Lucene/Solr 6.0.0 RC2

[Uwe Schindler]

Hi Jack

> Adding this less-controversial point:
>
> 5. It should have been stated explicitly that Java 1.9 is not supported at 
> this time.

I am not sure why you want to have this in the release notes. This is 
completely irrelevant:

- Java 9 is not yet released, so nobody would use it in production! As we 
cannot look into the future it is not even sure that Java 9 will be ever 
released or maybe Java 10 comes earlier! :-) So we cannot make any statements 
about Java 9. But we also cannot say that it is not supported, because:
- As of current day, Lucene and Solr 6 are in fact compatible with Java 9 build 
111 as released last week. There is only a bug in the preview build, but it is 
definitely compatible otherwise. The only thing that does not work is Solr's 
Hadoop-related stuff, but that is not Solr's fault, it is just Hadoop still on 
Java 6 and not taking care of upgrading. It is a kind of wonder that it works 
with Java 7 or 8 - really :-)

Java 9 has now the module system migrated into its core and the APIs are very 
stable now:
- MMapDirectory works (it does *not fully work* with Lucene 5.5). There is 
currently a change in the internal APIs for unmapping planned, but the current 
code in Lucene 6 is able to handle that. If not, nothing breaks, because 
MMapDirectory will just be disabled by default - thanks to the new code in 
Lucene 6. Lucene 5 will break horrible with Java 9.
- Lucene and Solr's tests pass, the few bugs we see are just pre-release bugs, 
but no technical problems. It's because Java 9 is still beta, not released
- Lucene and Solr no longer require crazy permissions granted that prevent them 
from the more restricted module environment in Java 9.

I can 99% ensure, Lucene 6+ will work with Java 9, once it is out. The 
remaining 1% is just there because you never know what the future brings: It 
could also happen that Lucene/Solr 5.5 or Lucene/Solr 6 won't work with Java 8 
update 90 or update 100! Who knows?

So please stop arguing.

As today's state, Lucene 6 is compatible with Java 9 build 111. PERIOD.
Uwe


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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 40030 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (11.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.0.0-src.tgz...
   [smoker] 28.5 MB in 0.03 sec (1040.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.tgz...
   [smoker] 62.9 MB in 0.06 sec (1124.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.0.0.zip...
   [smoker] 73.6 MB in 0.07 sec (1121.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6045 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6045 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 215 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (109.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.0.0-src.tgz...
   [smoker] 37.5 MB in 0.04 sec (990.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.tgz...
   [smoker] 131.5 MB in 0.13 sec (1047.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.0.0.zip...
   [smoker] 139.9 MB in 0.33 sec (429.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.0/lucene/build/smokeTestRelease/tmp/unpack/solr-6.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] bin/solr start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 30 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]   [|]   [/]   [-]   
[\]   [|]   [/]  
   [smoker] Start

Re: [VOTE] Release Lucene/Solr 6.0.0 RC2

[Jack Krupansky]

-0 for my previous reasons:

1. The new points feature should have been treated as experimental in 6.0.
2. The rest of Lucene should not have been switched over to this largely
unbaked, experimental points feature so soon.
3. The current 5.x numerics should not have been deprecated so soon, with
the points numerics so unbaked and so experimental.
4. The naming and terminology of the points feature is just plain bad -
confusing/conflating scalar numeric values and spatial data.
5. Given the degree to which Solr and Lucene are linked and the prominence
of Lucene switching from current numerics to points, it would be
appropriate for Solr to explicitly note that it still uses the
5.x-compatible numerics and will continue to do so until a reasonable
migration/upgrade story for existing numeric data is in place.

Adding this less-controversial point:

5. It should have been stated explicitly that Java 1.9 is not supported at
this time.

That said, I don't expect 6.0 to be held up for any of my personal
complaints. I simply wanted to avoid anyone having the impression that I
found the current status of handling of numerics and points to be
acceptable. I don't expect any change, but I cannot say anything positive
about this state of affairs.

None of this should reflect negatively on the RM or the artifacts or
logistical process of the release.


-- Jack Krupansky

On Sat, Apr 2, 2016 at 3:19 PM, Mikhail Khludnev  wrote:

> Hi,
>
> I'm not sure what I'm doing, but
>
> SUCCESS! [1:55:30.799304]
>
>
> On Fri, Apr 1, 2016 at 11:44 PM, Nicholas Knize  wrote:
>
>> Please vote for the RC2 release candidate for Lucene/Solr 6.0.0.
>>
>> Artifacts:
>>
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.0.0-RC2-rev48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3
>>
>> Smoke tester:
>>
>>   python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.0.0-RC2-rev48c80f91b8e5cd9b3a9b48e6184bd53e7619e7e3
>>
>> Here's my +1:
>>
>> SUCCESS! [0:28:59.770357]
>>
>> - Nick Knize
>>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> 
> 
>

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 976 - Still Failing

[Apache Jenkins Server]

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

11 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationDistributedZkTest

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

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


FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CdcrReplicationDistributedZkTest

Error Message:
48 thread

[jira] [Commented] (LUCENE-7170) move BaseGeoPointTestCase to test-framework

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7170:


+1

> move BaseGeoPointTestCase to test-framework
> ---
>
> Key: LUCENE-7170
> URL: https://issues.apache.org/jira/browse/LUCENE-7170
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-7170.patch
>
>
> This abstract test class has hooks for basic operations:
> {code}
>   protected abstract void addPointToDoc(String field, Document doc, double 
> lat, double lon);
>   protected abstract Query newRectQuery(String field, double minLat, double 
> maxLat, double minLon, double maxLon);
>   protected abstract Query newDistanceQuery(String field, double centerLat, 
> double centerLon, double radiusMeters);
>   protected abstract Query newPolygonQuery(String field, Polygon... polygon);
> {code}
> and hooks for quantization (quantizeLat/quantizeLon) so it can demand exact 
> answers.
> We currently have 3 subclasses, one is in the sandbox. I don't think the 
> sandbox/ should have to depend on spatial/ just for this base test class, and 
> having it in test-framework is a better place.



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

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

[jira] [Commented] (LUCENE-7159) improve spatial point/rect vs. polygon performance

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7159: improve testing of polygon tree methods


> improve spatial point/rect vs. polygon performance
> --
>
> Key: LUCENE-7159
> URL: https://issues.apache.org/jira/browse/LUCENE-7159
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Now that we can query on complex polygons without going OOM (LUCENE-7153), we 
> should do something to address the current 🐢 performance.
> Currently, we use a basic crossings test ({{O\(n)}}) for boundary cases. We 
> defer these expensive per-doc checks on boundary cases to a two phase 
> iterator (LUCENE-7019, LUCENE-7109), so that it can be avoided if e.g. 
> excluded by filters, conjunctions, deleted doc, and so on. This is currently 
> important for performance, but basically its shoving the problem under the 
> rug and hoping it goes away. At least for point in poly, there are a number 
> of faster techniques described here: 
> http://erich.realtimerendering.com/ptinpoly/
> Additionally I am not sure how costly our "tree traversal" (rectangle 
> intersection algorithms). Maybe its nothing to be worried about, but likely 
> it too gets bad if the thing gets complex enough. These don't need to be 
> perfect but need to behave like java's Shape#contains (can conservatively 
> return false), and Shape#intersects (can conservatively return true). Of 
> course, if they are too inaccurate, then things can get slower.
> In cases of precomputed structures we should also consider memory usage: e.g. 
> we shouldn't make a horrible tradeoff there.



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

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

[jira] [Commented] (LUCENE-7159) improve spatial point/rect vs. polygon performance

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7159: improve testing of polygon tree methods


> improve spatial point/rect vs. polygon performance
> --
>
> Key: LUCENE-7159
> URL: https://issues.apache.org/jira/browse/LUCENE-7159
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>
> Now that we can query on complex polygons without going OOM (LUCENE-7153), we 
> should do something to address the current 🐢 performance.
> Currently, we use a basic crossings test ({{O\(n)}}) for boundary cases. We 
> defer these expensive per-doc checks on boundary cases to a two phase 
> iterator (LUCENE-7019, LUCENE-7109), so that it can be avoided if e.g. 
> excluded by filters, conjunctions, deleted doc, and so on. This is currently 
> important for performance, but basically its shoving the problem under the 
> rug and hoping it goes away. At least for point in poly, there are a number 
> of faster techniques described here: 
> http://erich.realtimerendering.com/ptinpoly/
> Additionally I am not sure how costly our "tree traversal" (rectangle 
> intersection algorithms). Maybe its nothing to be worried about, but likely 
> it too gets bad if the thing gets complex enough. These don't need to be 
> perfect but need to behave like java's Shape#contains (can conservatively 
> return false), and Shape#intersects (can conservatively return true). Of 
> course, if they are too inaccurate, then things can get slower.
> In cases of precomputed structures we should also consider memory usage: e.g. 
> we shouldn't make a horrible tradeoff there.



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

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

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

[Policeman Jenkins Server]

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

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

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([C4F626B2753F1A91]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:173)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud.createMiniSolrCloudCluster(TestTolerantUpdateProcessorRandomCloud.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:811)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11122 lines...]
   [junit4] Suite: org.apache.solr.cloud.TestTolerantUpdateProcessorRandomCloud
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.TestTolerantUpdateProcessorRandomCloud_C4F626B2753F1A91-001/init-core-data-001
   [junit4]   2> 272525 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true)
   [junit4]   2> 272525 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.c.TestTolerantUpdateProcessorRandomCloud Configuring cluster: 
servers=7, shards=3, repfactor=2
   [junit4]   2> 272526 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 272526 INFO  (Thread-918) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 272526 INFO  (Thread-918) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 272627 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.c.ZkTestServer start zk server on port:35618
   [junit4]   2> 272627 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 272627 INFO  
(SUITE-TestTolerantUpdateProcessorRandomCloud-seed#[C4F626B2753F1A91]-worker) [ 
   ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 272629 INFO  (zkCallback-483-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.so

[jira] [Commented] (LUCENE-7163) Refactor GeoRect and Polygon to core

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7163: move Polygon's test too


> Refactor GeoRect and Polygon to core
> 
>
> Key: LUCENE-7163
> URL: https://issues.apache.org/jira/browse/LUCENE-7163
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-7163.patch
>
>
> {{o.a.l.spatial.util.GeoRect}} and {{o.a.l.spatial.util.Polygon}} are 
> reusable classes across multiple lucene modules. It makes sense for them to 
> be moved to the {{o.a.l.geo}} package in the core module so they're exposed 
> across multiple modules.
> {{GeoRect}} should also be refactored to something more straightforward, like 
> {{Rectangle}}



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

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

[jira] [Commented] (LUCENE-7163) Refactor GeoRect and Polygon to core

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7163: move Polygon's test too


> Refactor GeoRect and Polygon to core
> 
>
> Key: LUCENE-7163
> URL: https://issues.apache.org/jira/browse/LUCENE-7163
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Nicholas Knize
> Attachments: LUCENE-7163.patch
>
>
> {{o.a.l.spatial.util.GeoRect}} and {{o.a.l.spatial.util.Polygon}} are 
> reusable classes across multiple lucene modules. It makes sense for them to 
> be moved to the {{o.a.l.geo}} package in the core module so they're exposed 
> across multiple modules.
> {{GeoRect}} should also be refactored to something more straightforward, like 
> {{Rectangle}}



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

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

[jira] [Updated] (LUCENE-7170) move BaseGeoPointTestCase to test-framework

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-7170:

Attachment: LUCENE-7170.patch

Here is a patch. Basically it just moves the file and removes the sandbox/ dep 
on spatial/
{noformat}
modified:   dev-tools/maven/lucene/sandbox/pom.xml.template
modified:   lucene/sandbox/build.xml
modified:   
lucene/sandbox/src/test/org/apache/lucene/search/TestLatLonPointQueries.java
modified:   
lucene/spatial/src/test/org/apache/lucene/spatial/geopoint/search/TestGeoPointQuery.java
modified:   
lucene/spatial/src/test/org/apache/lucene/spatial/geopoint/search/TestLegacyGeoPointQuery.java
renamed:
lucene/spatial/src/test/org/apache/lucene/spatial/util/BaseGeoPointTestCase.java
 -> 
lucene/test-framework/src/java/org/apache/lucene/geo/BaseGeoPointTestCase.java
{noformat}

> move BaseGeoPointTestCase to test-framework
> ---
>
> Key: LUCENE-7170
> URL: https://issues.apache.org/jira/browse/LUCENE-7170
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Robert Muir
> Attachments: LUCENE-7170.patch
>
>
> This abstract test class has hooks for basic operations:
> {code}
>   protected abstract void addPointToDoc(String field, Document doc, double 
> lat, double lon);
>   protected abstract Query newRectQuery(String field, double minLat, double 
> maxLat, double minLon, double maxLon);
>   protected abstract Query newDistanceQuery(String field, double centerLat, 
> double centerLon, double radiusMeters);
>   protected abstract Query newPolygonQuery(String field, Polygon... polygon);
> {code}
> and hooks for quantization (quantizeLat/quantizeLon) so it can demand exact 
> answers.
> We currently have 3 subclasses, one is in the sandbox. I don't think the 
> sandbox/ should have to depend on spatial/ just for this base test class, and 
> having it in test-framework is a better place.



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

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

[jira] [Created] (LUCENE-7170) move BaseGeoPointTestCase to test-framework

[Robert Muir (JIRA)]

Robert Muir created LUCENE-7170:
---

 Summary: move BaseGeoPointTestCase to test-framework
 Key: LUCENE-7170
 URL: https://issues.apache.org/jira/browse/LUCENE-7170
 Project: Lucene - Core
  Issue Type: Task
Reporter: Robert Muir


This abstract test class has hooks for basic operations:
{code}
  protected abstract void addPointToDoc(String field, Document doc, double lat, 
double lon);

  protected abstract Query newRectQuery(String field, double minLat, double 
maxLat, double minLon, double maxLon);

  protected abstract Query newDistanceQuery(String field, double centerLat, 
double centerLon, double radiusMeters);

  protected abstract Query newPolygonQuery(String field, Polygon... polygon);
{code}

and hooks for quantization (quantizeLat/quantizeLon) so it can demand exact 
answers.

We currently have 3 subclasses, one is in the sandbox. I don't think the 
sandbox/ should have to depend on spatial/ just for this base test class, and 
having it in test-framework is a better place.



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

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

[jira] [Updated] (SOLR-8935) Add cycle detection PostFilter

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8935:
-
Description: in SOLR- cycle detection is done in the worker node. This 
ticket will allow all graph traversals to push down cycle detection into the 
search engine. This will eliminate a huge amount of un-needed network traffic 
for large distributed graph traversals.  (was: in SOLR- cycle detection is 
done in the worker node. This ticket will allow all graph traversals to push 
down cycle detection into the search engine. This will eliminate a huge amount 
of un-needed network traffic for large traversals.)

> Add cycle detection PostFilter
> --
>
> Key: SOLR-8935
> URL: https://issues.apache.org/jira/browse/SOLR-8935
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>
> in SOLR- cycle detection is done in the worker node. This ticket will 
> allow all graph traversals to push down cycle detection into the search 
> engine. This will eliminate a huge amount of un-needed network traffic for 
> large distributed graph traversals.



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

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

[jira] [Updated] (SOLR-8935) Add cycle detection PostFilter

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8935:
-
Description: in SOLR- cycle detection is done in the worker node. This 
ticket will allow all graph traversals to push down cycle detection into the 
search engine. This will eliminate a huge amount of un-needed network traffic 
for large traversals.  (was: in SOLR- cycle detection is done in the worker 
node. This ticket will allow all graph traversals, to push down cycle detection 
into the search engine. This will eliminate a huge amount of un-needed network 
traffic for large traversals.)

> Add cycle detection PostFilter
> --
>
> Key: SOLR-8935
> URL: https://issues.apache.org/jira/browse/SOLR-8935
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>
> in SOLR- cycle detection is done in the worker node. This ticket will 
> allow all graph traversals to push down cycle detection into the search 
> engine. This will eliminate a huge amount of un-needed network traffic for 
> large traversals.



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

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

[jira] [Resolved] (LUCENE-7169) Add Geo3DPoint.newSolidQuery

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7169.
-
Resolution: Won't Fix

Needs to implement GeoShape and doesn't currently, so this is not worth 
pursuing.

> Add Geo3DPoint.newSolidQuery
> 
>
> Key: LUCENE-7169
> URL: https://issues.apache.org/jira/browse/LUCENE-7169
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Karl Wright
>
> We should include the ability to search for solids as well in the general 
> API.  This capability is unique to Geo3D.



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

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

[jira] [Updated] (SOLR-8935) Add cycle detection PostFilter

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-8935:
-
Description: in SOLR- cycle detection is done in the worker node. This 
ticket will allow all graph traversals, to push down cycle detection into the 
search engine. This will eliminate a huge amount of un-needed network traffic 
for large traversals.  (was: in SOLR- cycle detection is done in the worker 
node. For this ticket and for all graph traversals, we can push cycle detection 
down into the search engine. This will eliminate a huge amount of un-needed 
network traffic for large traversals.)

> Add cycle detection PostFilter
> --
>
> Key: SOLR-8935
> URL: https://issues.apache.org/jira/browse/SOLR-8935
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>
> in SOLR- cycle detection is done in the worker node. This ticket will 
> allow all graph traversals, to push down cycle detection into the search 
> engine. This will eliminate a huge amount of un-needed network traffic for 
> large traversals.



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

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

[jira] [Created] (SOLR-8936) Push down the DISTINCT operation into the /export handler, to support exporting distinct edges during a graph traversal

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8936:


 Summary: Push down the DISTINCT operation into the /export 
handler, to support exporting distinct edges during a graph traversal
 Key: SOLR-8936
 URL: https://issues.apache.org/jira/browse/SOLR-8936
 Project: Solr
  Issue Type: New Feature
Reporter: Joel Bernstein


The /export handler sorts all results by specified fields as it streams out 
results. We can use the sort order to perform a reduce style distinct operation 
as docs are being sent out.

This can be used in the SQL handler, effectively removing the need for 
map_reduce mode SELECT DISTINCT operations.

But the primary driver for this is to export distinct edges during a graph 
traversal, which will eliminate a huge amount of network traffic during large 
traversals.



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

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

[jira] [Created] (SOLR-8935) Add cycle detection PostFilter

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-8935:


 Summary: Add cycle detection PostFilter
 Key: SOLR-8935
 URL: https://issues.apache.org/jira/browse/SOLR-8935
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein


in SOLR- cycle detection is done in the worker node. For this ticket and 
for all graph traversals, we can push cycle detection down into the search 
engine. This will eliminate a huge amount of un-needed network traffic for 
large traversals.



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

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

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

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7168:


bq. e.g. custom planet models/distance metrics/crazy shapes

Projections would be useful - and BKD is the right structure to handle them. We 
need to be careful where we put a lot of this logic though. There are other 
Apache projects that already do this kind of stuff very well (and maintain the 
logic along with the EPSG database). I'm not sure we want to necessarily 
duplicate this work. Support for some of this more "expert capability" makes 
more sense in spatial-extras where we can bring in third-party support (like 
SIS, ESRI). 

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



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

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

[jira] [Created] (LUCENE-7169) Add Geo3DPoint.newSolidQuery

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7169:
---

 Summary: Add Geo3DPoint.newSolidQuery
 Key: LUCENE-7169
 URL: https://issues.apache.org/jira/browse/LUCENE-7169
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Karl Wright


We should include the ability to search for solids as well in the general API.  
This capability is unique to Geo3D.





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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

I think (ultimately) we should have Geo3DPoint.java and whatever it uses in its 
newXXXQuery() methods is all we need, nothing more :)

Remember we can always choose to expose more advanced functionality at any 
time. We can revive things from git and so on. We can try to repackage things 
(but we must be careful this doesnt cause more harm than good) to be better.

We can add new methods like the newPathQuery (which seems useful and general) 
that are things Geo3D can do that nobody else can do: stuff like this is great. 

We can also try to start rounding out an expert API that does more stuff: make 
Custom3DPoint or Advanced3DPoint or whatever we want to call it that is even 
more expert: e.g. custom planet models/distance metrics/crazy shapes. I just 
think we should restrict ourselves to real use-cases there too to keep things 
bounded.

I do think we have to err towards simplicity rather than worrying about 
experts. But we can still make expert stuff possible. 


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



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

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

[jira] [Commented] (SOLR-8803) OOM killer for Windows

[Binoy Dalal (JIRA)]

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

Binoy Dalal commented on SOLR-8803:
---

The flag is being picked up. A simple script that opens up a new command prompt 
does work.
So there is something wrong with the script when being called from solr. I'll 
try and debug to see what I'm missing here.

> OOM killer for Windows
> --
>
> Key: SOLR-8803
> URL: https://issues.apache.org/jira/browse/SOLR-8803
> Project: Solr
>  Issue Type: Improvement
>Reporter: Binoy Dalal
>Priority: Minor
> Attachments: SOLR-8803.patch, SOLR-8803.patch, oom_win.bat, 
> oom_win.cmd
>
>
> Solr on windows does not currently have a script to kill the process on OOM 
> errors.
> The idea is to write a batch script that works like the OOM kill script for 
> Linux and kills the solr process on OOM errors while creating an OOM log file 
> like the one on Linux systems.



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

bq. Right but I think we should try to simplify and reduce to the subset of 
logic that lucene needs to index and run its queries. We sorta have to do this, 
otherwise everything is completely open-ended ("well someone MIGHT have a use 
case") and we can't do APIs that way.

Yes, but it's just another shape.  Presumably you would not want to peel all of 
the shapes that aren't explicitly used by lucene-core out of the package?  I'd 
make the case for it on that basis alone.

If the "shape API footprint" is worrying you, we should discuss what shapes you 
think people will want to search for and what they won't, and then come up with 
a place for the shapes you don't like to live.  I'm less willing to judge that 
up front, however.




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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

{quote}
While XYZSolids are used by Lucene for BKD trees, I cannot say whether or not 
they would never be used by anyone else. The functionality is general, after 
all. 
{quote}

Right but I think we should try to simplify and reduce to the subset of logic 
that lucene needs to index and run its queries. We sorta have to do this, 
otherwise everything is completely open-ended ("well someone MIGHT have a use 
case") and we can't do APIs that way.

{quote}
I already made all the variants of XYZSolids package-private and 
lucene.internal. Is this enough to hide this complication from users?
{quote}

This is a good step and will at least defer me from trying too hard to simplify 
this stuff for now. Because it at least hides all this complexity from the user 
and that is the worst of the worst. Having some hairy stuff that is 
package-private is much less evil.

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

While XYZSolids are used by Lucene for BKD trees, I cannot say whether or not 
they would never be used by anyone else.  The functionality is general, after 
all.  In fact, the functionality was introduced because we had issues without 
it from the BKD tree implementation.  Perhaps those problems are fixed but 
whether degeneracy support *for that use case* is needed still depends strongly 
on the relative values of the "known" minimum 32-bit resolution of the tree and 
the actual value of Vector.MINIMUM_RESOLUTION.  So at the moment I'm not even 
convinced that the BKD implementation doesn't need degeneracy support.

I already made all the variants of XYZSolids package-private and 
lucene.internal.  Is this enough to hide this complication from users?

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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

And I have not tested the numbers involved either: I am just looking to 
simplify.

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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

I think this is the wrong way to look at it? If some of these situations are 
merely theoretical and cannot actually happen in lucene, then why do we need to 
support them?

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

Handling geometric degeneracy conditions properly, I agree, should happen 
regardless of what is being done elsewhere in Lucene.


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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

Its an important implementation detail. If we can make simplifications around 
things like this, then I think we should.

We can't just let quantization *only* make things more complicated.

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

That's an implementation detail.  All of the stuff in spatial3D/geom knows 
nothing about that and operates from strict principles of the math alone.


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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

But we do not have the numeric resolution of a double. It is less, only 32 bits.

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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

"Immeasurably" means within the resolution of the mathematics underlying 
planes, given the numerical resolution of a double.  It is summarized with the 
constant Vector.MINIMUM_RESOLUTION.



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



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

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

I don't see how it can be immeasurably small. We use a 32-bit quantization so 
we know exactly how small things can be?


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



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7168:
-

Hi Robert,

The reason for the 8 implementations is because there are degeneracy 
conditions.  Specifically, when a dimension is immeasurably small, we still 
need to determine set membership but only when it is on the plane that 
represents that dimension.  it's dicey to use two planes that are right on top 
of each other for determining "in set" in that case.  There is a degeneracy 
condition for a single point as well.

This is independent of the BKD implementation's quantization effects; Geo3D 
would want to do this anyway.  There are similar issues with bounding boxes 
that have degeneracies of various kinds.


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



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

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

[JENKINS] Lucene-Solr-Tests-6.0 - Build # 6 - Still Failing

[Apache Jenkins Server]

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

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

Error Message:
replicaCount expected:<0> but was:<1>

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

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

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7168:
-

It seems also that the current test design (testing unquantized values, and 
trying to "correct" for quantization to satisfy that) may cause needless 
complexity in Geo3D? 

Because the query then tries to "correct for quantization", it computes a 
min/max in all 3 dimensions, and then passes these 6 values to a solid factory 
that returns one of 8 possible xyzsolid implementations that try to "correct" 
for it.


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



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

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

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

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7168:
--

 Summary: Remove geo3d test leniency
 Key: LUCENE-7168
 URL: https://issues.apache.org/jira/browse/LUCENE-7168
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless


Today the test hides possible failures by leniently handling quantization 
issues.

We should fix it to do what geo2d tests now do: pre-quantized indexed points, 
but don't quantize query shapes.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7167:


I opened LUCENE-7168 for the test quantization.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7167:


I'll open a separate issue to remove geo3d test leniency.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

Re: lucene-solr:lucene-7157: LUCENE_7157: current patch

[Michael McCandless]

I will remove this branch.

Let's debate on the issue instead:
https://issues.apache.org/jira/browse/LUCENE-7157

Mike McCandless

http://blog.mikemccandless.com


On Sun, Apr 3, 2016 at 9:08 AM, Robert Muir  wrote:
> I'm not going to argue with you about why GeoConcavePolygon.java
> should not be public.
>
> Instead, you can convince me why it should be. public should not be the 
> default.
>
> On Sun, Apr 3, 2016 at 8:56 AM, Karl Wright  wrote:

>> No, I responded to the commit, because I already said on the ticket "i
>> don't think a user should have to know about concaveness", and then I
>> see GeoConcavePolygon.java added in this commit
>> <<
>>
>> The API that you helped define uses point clockwise/counter-clockwise
>> ordering to determine what side of the polygon edge is the "inside" of the
>> polygon.  I do not see how you can finesse this.
>>
>> Users use GeoPolygonFactory.makeGeoPolygon() to construct complex polygons.
>> They don't need to know about convexity or concavity.  They only need to
>> know about point ordering.
>>
>> So I fail to understand your point?
>>
>> Karl
>>
>>
>>
>> <<
>>
>>
>>
>> On Sun, Apr 3, 2016 at 8:48 AM, Robert Muir  wrote:
>>>
>>> No, I responded to the commit, because I already said on the ticket "i
>>> don't think a user should have to know about concaveness", and then I
>>> see GeoConcavePolygon.java added in this commit
>>>
>>>
>>>
>>> On Sun, Apr 3, 2016 at 8:40 AM, Karl Wright  wrote:
>>> > Hi Robert,
>>> >
>>> > In case you are unaware, I am not a committer.  I just uploaded the
>>> > patch.
>>> > Mike created a branch to allow us to collaborate more easily.  I do not
>>> > think anything has hit trunk -- but if it did, I'm unaware of it.
>>> >
>>> > Do you want me to remove the patch from the ticket?
>>> >
>>> > Karl
>>> >
>>> >
>>> > On Sun, Apr 3, 2016 at 8:37 AM, Robert Muir  wrote:
>>> >>
>>> >> My concern has everything to do with the ticket. Please back the change
>>> >> out.
>>> >>
>>> >> We are an API and so adding a public class is a very serious thing.
>>> >>
>>> >> On Sun, Apr 3, 2016 at 8:14 AM, Karl Wright  wrote:
>>> >> > Robert,
>>> >> >
>>> >> > Your concern is noted but that has nothing really to do with this
>>> >> > ticket.
>>> >> > Would you mind creating another ticket for re-engineering Geo3D so
>>> >> > that
>>> >> > it
>>> >> > has fewer public classes?  Doing things piecemeal as part of another
>>> >> > ticket,
>>> >> > especially one as complex as this one, does not seem like the right
>>> >> > way
>>> >> > to
>>> >> > go.
>>> >> >
>>> >> > Karl
>>> >> >
>>> >> >
>>> >> > On Sun, Apr 3, 2016 at 8:09 AM, Robert Muir  wrote:
>>> >> >>
>>> >> >> Why does this change need to add so many public classes? I already
>>> >> >> mentioned on the issue: the user need not concern themselves with
>>> >> >> these impl details.
>>> >> >>
>>> >> >> It is frustrating that this package has 60 public classes (and if
>>> >> >> everything is public, why the hell does it need factories?). Can we
>>> >> >> please make these classes package private? If this cannot be done in
>>> >> >> an obvious way, then can you please back out the commit and we do
>>> >> >> whatever redesign is necessary. Certainly, I think we can all agree
>>> >> >> that having both public factories and making the things they create
>>> >> >> public too (which all of this is impl detail) is completely bogus.
>>> >> >>
>>> >> >> I know that I will frustrate you with this response, but we have to
>>> >> >> stop the patient from bleeding or it will never get better.
>>> >> >>
>>> >> >> On Sat, Apr 2, 2016 at 5:58 PM,   wrote:
>>> >> >> > Repository: lucene-solr
>>> >> >> > Updated Branches:
>>> >> >> >   refs/heads/lucene-7157 [created] 98e04cf49
>>> >> >> >
>>> >> >> >
>>> >> >> > LUCENE_7157: current patch
>>> >> >> >
>>> >> >> >
>>> >> >> > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>>> >> >> > Commit:
>>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/98e04cf4
>>> >> >> > Tree:
>>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/98e04cf4
>>> >> >> > Diff:
>>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/98e04cf4
>>> >> >> >
>>> >> >> > Branch: refs/heads/lucene-7157
>>> >> >> > Commit: 98e04cf49c7a4d5a551679792da7c3fa9559013f
>>> >> >> > Parents: 9ed95bc
>>> >> >> > Author: Mike McCandless 
>>> >> >> > Authored: Sat Apr 2 18:00:43 2016 -0400
>>> >> >> > Committer: Mike McCandless 
>>> >> >> > Committed: Sat Apr 2 18:00:43 2016 -0400
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> >  .../org/apache/lucene/spatial3d/Geo3DPoint.java |   8 +-
>>> >> >> >  .../spatial3d/geom/GeoConcavePolygon.java   | 380 
>>> >> >> >  .../lucene/spatial3d/geom/GeoConvexPolygon.java | 162 +++-
>>> >> >> >  .../spatial3d/geom/GeoPolygonFactory.java   | 857
>>> >> >> > ---
>>> >> >> >  .../luc

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

+1 for this patch. It reduces the surface area of geo3d api by half. Its an 
improvement.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

{quote}
Yes, that's what I thought we were doing, but the BKD work is Mike's, not mine.
{quote}

I wasn't trying to blame anyone, just the code :)
It does not matter if you did it, or mike did it, or I did it. I just think we 
can simplify it and test better.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Updated] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7167:

Attachment: LUCENE-7167.diff

Make package private the classes we don't expect people to extend or even to 
know about.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
> Attachments: LUCENE-7167.diff
>
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (SOLR-8803) OOM killer for Windows

[Binoy Dalal (JIRA)]

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

Binoy Dalal commented on SOLR-8803:
---

Tried on Solr 5.3.1, 5.4.1, 4.10.4
Still facing the same issue, with relative and absolute path both specified in 
the start script.
I think I'm doing something wrong since I've worked on 4.10.4 before (on Linux 
though) and that does call the OOM script and OOMEs.
I'll keep digging.

> OOM killer for Windows
> --
>
> Key: SOLR-8803
> URL: https://issues.apache.org/jira/browse/SOLR-8803
> Project: Solr
>  Issue Type: Improvement
>Reporter: Binoy Dalal
>Priority: Minor
> Attachments: SOLR-8803.patch, SOLR-8803.patch, oom_win.bat, 
> oom_win.cmd
>
>
> Solr on windows does not currently have a script to kill the process on OOM 
> errors.
> The idea is to write a batch script that works like the OOM kill script for 
> Linux and kills the solr process on OOM errors while creating an OOM log file 
> like the one on Linux systems.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

bq. We decide to use a lossy encoding, that is fine, but we should not try to 
"correct for it" at query time: we just have to accept that but then treat it 
as if the user handed us that truncated value from there on out and not allow 
any more lossiness/error to sneak in.

Yes, that's what I thought we were doing, but the BKD work is Mike's, not mine.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7167:


bq. Michael McCandless: You wrote the test – can you help clarify please?

I think we should remove this test's leniency, the same way we did in the geo2d 
tests, i.e. quantize at index time but not at query time?



> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

That is fine, I just want us to make progress on simplifying the API.

As far as the edge case / quantization handling, again I think we are doing the 
complete wrong thing here:

My problem is right here: 
https://github.com/apache/lucene-solr/blob/master/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/PointInGeo3DShapeQuery.java#L126-L135

We truncated the users data but we should not try to "correct" for that, it 
just makes things complicated for no good reason (and since we throw out edge 
cases, all this complexity IMO is basically untested). We decide to use a lossy 
encoding, that is fine, but we should not try to "correct for it" at query 
time: we just have to accept that but then treat it as if the user handed us 
that truncated value from there on out and not allow any more lossiness/error 
to sneak in.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Comment Edited] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright edited comment on LUCENE-7167 at 4/3/16 1:27 PM:
-

This clause was added to the test alone, because the quantization can, in 
theory, pull a point  to a slightly different place, and therefore the test 
(which bases its evaluation on the raw, unquantized point) can falsely claim 
that the point should be in (when it shouldn't) or out (when it shouldn't).  
Once the point is indexed though the quantized (x,y,z) *is* the benchmark, not 
the raw unquantized value.  Geo3D is correct either way -- it doesn't lie, it 
tells you whether the point is on or out, period.

So what you are looking at is code explicitly for testing, nothing more.

[~mikemccand]: You wrote the test -- can you help clarify please?



was (Author: kwri...@metacarta.com):
This clause was added to the test alone, because the quantization can, in 
theory, pull a point  to a slightly different place, and therefore the test 
(which bases its evaluation on the raw, unquantized point) can falsely claim 
that the point should be in (when it shouldn't) or out (when it shouldn't).  
Once the point is indexed though the quantized (x,y,z) *is* the benchmark, not 
the raw unquantized value.  Geo3D is correct either way -- it doesn't lie, it 
tells you whether the point is on or out, period.

So what you are looking at is code explicitly for testing, nothing more.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

I would be happy to do that but there are several commits backed up already and 
I'd prefer to submit this as a separate patch.  Is that acceptable to you?


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

This clause was added to the test alone, because the quantization can, in 
theory, pull a point  to a slightly different place, and therefore the test 
(which bases its evaluation on the raw, unquantized point) can falsely claim 
that the point should be in (when it shouldn't) or out (when it shouldn't).  
Once the point is indexed though the quantized (x,y,z) *is* the benchmark, not 
the raw unquantized value.  Geo3D is correct either way -- it doesn't lie, it 
tells you whether the point is on or out, period.

So what you are looking at is code explicitly for testing, nothing more.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

{quote}
Some classes that are public that don't need to be:

(1) Any of the xxxSolid classes
(2) Rectangle variants
(3) Any shape that is constructed with a factory

Some classes that are public that will need to remain so (IMO):

(1) Interfaces
(2) Distance calculators
(3) Factory classes
(4) Bounds calculators
{quote}

Great, can we start with this idea and see what it looks like? Maybe this step 
can greatly simplify the API.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

My issue with the edge case testing is right here:

https://github.com/apache/lucene-solr/blob/master/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/TestGeo3DPoint.java#L437-L440


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

bq. The test explicitly discards any edge cases.

(1) Can you define what you consider to be an edge case?
(2) Are you talking about the BKD implementation, or Geo3D, when you claim it 
is basically untested?  I find this extremely hard to believe unless you are in 
essence trying to fold both implementations together in your mind.  It was 
first tested heavily in the context of spatial, entirely outside of any Lucene 
considerations at all.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

Re: lucene-solr:lucene-7157: LUCENE_7157: current patch

[Robert Muir]

I'm not going to argue with you about why GeoConcavePolygon.java
should not be public.

Instead, you can convince me why it should be. public should not be the default.

On Sun, Apr 3, 2016 at 8:56 AM, Karl Wright  wrote:
>>>
> No, I responded to the commit, because I already said on the ticket "i
> don't think a user should have to know about concaveness", and then I
> see GeoConcavePolygon.java added in this commit
> <<
>
> The API that you helped define uses point clockwise/counter-clockwise
> ordering to determine what side of the polygon edge is the "inside" of the
> polygon.  I do not see how you can finesse this.
>
> Users use GeoPolygonFactory.makeGeoPolygon() to construct complex polygons.
> They don't need to know about convexity or concavity.  They only need to
> know about point ordering.
>
> So I fail to understand your point?
>
> Karl
>
>
>
> <<
>
>
>
> On Sun, Apr 3, 2016 at 8:48 AM, Robert Muir  wrote:
>>
>> No, I responded to the commit, because I already said on the ticket "i
>> don't think a user should have to know about concaveness", and then I
>> see GeoConcavePolygon.java added in this commit
>>
>>
>>
>> On Sun, Apr 3, 2016 at 8:40 AM, Karl Wright  wrote:
>> > Hi Robert,
>> >
>> > In case you are unaware, I am not a committer.  I just uploaded the
>> > patch.
>> > Mike created a branch to allow us to collaborate more easily.  I do not
>> > think anything has hit trunk -- but if it did, I'm unaware of it.
>> >
>> > Do you want me to remove the patch from the ticket?
>> >
>> > Karl
>> >
>> >
>> > On Sun, Apr 3, 2016 at 8:37 AM, Robert Muir  wrote:
>> >>
>> >> My concern has everything to do with the ticket. Please back the change
>> >> out.
>> >>
>> >> We are an API and so adding a public class is a very serious thing.
>> >>
>> >> On Sun, Apr 3, 2016 at 8:14 AM, Karl Wright  wrote:
>> >> > Robert,
>> >> >
>> >> > Your concern is noted but that has nothing really to do with this
>> >> > ticket.
>> >> > Would you mind creating another ticket for re-engineering Geo3D so
>> >> > that
>> >> > it
>> >> > has fewer public classes?  Doing things piecemeal as part of another
>> >> > ticket,
>> >> > especially one as complex as this one, does not seem like the right
>> >> > way
>> >> > to
>> >> > go.
>> >> >
>> >> > Karl
>> >> >
>> >> >
>> >> > On Sun, Apr 3, 2016 at 8:09 AM, Robert Muir  wrote:
>> >> >>
>> >> >> Why does this change need to add so many public classes? I already
>> >> >> mentioned on the issue: the user need not concern themselves with
>> >> >> these impl details.
>> >> >>
>> >> >> It is frustrating that this package has 60 public classes (and if
>> >> >> everything is public, why the hell does it need factories?). Can we
>> >> >> please make these classes package private? If this cannot be done in
>> >> >> an obvious way, then can you please back out the commit and we do
>> >> >> whatever redesign is necessary. Certainly, I think we can all agree
>> >> >> that having both public factories and making the things they create
>> >> >> public too (which all of this is impl detail) is completely bogus.
>> >> >>
>> >> >> I know that I will frustrate you with this response, but we have to
>> >> >> stop the patient from bleeding or it will never get better.
>> >> >>
>> >> >> On Sat, Apr 2, 2016 at 5:58 PM,   wrote:
>> >> >> > Repository: lucene-solr
>> >> >> > Updated Branches:
>> >> >> >   refs/heads/lucene-7157 [created] 98e04cf49
>> >> >> >
>> >> >> >
>> >> >> > LUCENE_7157: current patch
>> >> >> >
>> >> >> >
>> >> >> > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> >> >> > Commit:
>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/98e04cf4
>> >> >> > Tree:
>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/98e04cf4
>> >> >> > Diff:
>> >> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/98e04cf4
>> >> >> >
>> >> >> > Branch: refs/heads/lucene-7157
>> >> >> > Commit: 98e04cf49c7a4d5a551679792da7c3fa9559013f
>> >> >> > Parents: 9ed95bc
>> >> >> > Author: Mike McCandless 
>> >> >> > Authored: Sat Apr 2 18:00:43 2016 -0400
>> >> >> > Committer: Mike McCandless 
>> >> >> > Committed: Sat Apr 2 18:00:43 2016 -0400
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> >  .../org/apache/lucene/spatial3d/Geo3DPoint.java |   8 +-
>> >> >> >  .../spatial3d/geom/GeoConcavePolygon.java   | 380 
>> >> >> >  .../lucene/spatial3d/geom/GeoConvexPolygon.java | 162 +++-
>> >> >> >  .../spatial3d/geom/GeoPolygonFactory.java   | 857
>> >> >> > ---
>> >> >> >  .../lucene/spatial3d/geom/SidedPlane.java   |  20 +-
>> >> >> >  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  78 +-
>> >> >> >  6 files changed, 1355 insertions(+), 150 deletions(-)
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> 

[jira] [Commented] (SOLR-8803) OOM killer for Windows

[Binoy Dalal (JIRA)]

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

Binoy Dalal commented on SOLR-8803:
---

I noticed that very silly mistake and corrected it. But still nothing. I'll put 
up the updated patch in some time.
I've still to try on 4.10.4 so will update the thread with those results as 
well.

> OOM killer for Windows
> --
>
> Key: SOLR-8803
> URL: https://issues.apache.org/jira/browse/SOLR-8803
> Project: Solr
>  Issue Type: Improvement
>Reporter: Binoy Dalal
>Priority: Minor
> Attachments: SOLR-8803.patch, SOLR-8803.patch, oom_win.bat, 
> oom_win.cmd
>
>
> Solr on windows does not currently have a script to kill the process on OOM 
> errors.
> The idea is to write a batch script that works like the OOM kill script for 
> Linux and kills the solr process on OOM errors while creating an OOM log file 
> like the one on Linux systems.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

Some classes that are public that don't need to be:

(1) Any of the xxxSolid classes
(2) Rectangle variants
(3) Any shape that is constructed with a factory

Some classes that are public that will need to remain so (IMO):

(1) Interfaces
(2) Distance calculators
(3) Factory classes
(4) Bounds calculators



> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

Sorry karl, it has not been beasted to death. Please don't make statements like 
this that are 100% false.

The test explicitly discards any edge cases. Geo3D is basically untested.

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

Would you make allowances for opening the API's enough to (say) compute inside 
and outside distances?  How about allowing for custom shape development?



> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

bq. So if its gonna do that, why does it do this ridiculous garbage to try to 
"correct" for quantization. If we truncate someone's data at index time this 
cannot be undone. It cannot be corrected for. So making this complex 
XYZSolidFactory that, produces one of 8 possible XYZ's (which are all public 
too why have a factory!!!), this is so complex to try to "correct" for 
damage we have already done.

I honestly don't know what the heck you are talking about here.

Would you care to present a case that you think isn't going to work?  I 
challenge that it is broken in any way; it's been beasted practically to death. 
 And you clearly don't understand at all how Geo3D works, so maybe you and I 
ought to talk a bit before you conclude stuff like this.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

{quote}
Robert Muir In this ticket, please make your wishes clear as to what 
constitutes the public API and what constitutes the private one.
{quote}

A public api is one that users should use!

> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

I'll list some one problem:
 
Ryan already mentioned, why do we need all these solid classes? I looked at 
this part of geo3d recently because I was looking at how the various 2d 
implementations handled quantization and rounding, and so I thought, maybe 
geo3d needs to be fixed too in that area.

I had no idea what i was in for: geo3d explicitly discards any edge case 
testing. So if its gonna do that, why does it do this ridiculous garbage to try 
to "correct" for quantization. If we truncate someone's data at index time this 
cannot be undone. It cannot be corrected for. So making this complex 
XYZSolidFactory that, produces one of 8 possible XYZ's (which are all public 
too why have a factory!!!), this is so complex to try to "correct" for 
damage we have already done.

It does not work and if any edge cases were being tested at all we should see 
that. Removing all of this would be a great simplification for geo3d, it would 
remove a ton of public classes.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Comment Edited] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir edited comment on LUCENE-7167 at 4/3/16 12:56 PM:
--

I'll list one solvable problem:
 
Ryan already mentioned, why do we need all these solid classes? I looked at 
this part of geo3d recently because I was looking at how the various 2d 
implementations handled quantization and rounding, and so I thought, maybe 
geo3d needs to be fixed too in that area.

I had no idea what i was in for: geo3d explicitly discards any edge case 
testing. So if its gonna do that, why does it do this ridiculous garbage to try 
to "correct" for quantization. If we truncate someone's data at index time this 
cannot be undone. It cannot be corrected for. So making this complex 
XYZSolidFactory that, produces one of 8 possible XYZ's (which are all public 
too why have a factory!!!), this is so complex to try to "correct" for 
damage we have already done.

It does not work and if any edge cases were being tested at all we should see 
that. Removing all of this would be a great simplification for geo3d, it would 
remove a ton of public classes.



was (Author: rcmuir):
I'll list some one problem:
 
Ryan already mentioned, why do we need all these solid classes? I looked at 
this part of geo3d recently because I was looking at how the various 2d 
implementations handled quantization and rounding, and so I thought, maybe 
geo3d needs to be fixed too in that area.

I had no idea what i was in for: geo3d explicitly discards any edge case 
testing. So if its gonna do that, why does it do this ridiculous garbage to try 
to "correct" for quantization. If we truncate someone's data at index time this 
cannot be undone. It cannot be corrected for. So making this complex 
XYZSolidFactory that, produces one of 8 possible XYZ's (which are all public 
too why have a factory!!!), this is so complex to try to "correct" for 
damage we have already done.

It does not work and if any edge cases were being tested at all we should see 
that. Removing all of this would be a great simplification for geo3d, it would 
remove a ton of public classes.


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 116 - Still Failing

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.client.solrj.ConnectionReuseTest.test

Error Message:
We expected all communication via streaming client to use one connection! 
expected=65 got=62

Stack Trace:
java.lang.AssertionError: We expected all communication via streaming client to 
use one connection! expected=65 got=62
at 
__randomizedtesting.SeedInfo.seed([1504F70351AF05D7:9D50C8D9FF53682F]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.client.solrj.ConnectionReuseTest.test(ConnectionReuseTest.java:150)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7167:
-

Why would we remove it when we can fix it?


> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

Re: lucene-solr:lucene-7157: LUCENE_7157: current patch

[Robert Muir]

No, I responded to the commit, because I already said on the ticket "i
don't think a user should have to know about concaveness", and then I
see GeoConcavePolygon.java added in this commit



On Sun, Apr 3, 2016 at 8:40 AM, Karl Wright  wrote:
> Hi Robert,
>
> In case you are unaware, I am not a committer.  I just uploaded the patch.
> Mike created a branch to allow us to collaborate more easily.  I do not
> think anything has hit trunk -- but if it did, I'm unaware of it.
>
> Do you want me to remove the patch from the ticket?
>
> Karl
>
>
> On Sun, Apr 3, 2016 at 8:37 AM, Robert Muir  wrote:
>>
>> My concern has everything to do with the ticket. Please back the change
>> out.
>>
>> We are an API and so adding a public class is a very serious thing.
>>
>> On Sun, Apr 3, 2016 at 8:14 AM, Karl Wright  wrote:
>> > Robert,
>> >
>> > Your concern is noted but that has nothing really to do with this
>> > ticket.
>> > Would you mind creating another ticket for re-engineering Geo3D so that
>> > it
>> > has fewer public classes?  Doing things piecemeal as part of another
>> > ticket,
>> > especially one as complex as this one, does not seem like the right way
>> > to
>> > go.
>> >
>> > Karl
>> >
>> >
>> > On Sun, Apr 3, 2016 at 8:09 AM, Robert Muir  wrote:
>> >>
>> >> Why does this change need to add so many public classes? I already
>> >> mentioned on the issue: the user need not concern themselves with
>> >> these impl details.
>> >>
>> >> It is frustrating that this package has 60 public classes (and if
>> >> everything is public, why the hell does it need factories?). Can we
>> >> please make these classes package private? If this cannot be done in
>> >> an obvious way, then can you please back out the commit and we do
>> >> whatever redesign is necessary. Certainly, I think we can all agree
>> >> that having both public factories and making the things they create
>> >> public too (which all of this is impl detail) is completely bogus.
>> >>
>> >> I know that I will frustrate you with this response, but we have to
>> >> stop the patient from bleeding or it will never get better.
>> >>
>> >> On Sat, Apr 2, 2016 at 5:58 PM,   wrote:
>> >> > Repository: lucene-solr
>> >> > Updated Branches:
>> >> >   refs/heads/lucene-7157 [created] 98e04cf49
>> >> >
>> >> >
>> >> > LUCENE_7157: current patch
>> >> >
>> >> >
>> >> > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> >> > Commit:
>> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/98e04cf4
>> >> > Tree:
>> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/98e04cf4
>> >> > Diff:
>> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/98e04cf4
>> >> >
>> >> > Branch: refs/heads/lucene-7157
>> >> > Commit: 98e04cf49c7a4d5a551679792da7c3fa9559013f
>> >> > Parents: 9ed95bc
>> >> > Author: Mike McCandless 
>> >> > Authored: Sat Apr 2 18:00:43 2016 -0400
>> >> > Committer: Mike McCandless 
>> >> > Committed: Sat Apr 2 18:00:43 2016 -0400
>> >> >
>> >> >
>> >> > --
>> >> >  .../org/apache/lucene/spatial3d/Geo3DPoint.java |   8 +-
>> >> >  .../spatial3d/geom/GeoConcavePolygon.java   | 380 
>> >> >  .../lucene/spatial3d/geom/GeoConvexPolygon.java | 162 +++-
>> >> >  .../spatial3d/geom/GeoPolygonFactory.java   | 857
>> >> > ---
>> >> >  .../lucene/spatial3d/geom/SidedPlane.java   |  20 +-
>> >> >  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  78 +-
>> >> >  6 files changed, 1355 insertions(+), 150 deletions(-)
>> >> >
>> >> > --
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/98e04cf4/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> >> >
>> >> > --
>> >> > diff --git
>> >> >
>> >> > a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> >> >
>> >> > b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> >> > index 45e17b7..f0f2020 100644
>> >> > ---
>> >> >
>> >> > a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> >> > +++
>> >> >
>> >> > b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> >> > @@ -22,6 +22,7 @@ import java.util.ArrayList;
>> >> >  import org.apache.lucene.document.Field;
>> >> >  import org.apache.lucene.document.FieldType;
>> >> >  import org.apache.lucene.index.PointValues;
>> >> > +import org.apache.lucene.spatial3d.geom.Vector;
>> >> >  import org.apache.lucene.spatial3d.geom.GeoPoint;
>> >> >  import org.apache.lucene.spatial3d.geom.GeoShape;
>> >> >  import org.apache.lucene.spatial3d.geom.PlanetModel;
>> >> > @@ -149,11 +150,8 @@ public final class Geo3DPoint extends Field {
>> >> >checkLongitude(longitude);
>> >> >polyPoints.add(new GeoPoint(PlanetModel.WGS84,
>> >> > fromDegrees

[jira] [Commented] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7167:
-

[~rcmuir]  In this ticket, please make your wishes clear as to what constitutes 
the public API and what constitutes the private one.

I am not adverse to removing geo3D from Lucene entirely if that is the decision 
of the team.  Seems like a waste but that is up to the PMC.

[~mikemccand]: You also have put a great deal of time in the the Geo3D 
implementation, and I'm sure you have thoughts about how this should proceed.



> Re-engineer or remove all of geo3D
> --
>
> Key: LUCENE-7167
> URL: https://issues.apache.org/jira/browse/LUCENE-7167
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Karl Wright
>
> Geo3D has led to a lot of consternation because it has a relatively open API. 
>  The task is to either drastically restrict it or remove the package entirely.



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

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

[jira] [Created] (LUCENE-7167) Re-engineer or remove all of geo3D

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7167:
---

 Summary: Re-engineer or remove all of geo3D
 Key: LUCENE-7167
 URL: https://issues.apache.org/jira/browse/LUCENE-7167
 Project: Lucene - Core
  Issue Type: Task
Reporter: Karl Wright


Geo3D has led to a lot of consternation because it has a relatively open API.  
The task is to either drastically restrict it or remove the package entirely.





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

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

Re: lucene-solr:lucene-7157: LUCENE_7157: current patch

[Robert Muir]

My concern has everything to do with the ticket. Please back the change out.

We are an API and so adding a public class is a very serious thing.

On Sun, Apr 3, 2016 at 8:14 AM, Karl Wright  wrote:
> Robert,
>
> Your concern is noted but that has nothing really to do with this ticket.
> Would you mind creating another ticket for re-engineering Geo3D so that it
> has fewer public classes?  Doing things piecemeal as part of another ticket,
> especially one as complex as this one, does not seem like the right way to
> go.
>
> Karl
>
>
> On Sun, Apr 3, 2016 at 8:09 AM, Robert Muir  wrote:
>>
>> Why does this change need to add so many public classes? I already
>> mentioned on the issue: the user need not concern themselves with
>> these impl details.
>>
>> It is frustrating that this package has 60 public classes (and if
>> everything is public, why the hell does it need factories?). Can we
>> please make these classes package private? If this cannot be done in
>> an obvious way, then can you please back out the commit and we do
>> whatever redesign is necessary. Certainly, I think we can all agree
>> that having both public factories and making the things they create
>> public too (which all of this is impl detail) is completely bogus.
>>
>> I know that I will frustrate you with this response, but we have to
>> stop the patient from bleeding or it will never get better.
>>
>> On Sat, Apr 2, 2016 at 5:58 PM,   wrote:
>> > Repository: lucene-solr
>> > Updated Branches:
>> >   refs/heads/lucene-7157 [created] 98e04cf49
>> >
>> >
>> > LUCENE_7157: current patch
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> > Commit:
>> > http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/98e04cf4
>> > Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/98e04cf4
>> > Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/98e04cf4
>> >
>> > Branch: refs/heads/lucene-7157
>> > Commit: 98e04cf49c7a4d5a551679792da7c3fa9559013f
>> > Parents: 9ed95bc
>> > Author: Mike McCandless 
>> > Authored: Sat Apr 2 18:00:43 2016 -0400
>> > Committer: Mike McCandless 
>> > Committed: Sat Apr 2 18:00:43 2016 -0400
>> >
>> > --
>> >  .../org/apache/lucene/spatial3d/Geo3DPoint.java |   8 +-
>> >  .../spatial3d/geom/GeoConcavePolygon.java   | 380 
>> >  .../lucene/spatial3d/geom/GeoConvexPolygon.java | 162 +++-
>> >  .../spatial3d/geom/GeoPolygonFactory.java   | 857
>> > ---
>> >  .../lucene/spatial3d/geom/SidedPlane.java   |  20 +-
>> >  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  78 +-
>> >  6 files changed, 1355 insertions(+), 150 deletions(-)
>> > --
>> >
>> >
>> >
>> > http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/98e04cf4/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> > --
>> > diff --git
>> > a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> > b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> > index 45e17b7..f0f2020 100644
>> > ---
>> > a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> > +++
>> > b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
>> > @@ -22,6 +22,7 @@ import java.util.ArrayList;
>> >  import org.apache.lucene.document.Field;
>> >  import org.apache.lucene.document.FieldType;
>> >  import org.apache.lucene.index.PointValues;
>> > +import org.apache.lucene.spatial3d.geom.Vector;
>> >  import org.apache.lucene.spatial3d.geom.GeoPoint;
>> >  import org.apache.lucene.spatial3d.geom.GeoShape;
>> >  import org.apache.lucene.spatial3d.geom.PlanetModel;
>> > @@ -149,11 +150,8 @@ public final class Geo3DPoint extends Field {
>> >checkLongitude(longitude);
>> >polyPoints.add(new GeoPoint(PlanetModel.WGS84,
>> > fromDegrees(latitude), fromDegrees(longitude)));
>> >  }
>> > -// We don't know what the sense of the polygon is without providing
>> > the index of one vertex we know to be convex.
>> > -// Since that doesn't fit with the "super-simple API" requirements,
>> > we just use the index of the first one, and people have to just
>> > -// know to do it that way.
>> > -final int convexPointIndex = 0;
>> > -final GeoShape shape =
>> > GeoPolygonFactory.makeGeoPolygon(PlanetModel.WGS84, polyPoints,
>> > convexPointIndex);
>> > +// We use the polygon constructor that looks at point order.
>> > +final GeoShape shape =
>> > GeoPolygonFactory.makeGeoPolygon(PlanetModel.WGS84, polyPoints, null);
>> >  return newShapeQuery(field, shape);
>> >}
>> >
>> >
>> >
>> > http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/98e04cf4/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoConcavePolygon.java
>> > ---

[jira] [Commented] (SOLR-8812) ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-8812:


How about initiating a 5.5.1 and 6.0.1 release immediately after the 6.0 
release?

> ExtendedDismaxQParser (edismax) ignores Boolean OR when q.op=AND
> 
>
> Key: SOLR-8812
> URL: https://issues.apache.org/jira/browse/SOLR-8812
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 5.5
>Reporter: Ryan Steinberg
>Assignee: Erick Erickson
>Priority: Blocker
> Fix For: 6.0, 5.5.1
>
> Attachments: SOLR-8812.patch, SOLR-8812.patch
>
>
> The edismax parser ignores Boolean OR in queries when q.op=AND. This behavior 
> is new to Solr 5.5.0 and an unexpected major change.
> Example:
>   "q": "id:12345 OR zz",
>   "defType": "edismax",
>   "q.op": "AND",
> where "12345" is a known document ID and "zz" is a string NOT present 
> in my data
> Version 5.5.0 produces zero results:
> "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+((id:12345 
> DisjunctionMaxQuery((text:zz)))~2))/no_coord",
> "parsedquery_toString": "+((id:12345 (text:zz))~2)",
> "explain": {},
> "QParser": "ExtendedDismaxQParser"
> Version 5.4.0 produces one result as expected
>   "rawquerystring": "id:12345 OR zz",
> "querystring": "id:12345 OR zz",
> "parsedquery": "(+(id:12345 
> DisjunctionMaxQuery((text:zz/no_coord",
> "parsedquery_toString": "+(id:12345 (text:zz))"
> "explain": {},
> "QParser": "ExtendedDismaxQParser"



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

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

Re: lucene-solr:lucene-7157: LUCENE_7157: current patch

[Robert Muir]

Why does this change need to add so many public classes? I already
mentioned on the issue: the user need not concern themselves with
these impl details.

It is frustrating that this package has 60 public classes (and if
everything is public, why the hell does it need factories?). Can we
please make these classes package private? If this cannot be done in
an obvious way, then can you please back out the commit and we do
whatever redesign is necessary. Certainly, I think we can all agree
that having both public factories and making the things they create
public too (which all of this is impl detail) is completely bogus.

I know that I will frustrate you with this response, but we have to
stop the patient from bleeding or it will never get better.

On Sat, Apr 2, 2016 at 5:58 PM,   wrote:
> Repository: lucene-solr
> Updated Branches:
>   refs/heads/lucene-7157 [created] 98e04cf49
>
>
> LUCENE_7157: current patch
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/98e04cf4
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/98e04cf4
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/98e04cf4
>
> Branch: refs/heads/lucene-7157
> Commit: 98e04cf49c7a4d5a551679792da7c3fa9559013f
> Parents: 9ed95bc
> Author: Mike McCandless 
> Authored: Sat Apr 2 18:00:43 2016 -0400
> Committer: Mike McCandless 
> Committed: Sat Apr 2 18:00:43 2016 -0400
>
> --
>  .../org/apache/lucene/spatial3d/Geo3DPoint.java |   8 +-
>  .../spatial3d/geom/GeoConcavePolygon.java   | 380 
>  .../lucene/spatial3d/geom/GeoConvexPolygon.java | 162 +++-
>  .../spatial3d/geom/GeoPolygonFactory.java   | 857 ---
>  .../lucene/spatial3d/geom/SidedPlane.java   |  20 +-
>  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  78 +-
>  6 files changed, 1355 insertions(+), 150 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/98e04cf4/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
> --
> diff --git 
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java 
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
> index 45e17b7..f0f2020 100644
> --- a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
> +++ b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/Geo3DPoint.java
> @@ -22,6 +22,7 @@ import java.util.ArrayList;
>  import org.apache.lucene.document.Field;
>  import org.apache.lucene.document.FieldType;
>  import org.apache.lucene.index.PointValues;
> +import org.apache.lucene.spatial3d.geom.Vector;
>  import org.apache.lucene.spatial3d.geom.GeoPoint;
>  import org.apache.lucene.spatial3d.geom.GeoShape;
>  import org.apache.lucene.spatial3d.geom.PlanetModel;
> @@ -149,11 +150,8 @@ public final class Geo3DPoint extends Field {
>checkLongitude(longitude);
>polyPoints.add(new GeoPoint(PlanetModel.WGS84, fromDegrees(latitude), 
> fromDegrees(longitude)));
>  }
> -// We don't know what the sense of the polygon is without providing the 
> index of one vertex we know to be convex.
> -// Since that doesn't fit with the "super-simple API" requirements, we 
> just use the index of the first one, and people have to just
> -// know to do it that way.
> -final int convexPointIndex = 0;
> -final GeoShape shape = 
> GeoPolygonFactory.makeGeoPolygon(PlanetModel.WGS84, polyPoints, 
> convexPointIndex);
> +// We use the polygon constructor that looks at point order.
> +final GeoShape shape = 
> GeoPolygonFactory.makeGeoPolygon(PlanetModel.WGS84, polyPoints, null);
>  return newShapeQuery(field, shape);
>}
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/98e04cf4/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoConcavePolygon.java
> --
> diff --git 
> a/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoConcavePolygon.java
>  
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoConcavePolygon.java
> new file mode 100644
> index 000..9c60f69
> --- /dev/null
> +++ 
> b/lucene/spatial3d/src/java/org/apache/lucene/spatial3d/geom/GeoConcavePolygon.java
> @@ -0,0 +1,380 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + * http://www.apache.org/licen

[jira] [Updated] (SOLR-8934) Spellchecker collaction should return in popular order

[Michael Solomon (JIRA)]

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

Michael Solomon updated SOLR-8934:
--
Priority: Minor  (was: Trivial)

> Spellchecker collaction should return in popular order
> --
>
> Key: SOLR-8934
> URL: https://issues.apache.org/jira/browse/SOLR-8934
> Project: Solr
>  Issue Type: Improvement
>  Components: spellchecker
>Affects Versions: 5.5.1
>Reporter: Michael Solomon
>Priority: Minor
>
> From what I understand solr execute queries to determine if the suggest 
> return results.
> [https://cwiki.apache.org/confluence/display/solr/Spell+Checking#SpellChecking-Thespellcheck.collateParameter]
> {quote}
> The spellcheck.collate parameter only returns collations that are guaranteed 
> to result in hits if re-queried, even when applying original fq parameters.
>  it would be great if solr will order the collations by numFound, so the 
> collations with more results appear first.
> {quote}
> i.e:
> spellcheck.q = prditive analytiycs
> spellcheck.maxCollations = 5
> spellcheck.count=0
> response:
> {code:xml}
> 
>   
>   false
>   
> positive analytic
> positive analytics
> predictive analytics
> primitive analytics
> punitive analytic
>   
> 
> {code}
> Obviesly that "predictive analytics" have more results from "positive 
> analytic".



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

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

[jira] [Created] (SOLR-8934) Spellchecker collaction should return in popular order

[Michael Solomon (JIRA)]

Michael Solomon created SOLR-8934:
-

 Summary: Spellchecker collaction should return in popular order
 Key: SOLR-8934
 URL: https://issues.apache.org/jira/browse/SOLR-8934
 Project: Solr
  Issue Type: Improvement
  Components: spellchecker
Affects Versions: 5.5.1
Reporter: Michael Solomon
Priority: Trivial


>From what I understand solr execute queries to determine if the suggest return 
>results.
[https://cwiki.apache.org/confluence/display/solr/Spell+Checking#SpellChecking-Thespellcheck.collateParameter]
{quote}
The spellcheck.collate parameter only returns collations that are guaranteed to 
result in hits if re-queried, even when applying original fq parameters.
 it would be great if solr will order the collations by numFound, so the 
collations with more results appear first.
{quote}
i.e:
spellcheck.q = prditive analytiycs
spellcheck.maxCollations = 5
spellcheck.count=0

response:
{code:xml}

  
  false
  
positive analytic
positive analytics
predictive analytics
primitive analytics
punitive analytic
  

{code}
Obviesly that "predictive analytics" have more results from "positive analytic".



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7157:

Attachment: LUCENE-7157.diff

Everything is now working.
[~mikemccand]: This is ready for review.  There are a number of improvements 
here for polygons in general -- namely, faster computation of intersections and 
bounds, along with ability to handle concave polygons.  There is one 
algorithmic area of concern with how we figure out clockwise/counterclockwise 
directionality during the construction.  This code is problematic because it 
generates a random pole repeatedly until it finds one that works.  It may be 
possible in future revs to reduce the search area for a good pole, but I doubt 
the need for randomness will go away ever entirely.


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



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

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

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

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([AB664A3E51000B78:C029EA43280FD642]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:134)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy(ZkStateReaderTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10846 lines...]
   [junit4] Suite: org.apache.solr.cloud.overseer.ZkStateReaderTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/

[jira] [Commented] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7132:
---

I added https://github.com/randomizedtesting/randomizedtesting/issues/227 to 
make this easier to debug. The stack trace is not very helpful to figure out 
that the "bad" guy was the non-nulled {{writer}} field.

> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, SOLR-8884.patch, 
> SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



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

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

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

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7157:

Attachment: LUCENE-7157.diff

No more hash-order dependencies, and fix some of the logical errors found so 
far.

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



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

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

[jira] [Commented] (SOLR-8803) OOM killer for Windows

[jmlucjav (JIRA)]

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

jmlucjav commented on SOLR-8803:


set an absolute path to oom_win.bat  maybe?

> OOM killer for Windows
> --
>
> Key: SOLR-8803
> URL: https://issues.apache.org/jira/browse/SOLR-8803
> Project: Solr
>  Issue Type: Improvement
>Reporter: Binoy Dalal
>Priority: Minor
> Attachments: SOLR-8803.patch, SOLR-8803.patch, oom_win.bat, 
> oom_win.cmd
>
>
> Solr on windows does not currently have a script to kill the process on OOM 
> errors.
> The idea is to write a batch script that works like the OOM kill script for 
> Linux and kills the solr process on OOM errors while creating an OOM log file 
> like the one on Linux systems.



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

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([76A2A7B2D3A8A657:1DED07CFAAA77B6D]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:134)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithExplicitRefreshLazy(ZkStateReaderTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 32 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Fa

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

[Apache Jenkins Server]

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

9 tests failed.
FAILED:  org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test

Error Message:
No live SolrServers available to handle this 
request:[https://127.0.0.1:38388/xi/j/collection1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:38388/xi/j/collection1]
at 
__randomizedtesting.SeedInfo.seed([F4FEB0EA8AE0D98C:7CAA8F30241CB474]:0)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:352)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1165)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:935)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:871)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.queryServer(AbstractFullDistribZkTestBase.java:1397)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertPartialResults(CloudExitableDirectoryReaderTest.java:99)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:71)
at 
org.apache.solr.cloud.CloudExitableDirectoryReaderTest.test(CloudExitableDirectoryReaderTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.

[jira] [Comment Edited] (LUCENE-7132) BooleanQuery scores can be diff for same docs+sim when using coord (disagree with Explanation which doesn't change)

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7132 at 4/3/16 8:36 AM:
---

Here is what's wrong in the test: You have to null the writer field in 
BaseExplanationTestCase like the searcher in afterClass().


was (Author: thetaphi):
You have to null the writer fiel in BaseExplanationTrstCase like searcher in 
afterClass. It's shown how to do for the other fields there :)

> BooleanQuery scores can be diff for same docs+sim when using coord (disagree 
> with Explanation which doesn't change)
> ---
>
> Key: LUCENE-7132
> URL: https://issues.apache.org/jira/browse/LUCENE-7132
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5
>Reporter: Ahmet Arslan
>Assignee: Steve Rowe
> Attachments: LUCENE-7132.patch, LUCENE-7132.patch, SOLR-8884.patch, 
> SOLR-8884.patch, debug.xml
>
>
> Some of the folks 
> [reported|http://find.searchhub.org/document/80666f5c3b86ddda] that sometimes 
> explain's score can be different than the score requested by fields 
> parameter. Interestingly, Explain's scores would create a different ranking 
> than the original result list. This is something users experience, but it 
> cannot be re-produced deterministically.



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

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