date:20160421

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_72) - Build # 16559 - Still Failing!

2016-04-21 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16559/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy

Error Message:
java.util.LinkedHashMap cannot be cast to org.apache.solr.common.util.NamedList

Stack Trace:
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to 
org.apache.solr.common.util.NamedList
at 
__randomizedtesting.SeedInfo.seed([EA2EA88E459B033B:6DD2A7204B63FEBC]:0)
at 
org.apache.solr.client.solrj.response.schema.SchemaResponse.setResponse(SchemaResponse.java:252)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy(SchemaTest.java:123)
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

[JENKINS] Lucene-Solr-NightlyTests-5.5 - Build # 1 - Failure

2016-04-21 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.5/1/

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

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:60491/sbh/gz

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:60491/sbh/gz
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:586)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:458)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
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:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
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

[jira] [Updated] (SOLR-9028) fix bugs in (add sanity checks for) SSL clientAuth testing

2016-04-21 Thread Steve Rowe (JIRA)


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

Steve Rowe updated SOLR-9028:
-
Attachment: os.x.failure.txt

Fails for me on OS X 10.11.4, {{os.x.failure.txt}} is test output.  {{java 
-version}} says:

{noformat}
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
{noformat}

> fix bugs in (add sanity checks for) SSL clientAuth testing
> --
>
> Key: SOLR-9028
> URL: https://issues.apache.org/jira/browse/SOLR-9028
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-9028.patch, os.x.failure.txt
>
>
> While looking into SOLR-8970 i realized there was a whole heap of problems 
> with how clientAuth was being handled in tests.  Notably: it wasn't actaully 
> being used when the randomization selects it (aparently due to a copy/paste 
> mistake in SOLR-7166).  But there are few other misc issues (improper usage 
> of sysprops overrides for tests, missuage of keystore/truststore in test 
> clients, etc..)
> I'm working up a patch to fix all of this, and add some much needed tests to 
> *explicitly* verify both SSL and clientAuth that will include some "false 
> positive" verifications, and some "test the test" checks.



--
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-7242) LatLonTree should build a balanced tree

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-7242:
-

I checked startup cost and everything is ok (numbers are so small that its all 
noise).

> LatLonTree should build a balanced tree
> ---
>
> Key: LUCENE-7242
> URL: https://issues.apache.org/jira/browse/LUCENE-7242
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7242.patch
>
>
> [~rjernst]'s idea: we create an interval tree of edges, but with randomized 
> order.
> Instead we can speed things up more by creating a balanced tree up front.



--
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-8992) Restore Schema API GET method functionality removed by SOLR-8736

2016-04-21 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on SOLR-8992:
--

+1 to the latest patch.  It did take me a while to grok the default case in 
SchemaHandler.handleGET() though - the local variable names (realName, 
fieldName, name, parts) are confusing.  I suggest rethinking them so it's 
clearer what's going on.

Noble, if you can't fix the SchemaTest failures right away, we should revert 
your e8cc19e commit until a fix is in place.

> Restore Schema API GET method functionality removed by SOLR-8736
> 
>
> Key: SOLR-8992
> URL: https://issues.apache.org/jira/browse/SOLR-8992
> Project: Solr
>  Issue Type: Bug
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-8992.patch, SOLR-8992.patch, SOLR-8992.patch
>
>
> The following schema API GET functionality was removed under SOLR-8736; some 
> of this functionality should be restored:
> * {{schema/copyfields}}:
> ** The following information is no longer output:
> *** {{destDynamicBase}}: the matching dynamic field pattern for the 
> destination
> *** {{sourceDynamicBase}}: the matching dynamic field pattern for the source
> ** The following request parameters are no longer supported:
> *** {{dest.fl}}: include only copyFields that have one of these as a 
> destination
> *** {{source.fl}}: include only copyFields that have one of these as a source
> * {{schema/dynamicfields}}:
> ** The following request parameters are no longer supported:
> *** {{fl}}: a comma and/or space separated list of dynamic field patterns to 
> include 
> * {{schema/fields}} and {{schema/fields/_fieldname_}}:
> ** The following information is no longer output:
> *** {{dynamicBase}}: the matching dynamic field pattern, if the 
> {{includeDynamic}} param is given (see below) 
> ** The following request parameters are no longer supported:
> *** {{fl}}: (only supported without {{/_fieldname_}}): a comma and/or space 
> separated list of fields to include 
> *** {{includeDynamic}}: output the matching dynamic field pattern as 
> {{dynamicBase}}, if {{_fieldname_}}, or field(s) listed in {{fl}} param, are 
> not explicitly declared in the schema
> * {{schema/fieldtypes}} and {{schema/fieldtypes/_typename_}}:
> ** The following information is no longer output: 
> *** {{fields}}: the fields with the given field type
> *** {{dynamicFields}}: the dynamic fields with the given field type  



