[
https://issues.apache.org/jira/browse/LUCENE-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14961224#comment-14961224
]
Michael McCandless commented on LUCENE-6780:
--------------------------------------------
OK I found a couple test bugs, which explained some of the failures.
I also cut all "small" booleans back to true always, so we are only testing a
region b/w 1-3 degrees in lat and lon.
There is still a lurking boundary case failure, where a doc's lat/lon is on the
edge of the bbox rect we query.
And then things are still sometimes very very slow, even when restricting
queries to small shapes, e.g. when I run {{ant test
-Dtestcase=TestGeoPointQuery -Dtests.seed=0}}, I get these times:
{noformat}
-test:
[junit4:pickseed] Seed property 'tests.seed' already defined: 0
[junit4] <JUnit4> says hello! Master seed: 0
[junit4] Executing 1 suite with 1 JVM.
[junit4]
[junit4] Started J0 PID(30211@localhost).
[junit4] Suite: org.apache.lucene.search.TestGeoPointQuery
[junit4] OK 0.01s | TestGeoPointQuery.testInvalidGeoDistanceQuery
[junit4] OK 0.02s | TestGeoPointQuery.testBBoxQuery
[junit4] OK 9.10s | TestGeoPointQuery.testMultiValued
[junit4] OK 2.07s | TestGeoPointQuery.testRandomMedium
[junit4] OK 0.01s | TestGeoPointQuery.testGeoDistanceQueryHuge
[junit4] OK 1.05s | TestGeoPointQuery.testRandomTiny
[junit4] OK 0.27s | TestGeoPointQuery.testWholeMap
[junit4] OK 0.00s | TestGeoPointQuery.testRectCrossesCircle
[junit4] OK 2.48s | TestGeoPointQuery.testAllLonEqual
[junit4] OK 0.00s | TestGeoPointQuery.testMortonEncoding
[junit4] OK 13.2s | TestGeoPointQuery.testSamePointManyTimes
[junit4] OK 0.01s | TestGeoPointQuery.testGeoDistanceQueryCrossDateline
[junit4] IGNOR/A 0.03s | TestGeoPointQuery.testRandomBig
[junit4] > Assumption #1: 'nightly' test group is disabled (@Nightly())
[junit4] OK 0.00s | TestGeoPointQuery.testPacManPolyQuery
[junit4] OK 0.01s | TestGeoPointQuery.testMultiValuedQuery
[junit4] OK 0.00s | TestGeoPointQuery.testPolyQuery
[junit4] OK 0.00s | TestGeoPointQuery.testGeoDistanceQuery
[junit4] HEARTBEAT J0 PID(30211@localhost): 2015-10-16T15:07:46, stalled for
66.9s at: TestGeoPointQuery.testAllLatEqual
[junit4] OK 78.3s | TestGeoPointQuery.testAllLatEqual
[junit4] OK 0.00s | TestGeoPointQuery.testInvalidBBox
[junit4] OK 0.00s | TestGeoPointQuery.testBBoxCrossDateline
[junit4] Completed [1/1] in 106.94s, 20 tests, 1 skipped
[junit4]
[junit4] JVM J0: 0.36 .. 107.82 = 107.47s
[junit4] Execution time total: 1 minute 47 seconds
[junit4] Tests summary: 1 suite, 20 tests, 1 ignored (1 assumption)
[echo] 5 slowest tests:
{noformat}
Why is {{testAllLatEqual}} so slow? This test case came from BKD's test (since
we refactored to a common base test class) ... I just don't understand why it's
so slow for geo point query.
> GeoPointDistanceQuery doesn't work with a large radius?
> -------------------------------------------------------
>
> Key: LUCENE-6780
> URL: https://issues.apache.org/jira/browse/LUCENE-6780
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Attachments: LUCENE-6780-heap-used-hack.patch, LUCENE-6780.patch,
> LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch, LUCENE-6780.patch
>
>
> I'm working on LUCENE-6698 but struggling with test failures ...
> Then I noticed that TestGeoPointQuery's test never tests on large distances,
> so I modified the test to sometimes do so (like TestBKDTree) and hit test
> failures.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