--
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-7242) LatLonTree should build a balanced tree

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-7242:

Attachment: LUCENE-7242.patch

Initial patch: seems to make things a bit faster:

Synthetic polygons from luceneUtil
||vertices||old QPS||new QPS|
|5|38.4|41.1|
|50|29.7|33.1|
|500|27.5|30.5|
|5000|18.8|20.1|
Real polygons (33 london districts: 
http://data.london.gov.uk/2011-boundary-files)
||vertices||old QPS||new QPS|
|avg 5.6k|73.0|84.7|

I want to check that startup cost is not hurt, otherwise I think its better. 
startup cost may be improved.

> LatLonTree should build a balanced tree
> ---
>
> Key: LUCENE-7242
> URL: https://issues.apache.org/jira/browse/LUCENE-7242
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
> Attachments: LUCENE-7242.patch
>
>
> [~rjernst]'s idea: we create an interval tree of edges, but with randomized 
> order.
> Instead we can speed things up more by creating a balanced tree up front.



--
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-7240) Remove DocValues from LatLonPoint, add DocValuesField for that

2016-04-21 Thread Karl Wright (JIRA)


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

Karl Wright commented on LUCENE-7240:
-

+1

This looks like a big help (and will unblock my work too).

> Remove DocValues from LatLonPoint, add DocValuesField for that
> --
>
> Key: LUCENE-7240
> URL: https://issues.apache.org/jira/browse/LUCENE-7240
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7240.patch, LUCENE-7240.patch
>
>
> LatLonPoint needed two-phase intersection initially because of big 
> inefficiencies, but as of LUCENE-7239 all of its query operations:  
> {{newBoxQuery()}}, {{newDistanceQuery()}}, {{newPolygonQuery()}} and 
> {{nearest()}} only need the points datastructure (BKD).
> If you want to do {{newDistanceSort()}} then you need docvalues for that, but 
> I think it should be moved to a separate field: e.g. docvalues is optional 
> just like any other field in lucene. We can add other methods that make sense 
> to that new docvalues field (e.g. facet by distance/region, expressions 
> support, whatever). It is really disjoint from the core query support: and 
> also currently has a heavyish cost of ~64-bits per value in space.



--
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-7242) LatLonTree should build a balanced tree

2016-04-21 Thread Robert Muir (JIRA)

Robert Muir created LUCENE-7242:
---

 Summary: LatLonTree should build a balanced tree
 Key: LUCENE-7242
 URL: https://issues.apache.org/jira/browse/LUCENE-7242
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir


[~rjernst]'s idea: we create an interval tree of edges, but with randomized 
order.

Instead we can speed things up more by creating a balanced tree up front.



--
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: Jira Spam - And changes made as a result.

2016-04-21 Thread Ryan Josal

Woah, yeah, I have filed a few bugs as well as posted patches and
comments.  Indeed I don't seem to be able to comment anymore.  Anyone want
to add me (rjosal) to a role that can comment or create?

Ryan

On Thursday, April 21, 2016, David Smiley  wrote:

> Wow!  My reading of this is that the general public (i.e. not committers)
> won't be able to really do anything other than view JIRA issues unless we
> expressly add individuals to a specific project group?  :-(  Clearly that
> sucks big time.  Is anyone reading this differently?  Assuming this is
> true... at this point maybe there is nothing to do but wait until the
> inevitable requests come in for people to create/comment.  Maybe send a
> message to the user lists?
>
> ~ David
>
> -- Forwarded message -
> From: Gav  >
> Date: Fri, Apr 22, 2016 at 12:14 AM
> Subject: Jira Spam - And changes made as a result.
> To: infrastruct...@apache.org
> 
> Infrastructure  >
>
>
> Hi All,
>
> Apologies for notifying you after the fact.
>
> Earlier today (slowing down to a halt about 1/2 hr ago due to our changes)
> we had a
> big Spam attack directed at the ASF Jira instance.
>
> Many project were affected, including :-
>
> TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
> AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .
>
> During the process we ended up banning 27 IP addresses , deleted well over
> 200 tickets, and about 2 dozen user accounts.
>
> The spammers were creating accounts using the normal system and going
> through the required captchas.
>
> In addition to the ban hammer and deletions and to prevent more spam
> coming in, we changed the 'Default Permissions Scheme' so that anyone in
> the 'jira-users' group are no longer allowed to 'Create' tickets and are no
> longer allowed to 'Comment' on any tickets.
>
> Obviously that affects genuine users as well as the spammers, we know
> that.
>
> Replacement auth instead of jira-users group now includes allowing those
> in the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in
> jira.
>
> Projects would you please assist in making this work - anyone that is not
> in any of those roles for your project; and needs access to be able to
> create issues and comment, please do add their jira id to one of the
> available roles. (Let us know if you need assistance in this area)
>
> This is a short term solution. For the medium to long term we are working
> on providing LDAP authentication for Jira and Confluence through Atlassian
> Crowd (likley).
>
> If any projects are still being affected, please notify us as you may be
> using another permissions scheme to the one altered. Notify us via INFRA
> jira ticket or reply to this mail to infrastruct...@apache.org
>  or join us on
> hipchat (https://www.hipchat.com/gIjVtYcNy)
>
> Any project seriously adversely impacted by our changes please do come
> talk to us and we'll see what we can work out.
>
> Thanks all for your patience and understanding.
>
> Gav... (ASF Infra)
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

[jira] [Updated] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

2016-04-21 Thread Karl Wright (JIRA)

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

Karl Wright updated LUCENE-7241:

Description:
This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.

The trick here is to organize edges by some criteria, e.g. z value range, and
use that to avoid needing to go through all edges and/or tile large irregular
polygons. Then we use the ability to quickly determine intersections to figure
out whether a point is within the polygon, or not.

The current way geo3d polygons are constructed involves finding a single point,
or "pole", which all polygon points circle. This point is known to be either
"in" or "out" based on the direction of the points. So we have one place of
"truth" on the globe that is known at polygon setup time.

If edges are organized by z value, where the z values for an edge are computed
by the standard way of computing bounds for a plane, then we can readily
organize edges into a tree structure such that it is easy to find all edges we
need to check for a given z value. Then, we merely need to compute how many
intersections to consider as we navigate from the "truth" point to the point
being tested. In practice, this means both having a tree that is organized by
z, and a tree organized by (x,y), since we need to navigate in both directions.
But then we can cheaply count the number of intersections, and once we do
that, we know whether our point is "in" or "out".

The other performance improvement we need is whether a given plane intersects
the polygon within provided bounds. This can be done using the same two trees
(z and (x,y)), by virtue of picking which tree to use based on the plane's
minimum bounds in z or (x,y). And, in practice, we might well use three trees:
one in x, one in y, and one in z, which would mean we didn't have to compute
longitudes ever.

An implementation like this trades off the cost of finding point membership in
near O\(log\(n)) time vs. the extra expense per step of finding that
membership. Setup of the query is O\(n) in this scheme, rather than O\(n^2) in
the current implementation, but once again each individual step is more
expensive. Therefore I would expect we'd want to use the current
implementation for simpler polygons and this sort of implementation for tougher
polygons. Choosing which to use is a topic for another ticket.

was:
This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.

An implementation like this trades off the cost of finding point membership in
near O(log(n)) time vs. the extra expense per step of finding that membership.
Setup of the query is O\(n) in this scheme, rather than O\(n^2) in the current
implementation, but once again each individual step is more expensive.
Therefore I would expect we'd want to use the current implementation for
simpler polygons and this sort of implementation for tougher polygons.
Choosing which to use is a topic for another ticket.

> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL:

[jira] [Updated] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

2016-04-21 Thread Karl Wright (JIRA)

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

Karl Wright updated LUCENE-7241:

Description:
This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.

was:
This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.

An implementation like this trades off the cost of finding point membership in
near O(log(n)) time vs. the extra expense per step of finding that membership.
Setup of the query is O(n) in this scheme, rather than O(n^2) in the current
implementation, but once again each individual step is more expensive.
Therefore I would expect we'd want to use the current implementation for
simpler polygons and this sort of implementation for tougher polygons.
Choosing which to use is a topic for another ticket.

> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL:

[jira] [Updated] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

2016-04-21 Thread Karl Wright (JIRA)

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

Karl Wright updated LUCENE-7241:

Description:
This ticket corresponds to LUCENE-7239, except it's for geo3d polygons.

An implementation like this trades off the cost of finding point membership in
near O(log(n)) time vs. the extra expense per step of finding that membership.
Setup of the query is O(n) in this scheme, rather than O(n^2) in the current
implementation, but once again each individual step is more expensive.
Therefore I would expect we'd want to use the current implementation for
simpler polygons and this sort of implementation for tougher polygons.
Choosing which to use is a topic for another ticket.

was:
This ticket corresponds to the LUCENE-7239, except it's for geo3d polygons.

An implementation like this trades off the cost of finding point membership in
near O(log(n)) time vs. the extra expense per step of finding that membership.
Setup of the query is O(n) in this scheme, rather than O(n^2) in the current
implementation, but once again each individual step is more expensive.
Therefore I would expect we'd want to use the current implementation for
simpler polygons and this sort of implementation for tougher polygons.
Choosing which to use is a topic for another ticket.

> Improve performance of geo3d for polygons with very large numbers of points
> ---
>
> Key: LUCENE-7241
> URL:

[jira] [Created] (LUCENE-7241) Improve performance of geo3d for polygons with very large numbers of points

2016-04-21 Thread Karl Wright (JIRA)

Karl Wright created LUCENE-7241:
---

 Summary: Improve performance of geo3d for polygons with very large 
numbers of points
 Key: LUCENE-7241
 URL: https://issues.apache.org/jira/browse/LUCENE-7241
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial3d
Affects Versions: master
Reporter: Karl Wright
Assignee: Karl Wright


This ticket corresponds to the LUCENE-7239, except it's for geo3d polygons.

The trick here is to organize edges by some criteria, e.g. z value range, and 
use that to avoid needing to go through all edges and/or tile large irregular 
polygons.  Then we use the ability to quickly determine intersections to figure 
out whether a point is within the polygon, or not.

The current way geo3d polygons are constructed involves finding a single point, 
or "pole", which all polygon points circle.  This point is known to be either 
"in" or "out" based on the direction of the points.  So we have one place of 
"truth" on the globe that is known at polygon setup time.

If edges are organized by z value, where the z values for an edge are computed 
by the standard way of computing bounds for a plane, then we can readily 
organize edges into a tree structure such that it is easy to find all edges we 
need to check for a given z value.  Then, we merely need to compute how many 
intersections to consider as we navigate from the "truth" point to the point 
being tested.  In practice, this means both having a tree that is organized by 
z, and a tree organized by (x,y), since we need to navigate in both directions. 
 But then we can cheaply count the number of intersections, and once we do 
that, we know whether our point is "in" or "out".

The other performance improvement we need is whether a given plane intersects 
the polygon within provided bounds.  This can be done using the same two trees 
(z and (x,y)), by virtue of picking which tree to use based on the plane's 
minimum bounds in z or (x,y).  And, in practice, we might well use three trees: 
one in x, one in y, and one in z, which would mean we didn't have to compute 
longitudes ever.

An implementation like this trades off the cost of finding point membership in 
near O(log(n)) time vs. the extra expense per step of finding that membership.  
Setup of the query is O(n) in this scheme, rather than O(n^2) in the current 
implementation, but once again each individual step is more expensive.  
Therefore I would expect we'd want to use the current implementation for 
simpler polygons and this sort of implementation for tougher polygons.  
Choosing which to use is a topic for another ticket.





--
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-7240) Remove DocValues from LatLonPoint, add DocValuesField for that

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-7240:

Attachment: LUCENE-7240.patch

A couple javadocs improvements/cleanups.

> Remove DocValues from LatLonPoint, add DocValuesField for that
> --
>
> Key: LUCENE-7240
> URL: https://issues.apache.org/jira/browse/LUCENE-7240
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7240.patch, LUCENE-7240.patch
>
>
> LatLonPoint needed two-phase intersection initially because of big 
> inefficiencies, but as of LUCENE-7239 all of its query operations:  
> {{newBoxQuery()}}, {{newDistanceQuery()}}, {{newPolygonQuery()}} and 
> {{nearest()}} only need the points datastructure (BKD).
> If you want to do {{newDistanceSort()}} then you need docvalues for that, but 
> I think it should be moved to a separate field: e.g. docvalues is optional 
> just like any other field in lucene. We can add other methods that make sense 
> to that new docvalues field (e.g. facet by distance/region, expressions 
> support, whatever). It is really disjoint from the core query support: and 
> also currently has a heavyish cost of ~64-bits per value in space.



--
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-7240) Remove DocValues from LatLonPoint, add DocValuesField for that

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-7240:

Attachment: LUCENE-7240.patch

Here is a patch splitting it out.

I ran rough indexing benchmark with luceneutil:

previous (docvalues + points):
INDEX SIZE: 1.0679643917828798 GB
380.419779939 sec to index part 0

patch (points only)
INDEX SIZE: 0.6146336644887924 GB
359.832694579 sec to index part 0

So it doesn't buy you a lot on index time, but helps index-size if you don't 
need sorting or similar. And it keeps the stuff organized similar to other 
fields in core.

> Remove DocValues from LatLonPoint, add DocValuesField for that
> --
>
> Key: LUCENE-7240
> URL: https://issues.apache.org/jira/browse/LUCENE-7240
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Attachments: LUCENE-7240.patch
>
>
> LatLonPoint needed two-phase intersection initially because of big 
> inefficiencies, but as of LUCENE-7239 all of its query operations:  
> {{newBoxQuery()}}, {{newDistanceQuery()}}, {{newPolygonQuery()}} and 
> {{nearest()}} only need the points datastructure (BKD).
> If you want to do {{newDistanceSort()}} then you need docvalues for that, but 
> I think it should be moved to a separate field: e.g. docvalues is optional 
> just like any other field in lucene. We can add other methods that make sense 
> to that new docvalues field (e.g. facet by distance/region, expressions 
> support, whatever). It is really disjoint from the core query support: and 
> also currently has a heavyish cost of ~64-bits per value in space.



--
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-Windows (64bit/jdk1.8.0_72) - Build # 5794 - Failure!

2016-04-21 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/5794/
Java: 64bit/jdk1.8.0_72 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy

Error Message:
java.util.LinkedHashMap cannot be cast to org.apache.solr.common.util.NamedList

Stack Trace:
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to 
org.apache.solr.common.util.NamedList
at 
__randomizedtesting.SeedInfo.seed([EE56C3E37B0EEFBF:69AACC4D75F61238]:0)
at 
org.apache.solr.client.solrj.response.schema.SchemaResponse.setResponse(SchemaResponse.java:252)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy(SchemaTest.java:123)
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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_72) - Build # 16558 - Still Failing!

2016-04-21 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/16558/
Java: 32bit/jdk1.8.0_72 -client -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy

Error Message:
java.util.LinkedHashMap cannot be cast to org.apache.solr.common.util.NamedList

Stack Trace:
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to 
org.apache.solr.common.util.NamedList
at 
__randomizedtesting.SeedInfo.seed([8E82F7DBFF646C9C:97EF875F19C911B]:0)
at 
org.apache.solr.client.solrj.response.schema.SchemaResponse.setResponse(SchemaResponse.java:252)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.client.solrj.request.SchemaTest.testSchemaRequestAccuracy(SchemaTest.java:123)
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:

[jira] [Resolved] (LUCENE-7229) Improve Polygon.relate

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir resolved LUCENE-7229.
-
   Resolution: Fixed
Fix Version/s: 6.1
   master

> Improve Polygon.relate
> --
>
> Key: LUCENE-7229
> URL: https://issues.apache.org/jira/browse/LUCENE-7229
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: master, 6.1
>
> Attachments: LUCENE-7229.patch, LUCENE-7229.patch
>
>
> This method is currently quite slow and in many cases does more work than is 
> required. The speed actually directly impacts queries (tree traversal) and 
> bounds grid size to something tiny making it less effective.
> I think we should replace it line intersections based on orientation methods 
> described here http://www.cs.berkeley.edu/~jrs/meshpapers/robnotes.pdf and 
> https://www.cs.cmu.edu/~quake/robust.html
> For one, a naive implementation is considerably faster than the method today: 
> both because it reduces the cost of BKD tree traversals and also because it 
> makes grid construction cheaper. This means we can increase its level of 
> detail with similar or lower startup cost. Now its more like a Mario Brothers 
> 2 picture of your polygon instead of Space Invaders.
> Synthetic polygons from luceneUtil
> ||vertices||old QPS||new QPS||old startup cost||new startup cost||
> |50|20.4|21.7|1ms|1ms|
> |500|11.2|14.4|5ms|4ms|
> |1000|7.4|10.0|9ms|8ms|
> Real polygons (33 london districts: 
> http://data.london.gov.uk/2011-boundary-files)
> ||vertices||old QPS||new QPS||old startup cost||new startup cost||
> |avg 5.6k|4.9|8.6|94ms|85ms|
> But I also like using this method because its possible to extend it to remove 
> floating point error completely in the future with techniques described in 
> those links. This may be necessary if we want to do smarter things (e.g. not 
> linear time).



--
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-7239) Speed up LatLonPoint's polygon queries when there are many vertices

2016-04-21 Thread Robert Muir (JIRA)


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

Robert Muir resolved LUCENE-7239.
-
   Resolution: Fixed
Fix Version/s: 6.1
   master

> Speed up LatLonPoint's polygon queries when there are many vertices
> ---
>
> Key: LUCENE-7239
> URL: https://issues.apache.org/jira/browse/LUCENE-7239
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
> Fix For: master, 6.1
>
> Attachments: LUCENE-7239.patch, LUCENE-7239.patch
>
>
> This is inspired by the "reliability and numerical stability" recommendations 
> at the end of http://www-ma2.upc.es/geoc/Schirra-pointPolygon.pdf.
> Basically our polys need to answer two questions that are slow today:
> contains(point)
> crosses(rectangle)
> Both of these ops only care about a subset of edges: the ones overlapping a y 
> interval range. We can organize these edges in an interval tree to be 
> practical and speed things up a lot. Worst case is still O(n) but those 
> solutions are more complex to do.



--
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

Fwd: Jira Spam - And changes made as a result.

2016-04-21 Thread David Smiley

Wow!  My reading of this is that the general public (i.e. not committers)
won't be able to really do anything other than view JIRA issues unless we
expressly add individuals to a specific project group?  :-(  Clearly that
sucks big time.  Is anyone reading this differently?  Assuming this is
true... at this point maybe there is nothing to do but wait until the
inevitable requests come in for people to create/comment.  Maybe send a
message to the user lists?

~ David

-- Forwarded message -
From: Gav 
Date: Fri, Apr 22, 2016 at 12:14 AM
Subject: Jira Spam - And changes made as a result.
To: infrastruct...@apache.org Infrastructure 


Hi All,

Apologies for notifying you after the fact.

Earlier today (slowing down to a halt about 1/2 hr ago due to our changes)
we had a
big Spam attack directed at the ASF Jira instance.

Many project were affected, including :-

TM, ARROW ACCUMULO, ABDERA, JSPWIKI, QPIDIT, LOGCXX, HAWQ, AMQ, ATLAS,
AIRFLOW, ACE, APEXCORE, RANGER and KYLIN .

During the process we ended up banning 27 IP addresses , deleted well over
200 tickets, and about 2 dozen user accounts.

The spammers were creating accounts using the normal system and going
through the required captchas.

In addition to the ban hammer and deletions and to prevent more spam coming
in, we changed the 'Default Permissions Scheme' so that anyone in the
'jira-users' group are no longer allowed to 'Create' tickets and are no
longer allowed to 'Comment' on any tickets.

Obviously that affects genuine users as well as the spammers, we know that.

Replacement auth instead of jira-users group now includes allowing those in
the 'Administrator, PMC, Committer, Contributor and Developer' ROLES in
jira.

Projects would you please assist in making this work - anyone that is not
in any of those roles for your project; and needs access to be able to
create issues and comment, please do add their jira id to one of the
available roles. (Let us know if you need assistance in this area)

This is a short term solution. For the medium to long term we are working
on providing LDAP authentication for Jira and Confluence through Atlassian
Crowd (likley).

If any projects are still being affected, please notify us as you may be
using another permissions scheme to the one altered. Notify us via INFRA
jira ticket or reply to this mail to infrastruct...@apache.org or join us
on hipchat (https://www.hipchat.com/gIjVtYcNy)

Any project seriously adversely impacted by our changes please do come talk
to us and we'll see what we can work out.

Thanks all for your patience and understanding.

Gav... (ASF Infra)
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: VOTE: RC2 Release apache-solr-ref-guide-6.0.pdf

2016-04-21 Thread Tomás Fernández Löbbe

+1

Not a blocker, but looks like many times images are broken into 2 pages
(happens for example for many of the admin UI screenshot, but also with
smaller images like in the Spatial Filers section). Is there a way to
prevent this in Confluence?
Also, we should try to prevent pasting extremely long examples, some
example outputs take ~3 pages

On Thu, Apr 21, 2016 at 1:34 PM, Joel Bernstein  wrote:

> +1
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Thu, Apr 21, 2016 at 3:53 PM, Cassandra Targett 
> wrote:
>
>> Reminder to VOTE on this thread so we can get the Ref Guide released.
>>
>> Thanks,
>> Cassandra
>>
>> On Mon, Apr 18, 2016 at 6:13 PM, Steve Rowe  wrote:
>> > +1
>> >
>> > --
>> > Steve
>> > www.lucidworks.com
>> >
>> >> On Apr 18, 2016, at 5:59 PM, Cassandra Targett 
>> wrote:
>> >>
>> >> Please VOTE to release the Apache Solr Ref Guide for 6.0:
>> >>
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.0-RC2/
>> >>
>> >> $ cat apache-solr-ref-guide-6.0.pdf.sha1
>> >> 9073530b89148ce3f641a42e38249bd1fbb25136  apache-solr-ref-guide-6.0.pdf
>> >>
>> >> Here's my +1.
>> >>
>> >> * Note, RC1 was skipped because there were a few other issues to be
>> >> fixed right after I'd committed it.
>> >>
>> >> Thanks,
>> >> Cassandra
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

1 2 3 >

1 - 100 of 230 matches

Mail list logo