[jira] [Comment Edited] (SOLR-12161) CloudSolrClient with basic auth enabled will update even if no credentials supplied

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-12161 at 4/11/18 5:07 AM:


diagnosis: 

update requests done using CloudSolrClient are executed in a threadpool so that 
each shard is requested in a separate thread. Solrj mistakes this to be an 
inter server request and sets the PKI authentication header. So this request is 
considered goes through using PKI authentication. commit() request is performed 
in the same thread (not the thread pool) so it uses basic auth and works as 
expected.

 

So far so good.

 

Is it a security vulnerability?

NO

This is executed in the test JVM which already has a valid Solr which in turn 
has a valid PKIAuthenticationPlugin instance. Normally, when SolrJ is used 
outside in a JVM which does not have a Solr running inside, the 
PKIAuthenticationPlugin instance does not exist and the headers cannot be set 
and the request would fail , as expected.

 

is it a bug?

 

YES. But limited to the test environment

 

Is it a regression?

 

I'm not sure. We need further investigation to know that.


was (Author: noble.paul):
diagnosis: 

update requests done using CloudSolrClient are executed in a threadpool so that 
each shard is requested in a separate thread. Solrj mistakes this to be an 
inter server request and sets the PKI authentication header. So this request is 
considered goes through using PKI authentication. commit() request is performed 
without the same thread (not the thread pool) so it uses basic auth and works 
as expected.

 

So far so good.

 

Is it a security vulnerability?

NO

This is executed in the test JVM which already has a valid Solr which in turn 
has a valid PKIAuthenticationPlugin instance. Normally, when SolrJ is used 
outside in a JVM which does not have a Solr running inside, the 
PKIAuthenticationPlugin instance does not exist and the headers cannot be set 
and the request would fail , as expected.

 

is it a bug?

 

YES. But limited to the test environment

 

Is it a regression?

 

I'm not sure. We need further investigation to know that.

> CloudSolrClient with basic auth enabled will update even if no credentials 
> supplied
> ---
>
> Key: SOLR-12161
> URL: https://issues.apache.org/jira/browse/SOLR-12161
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 7.3
>Reporter: Erick Erickson
>Assignee: Noble Paul
>Priority: Major
> Attachments: AuthUpdateTest.java, tests.patch
>
>
> This is an offshoot of SOLR-9399. When I was writing a test, if I create a 
> cluster with basic authentication set up, I can _still_ add documents to a 
> collection even without credentials being set in the request.
> However, simple queries, commits etc. all fail without credentials set in the 
> request.
> I'll attach a test class that illustrates the problem.
> If I use a new HttpSolrClient instead of a CloudSolrClient, then the update 
> request fails as expected.
> [~noblepaul] do you have any insight here? Possibly something with splitting 
> up the update request to go to each individual shard?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

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

mosh commented on SOLR-12209:
-

Sounds great, I will try and tackle this in the coming days.
Thanks.

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] lucene-solr issue #345: LUCENE-8229: Add Weight.matches() method

[dsmiley]

Github user dsmiley commented on the issue:

https://github.com/apache/lucene-solr/pull/345
  
Curious; what led to the addition of the MatchesIteratorSupplier instead of 
directly returning the MatchesIterator?  Whatever your response may be, does 
the eager call to `.get` in Matches.forField defeat the purpose?


---

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

[JENKINS] Lucene-Solr-7.x-Windows (32bit/jdk1.8.0_144) - Build # 540 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/540/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImport

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J0\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_D4A7285F9C6600F5-001\tempDir-003

at 
__randomizedtesting.SeedInfo.seed([D4A7285F9C6600F5:510B55C424699ED5]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[dsmiley]

Github user dsmiley commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180628960
  
--- Diff: 
lucene/core/src/java/org/apache/lucene/search/DisjunctionMatchesIterator.java 
---
@@ -0,0 +1,168 @@
+/*
+ * 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/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Objects;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PostingsEnum;
+import org.apache.lucene.index.Term;
+import org.apache.lucene.index.Terms;
+import org.apache.lucene.index.TermsEnum;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefIterator;
+import org.apache.lucene.util.PriorityQueue;
+
+/**
+ * A {@link MatchesIterator} that combines matches from a set of 
sub-iterators
+ *
+ * Matches are sorted by their start positions, and then by their end 
positions, so that
+ * prefixes sort first.  Matches may overlap, or be duplicated if they 
appear in more
+ * than one of the sub-iterators.
+ */
+final class DisjunctionMatchesIterator implements MatchesIterator {
+
+  /**
+   * Create a {@link DisjunctionMatchesIterator} over a list of terms
+   *
+   * Only terms that have at least one match in the given document will be 
included
+   */
+  static MatchesIterator fromTerms(LeafReaderContext context, int doc, 
String field, List terms) throws IOException {
+for (Term term : terms) {
+  if (Objects.equals(field, term.field()) == false) {
--- End diff --

Why do you use Objects.equals instead of field.equals(term.field())?  
Neither side can be null; right?


---

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1002 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 23733 lines...]
[asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
invalid part, must have at least one section (e.g., chapter, appendix, etc.)
[asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
part, must have at least one section (e.g., chapter, appendix, etc.)
 [java] Processed 2190 links (1746 relative) to 3004 anchors in 243 files
 [echo] Validated Links & Anchors via: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/

-dist-changes:
 [copy] Copying 4 files to 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes

-dist-keys:
  [get] Getting: http://home.apache.org/keys/group/lucene.asc
  [get] To: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/KEYS

package:

-unpack-solr-tgz:

-ensure-solr-tgz-exists:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked
[untar] Expanding: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz
 into 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked

generate-maven-artifacts:

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml

resolve:

ivy-availability-check:
[loadresource] Do not set property disallowed.ivy.jars.list as its length is 0.

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 

[jira] [Resolved] (SOLR-12160) Document Time Routed Aliases separate from API

[David Smiley (JIRA)]

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

David Smiley resolved SOLR-12160.
-
   Resolution: Fixed
Fix Version/s: 7.4

Thanks Gus.  I committed it with maybe a tweak or two.  I'm good with 
"segments" though I suppose it's ambiguous with Lucene segments.  I was trying 
to avoid choosing a word by just saying "collection".

> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12160) Document Time Routed Aliases separate from API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12160:


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

SOLR-12160: Time Routed Alias (TRA) documentation

(cherry picked from commit 0292d0f)


> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12160) Document Time Routed Aliases separate from API

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12160:


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

SOLR-12160: Time Routed Alias (TRA) documentation


> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12201:


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

SOLR-12201: TestReplicationHandler.doTestIndexFetchOnMasterRestart(): handle 
unexpected replication failures


> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: master (8.0), 7.4
>
> Attachments: SOLR-12201.patch
>
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 
> one asserting zero replication failures, at line 668, would fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-12201.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4

> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12201.patch
>
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 
> one asserting zero replication failures, at line 668, would fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12201:


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

SOLR-12201: TestReplicationHandler.doTestIndexFetchOnMasterRestart(): handle 
unexpected replication failures


> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12201.patch
>
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 
> one asserting zero replication failures, at line 668, would fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12161) CloudSolrClient with basic auth enabled will update even if no credentials supplied

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-12161:
---

diagnosis: 

update requests done using CloudSolrClient are executed in a threadpool so that 
each shard is requested in a separate thread. Solrj mistakes this to be an 
inter server request and sets the PKI authentication header. So this request is 
considered goes through using PKI authentication. commit() request is performed 
without the same thread (not the thread pool) so it uses basic auth and works 
as expected.

 

So far so good.

 

Is it a security vulnerability?

NO

This is executed in the test JVM which already has a valid Solr which in turn 
has a valid PKIAuthenticationPlugin instance. Normally, when SolrJ is used 
outside in a JVM which does not have a Solr running inside, the 
PKIAuthenticationPlugin instance does not exist and the headers cannot be set 
and the request would fail , as expected.

 

is it a bug?

 

YES. But limited to the test environment

 

Is it a regression?

 

I'm not sure. We need further investigation to know that.

> CloudSolrClient with basic auth enabled will update even if no credentials 
> supplied
> ---
>
> Key: SOLR-12161
> URL: https://issues.apache.org/jira/browse/SOLR-12161
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authentication
>Affects Versions: 7.3
>Reporter: Erick Erickson
>Assignee: Noble Paul
>Priority: Major
> Attachments: AuthUpdateTest.java, tests.patch
>
>
> This is an offshoot of SOLR-9399. When I was writing a test, if I create a 
> cluster with basic authentication set up, I can _still_ add documents to a 
> collection even without credentials being set in the request.
> However, simple queries, commits etc. all fail without credentials set in the 
> request.
> I'll attach a test class that illustrates the problem.
> If I use a new HttpSolrClient instead of a CloudSolrClient, then the update 
> request fails as expected.
> [~noblepaul] do you have any insight here? Possibly something with splitting 
> up the update request to go to each individual shard?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12201:
---

Attached patch allows for the possibility that prior to restarting master, 
replication may have failed, e.g. because master was still loading when slave 
wanted to replicate:

{noformat}
   [junit4]   2> 41046 WARN  (indexFetcher-265-thread-1) [] 
o.a.s.h.IndexFetcher Master at: http://127.0.0.1:50479/solr/collection1 is not 
available. Index 
fetch failed by exception: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:50479/solr/collection1: SolrCore is loading
{noformat}

With the patch 100 beasting iterations succeeded for me.  The patch also 
removes the BadApple annotation from the test.

Committing shortly.

> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12201.patch
>
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 

[jira] [Updated] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[Steve Rowe (JIRA)]

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

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

> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
> Attachments: SOLR-12201.patch
>
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 
> one asserting zero replication failures, at line 668, would fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-12187:

Attachment: SOLR-12187.patch

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch, 
> SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12201) TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected replication failures

[Steve Rowe (JIRA)]

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

Steve Rowe reassigned SOLR-12201:
-

Assignee: Steve Rowe

> TestReplicationHandler.doTestIndexFetchOnMasterRestart(): unexpected 
> replication failures
> -
>
> Key: SOLR-12201
> URL: https://issues.apache.org/jira/browse/SOLR-12201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>Priority: Major
>
> This is a BadApple'd test, and in local beasting failed 31/100 iterations.
> E.g. from 
> [https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/24/]:
> {noformat}
>[junit4]   1> SHALIN: 
> {responseHeader={status=0,QTime=150},details={indexSize=11.2 
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-008/./collection1/data/index/,commits=[{indexVersion=1523043739675,generation=2,filelist=[_0.fdt,
>  _0.fdx, _0.fnm, _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=false,isSlave=true,indexVersion=1523043739675,generation=2,slave={masterDetails={indexSize=11.27
>  
> KB,indexPath=/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/solr/build/solr-core/test/J1/temp/solr.handler.TestReplicationHandler_C1A11EE85E7B0C57-001/solr-instance-007/./collection1/data/index/,commits=[{indexVersion=0,generation=1,filelist=[segments_1]},
>  {indexVersion=1523043739675,generation=2,filelist=[_0.fdt, _0.fdx, _0.fnm, 
> _0.nvd, _0.nvm, _0.si, _0_FSTOrd50_0.doc, _0_FSTOrd50_0.tbk, 
> _0_FSTOrd50_0.tix, 
> segments_2]}],isMaster=true,isSlave=false,indexVersion=1523043739675,generation=2,master={confFiles=schema.xml,replicateAfter=[commit,
>  
> startup],replicationEnabled=true,replicableVersion=1523043739675,replicableGeneration=2}},masterUrl=http://127.0.0.1:36880/solr/collection1,pollInterval=00:00:01,nextExecutionAt=Fri
>  Apr 06 20:42:21 BST 2018,indexReplicatedAt=Fri Apr 06 20:42:20 BST 
> 2018,indexReplicatedAtList=[Fri Apr 06 20:42:20 BST 2018, Fri Apr 06 20:42:17 
> BST 2018],replicationFailedAtList=[Fri Apr 06 20:42:17 BST 
> 2018],timesIndexReplicated=2,lastCycleBytesDownloaded=11650,timesFailed=1,replicationFailedAt=Fri
>  Apr 06 20:42:17 BST 2018,previousCycleTimeInSeconds=0,currentDate=Fri Apr 06 
> 20:42:21 BST 2018,isPollingDisabled=false,isReplicating=false}}}
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestReplicationHandler 
> -Dtests.method=doTestIndexFetchOnMasterRestart -Dtests.seed=C1A11EE85E7B0C57 
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true 
> -Dtests.locale=en -Dtests.timezone=Europe/Isle_of_Man -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 9.39s J1 | 
> TestReplicationHandler.doTestIndexFetchOnMasterRestart <<<
>[junit4]> Throwable #1: java.lang.AssertionError: expected:<1> but 
> was:<2>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([C1A11EE85E7B0C57:1956DA0CF5A0CE0B]:0)
>[junit4]>  at 
> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:666)
>[junit4]>  at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The failed assertion is on line 666:
> {code:java|title=TestReplicationHandler.java}
> 666:assertEquals(1, 
> Integer.parseInt(getSlaveDetails("timesIndexReplicated")));
> 667:String timesFailed = getSlaveDetails("timesFailed");
> 668:assertEquals(0, Integer.parseInt(timesFailed != null ?  timesFailed : 
> "0"));
> {code}
> {{getSlaveDetails()}} prints out the properties it retrieves as JSON 
> following "SHALIN:" -- see the log excerpt above.  {{timesIndexReplicated}} 
> is 2 instead of 1 because there was an unexpected replication failure: 
> {{timesFailed}} is 1; if the assertion at line 666 were not there, then the 
> one asserting zero replication failures, at line 668, would fail.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8248) Make MergePolicy.setMaxCFSSegmentSizeMB final

[Mike Sokolov (JIRA)]

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

Mike Sokolov commented on LUCENE-8248:
--

I submitted a new patch that overrides {{set/getMaxCFSSegmentSizeMB}}, 
deprecates {{MergePolicyWrapper}} and replaces it with {{FilterMergePolicy}}. I 
also had to add these overrides to {{NoMergePolicy}} in order to get its test 
to pass since it verifies that all methods are overridden?

> Make MergePolicy.setMaxCFSSegmentSizeMB final
> -
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/index
>Reporter: Mike Sokolov
>Priority: Minor
> Attachments: LUCENE-8248.patch, MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
> not, which means that overriding it with anything other than a trivial 
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from 
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar 
> adapter classes in Lucene, which are usually Filter*.java. Personally I was 
> looking for MergePolicyAdapter, but if there is a prevailing convention here 
> around Filter, does it make sense to change this class's name to 
> FilterMergePolicy?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+5) - Build # 7263 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7263/
Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
timed out waiting for collection1 startAt time to exceed: Tue Apr 10 19:40:36 
CST 2018

Stack Trace:
java.lang.AssertionError: timed out waiting for collection1 startAt time to 
exceed: Tue Apr 10 19:40:36 CST 2018
at 
__randomizedtesting.SeedInfo.seed([C7A487B64E5488B3:30D769EE88BC2755]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.handler.TestReplicationHandler.watchCoreStartAt(TestReplicationHandler.java:1577)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1376)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:841)


FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:

[jira] [Updated] (LUCENE-8248) Make MergePolicy.setMaxCFSSegmentSizeMB final

[Mike Sokolov (JIRA)]

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

Mike Sokolov updated LUCENE-8248:
-
Attachment: LUCENE-8248.patch

> Make MergePolicy.setMaxCFSSegmentSizeMB final
> -
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/index
>Reporter: Mike Sokolov
>Priority: Minor
> Attachments: LUCENE-8248.patch, MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
> not, which means that overriding it with anything other than a trivial 
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from 
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar 
> adapter classes in Lucene, which are usually Filter*.java. Personally I was 
> looking for MergePolicyAdapter, but if there is a prevailing convention here 
> around Filter, does it make sense to change this class's name to 
> FilterMergePolicy?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [jira] [Commented] (LUCENE-8248) Make MergePolicy.setMaxCFSSegmentSizeMB final

[Michael Sokolov]

Ah true that would be messy! I'll update the patch.

On Tue, Apr 10, 2018 at 7:26 PM, Michael McCandless (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/LUCENE-8248?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=16433177#comment-16433177 ]
>
> Michael McCandless commented on LUCENE-8248:
> 
>
> Hmm maybe instead we should remove the {{final}} from
> {{getMaxCFSSegmentSizeMB}} and override both in the wrapper?
>
> Otherwise sneaky things could go wrong e.g. if you subclass
> {{MergePolicyWrapper}} and delegate to another merge policy that makes
> decisions based on the {{maxCFSSizeMB.}}  The caller would call
> {{setMaxCFSSizeMB}} but the wrapped merge policy wouldn't see the change I
> think?
>
> Also, I do think we should do the rename here to make it consistent.  We
> can do a hard rename for 8.x (master) and then on backport to 7.x we can
> leave a deprecated minimal {{MergePolicyWrapper}} just subclassing the new
> {{FilterMergePolicy}}?
>
> > Make MergePolicy.setMaxCFSSegmentSizeMB final
> > -
> >
> > Key: LUCENE-8248
> > URL: https://issues.apache.org/jira/browse/LUCENE-8248
> > Project: Lucene - Core
> >  Issue Type: Wish
> >  Components: core/index
> >Reporter: Mike Sokolov
> >Priority: Minor
> > Attachments: MergePolicy.patch
> >
> >
> > MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding
> setter is not, which means that overriding it with anything other than a
> trivial delegation can only lead to confusion.
> > The patch makes the method final and removes the trivial implementations
> from MergePolicyWrapper and NoMergePolicy.
> > [~mikemccand] also pointed out that the class name is nonstandard for
> similar adapter classes in Lucene, which are usually Filter*.java.
> Personally I was looking for MergePolicyAdapter, but if there is a
> prevailing convention here around Filter, does it make sense to change this
> class's name to FilterMergePolicy?
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-12162) CorePropertiesLocator Exception message contains a typo when unable to create Solr Core

[Ryan Zwiefelhofer (JIRA)]

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

Ryan Zwiefelhofer commented on SOLR-12162:
--

[~erickerickson] Thank you! Appreciate it. 

> CorePropertiesLocator Exception message contains a typo when unable to create 
> Solr Core
> ---
>
> Key: SOLR-12162
> URL: https://issues.apache.org/jira/browse/SOLR-12162
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ryan Zwiefelhofer
>Priority: Trivial
>  Labels: patch, pull-request-available
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12162_corepropertieslocator_typo.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> CorePropertiesLocator has a typo in the SolrException thrown when unable to 
> create a new core. 
> ([https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CorePropertiesLocator.java#L69)]
> There should be a space before the `as` so that the exception message reads 
> correctly.
> Before:
> {{Could not create a new core in /coredescriptor/instancedirectoryas another 
> core is already defined there}}
>                                                                               
>                                                  ^ no space here
>  
> After:
> {{Could not create a new core in /coredescriptor/instancedirectory as another 
> core is already defined there}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11982) Add support for indicating preferred replica types for queries

[JIRA]

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

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

Uploaded patch with rename to {{shards.preference}} and minor changes to the 
docs (the examples). I'll commit tomorrow if there are no more concerns

> Add support for indicating preferred replica types for queries
> --
>
> Key: SOLR-11982
> URL: https://issues.apache.org/jira/browse/SOLR-11982
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.4, master (8.0)
>Reporter: Ere Maijala
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
>  Labels: patch-available, patch-with-test
> Attachments: SOLR-11982-preferReplicaTypes.patch, 
> SOLR-11982-preferReplicaTypes.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch
>
>
> It would be nice to have the possibility to easily sort the shards in the 
> preferred order e.g. by replica type. The attached patch adds support for 
> {{shards.sort}} parameter that allows one to sort e.g. PULL and TLOG replicas 
> first with \{{shards.sort=replicaType:PULL|TLOG }}(which would mean that NRT 
> replicas wouldn't be hit with queries unless they're the only ones available) 
> and/or to sort by replica location (like preferLocalShards=true but more 
> versatile).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-11982) Add support for indicating preferred replica types for queries

[JIRA]

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

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

> Add support for indicating preferred replica types for queries
> --
>
> Key: SOLR-11982
> URL: https://issues.apache.org/jira/browse/SOLR-11982
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.4, master (8.0)
>Reporter: Ere Maijala
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
>  Labels: patch-available, patch-with-test
> Attachments: SOLR-11982-preferReplicaTypes.patch, 
> SOLR-11982-preferReplicaTypes.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch
>
>
> It would be nice to have the possibility to easily sort the shards in the 
> preferred order e.g. by replica type. The attached patch adds support for 
> {{shards.sort}} parameter that allows one to sort e.g. PULL and TLOG replicas 
> first with \{{shards.sort=replicaType:PULL|TLOG }}(which would mean that NRT 
> replicas wouldn't be hit with queries unless they're the only ones available) 
> and/or to sort by replica location (like preferLocalShards=true but more 
> versatile).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8248) Make MergePolicy.setMaxCFSSegmentSizeMB final

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8248:


Hmm maybe instead we should remove the {{final}} from 
{{getMaxCFSSegmentSizeMB}} and override both in the wrapper?

Otherwise sneaky things could go wrong e.g. if you subclass 
{{MergePolicyWrapper}} and delegate to another merge policy that makes 
decisions based on the {{maxCFSSizeMB.}}  The caller would call 
{{setMaxCFSSizeMB}} but the wrapped merge policy wouldn't see the change I 
think?

Also, I do think we should do the rename here to make it consistent.  We can do 
a hard rename for 8.x (master) and then on backport to 7.x we can leave a 
deprecated minimal {{MergePolicyWrapper}} just subclassing the new 
{{FilterMergePolicy}}?

> Make MergePolicy.setMaxCFSSegmentSizeMB final
> -
>
> Key: LUCENE-8248
> URL: https://issues.apache.org/jira/browse/LUCENE-8248
> Project: Lucene - Core
>  Issue Type: Wish
>  Components: core/index
>Reporter: Mike Sokolov
>Priority: Minor
> Attachments: MergePolicy.patch
>
>
> MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
> not, which means that overriding it with anything other than a trivial 
> delegation can only lead to confusion.
> The patch makes the method final and removes the trivial implementations from 
> MergePolicyWrapper and NoMergePolicy.
> [~mikemccand] also pointed out that the class name is nonstandard for similar 
> adapter classes in Lucene, which are usually Filter*.java. Personally I was 
> looking for MergePolicyAdapter, but if there is a prevailing convention here 
> around Filter, does it make sense to change this class's name to 
> FilterMergePolicy?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

The more-rigorous way of properly discovering the above condition is sort of 
already present.  What's needed is to find the XYZBounds of the bit of arc 
between the intersection point and the end point of the arc, and make sure that 
it all fits within the envelope plane bounds.

Unfortunately, this is all rather expensive to compute -- mainly because of 
significant object creation being required.  Fortunately, it happens only in 
very specific cases so maybe it would be limited enough to not impact things 
too badly.  But no question it would need to happen every time an edge ends on 
an envelope plane, and the distance between the edge endpoint and the 
intersection point is greater than MINIMUM_RESOLUTION.

I'm going to take a break from this particular part of the problem to give 
myself a chance to think it through to be sure there isn't a better way.  I'm 
also going to analyze case3 to see what the issue is there -- tomorrow.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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 # 1794 - Failure!

[Policeman Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 79, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (SOLR-12151) abstract MultiSolrCloudTestCase class

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-12151:
---

bq. TriggerIntegrationTest failure seems unrelated and changes have been made 
elsewhere since to probably fix it, so here just re-submitting the existing 
patch, let's see.

FYI, the Precommit-Admin Jenkins job remembers which patches it has reviewed 
and won't review them twice, so you have to upload a new patch in order to get 
the precommit job to run again.  From 
[https://builds.apache.org/job/PreCommit-Admin/]:

{quote}
h3. How to re-trigger patch testing for an issue:

The easiest way to rerun testing of a patch is to upload a new patch (with the 
same filename is fine) to the same Jira. The combination of a Jira being in 
Patch Available state AND having a new attachment that has never been processed 
by this system is what will trigger a new test of the patch.
{quote}

> abstract MultiSolrCloudTestCase class
> -
>
> Key: SOLR-12151
> URL: https://issues.apache.org/jira/browse/SOLR-12151
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12151.patch
>
>
> An abstract base class for tests that require more than one SolrCloud.
> Builds upon the existing 
> [SolrCloudTestCase|https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/cloud/SolrCloudTestCase.java]
>  class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12211) HdfsDirectoryFactoryTest can fail by trying to allocate too much direct memory.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12211:


Commit 89c364c2de43036782688a84abdf6da0fd4a1389 in lucene-solr's branch 
refs/heads/branch_7x from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=89c364c ]

SOLR-12211: HdfsDirectoryFactoryTest can fail by trying to allocate too much 
direct memory.


> HdfsDirectoryFactoryTest can fail by trying to allocate too much direct 
> memory.
> ---
>
> Key: SOLR-12211
> URL: https://issues.apache.org/jira/browse/SOLR-12211
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12211) HdfsDirectoryFactoryTest can fail by trying to allocate too much direct memory.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12211:


Commit b93e24cb834abd2080244dbb80f3d503d0a08e8f in lucene-solr's branch 
refs/heads/master from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b93e24c ]

SOLR-12211: HdfsDirectoryFactoryTest can fail by trying to allocate too much 
direct memory.


> HdfsDirectoryFactoryTest can fail by trying to allocate too much direct 
> memory.
> ---
>
> Key: SOLR-12211
> URL: https://issues.apache.org/jira/browse/SOLR-12211
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.4, master (8.0)
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12211) HdfsDirectoryFactoryTest can fail by trying to allocate too much direct memory.

[Mark Miller (JIRA)]

Mark Miller created SOLR-12211:
--

 Summary: HdfsDirectoryFactoryTest can fail by trying to allocate 
too much direct memory.
 Key: SOLR-12211
 URL: https://issues.apache.org/jira/browse/SOLR-12211
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
  Components: search
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 7.4, master (8.0)






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 558 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/558/

4 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters

Error Message:
Error from server at https://127.0.0.1:36715/solr: KeeperErrorCode = Session 
expired for 
/overseer/collection-map-completed/mn-42bd3978-b57b-465f-8612-c632beab37df

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36715/solr: KeeperErrorCode = Session expired 
for /overseer/collection-map-completed/mn-42bd3978-b57b-465f-8612-c632beab37df
at 
__randomizedtesting.SeedInfo.seed([18596F151B6598F1:E34EFCA542324F46]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1106)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.request.CollectionAdminRequest$RequestStatus.waitFor(CollectionAdminRequest.java:1256)
at 
org.apache.solr.client.solrj.request.CollectionAdminRequest.waitForAsyncRequest(CollectionAdminRequest.java:1216)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters(CloudSolrClientTest.java:564)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[jira] [Commented] (SOLR-12151) abstract MultiSolrCloudTestCase class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12151:


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

SOLR-12151: Add abstract MultiSolrCloudTestCase class.


> abstract MultiSolrCloudTestCase class
> -
>
> Key: SOLR-12151
> URL: https://issues.apache.org/jira/browse/SOLR-12151
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12151.patch
>
>
> An abstract base class for tests that require more than one SolrCloud.
> Builds upon the existing 
> [SolrCloudTestCase|https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/cloud/SolrCloudTestCase.java]
>  class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12151) abstract MultiSolrCloudTestCase class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12151:


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

SOLR-12151: Add abstract MultiSolrCloudTestCase class.


> abstract MultiSolrCloudTestCase class
> -
>
> Key: SOLR-12151
> URL: https://issues.apache.org/jira/browse/SOLR-12151
> Project: Solr
>  Issue Type: Test
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12151.patch
>
>
> An abstract base class for tests that require more than one SolrCloud.
> Builds upon the existing 
> [SolrCloudTestCase|https://github.com/apache/lucene-solr/blob/master/solr/test-framework/src/java/org/apache/solr/cloud/SolrCloudTestCase.java]
>  class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (LUCENE-8248) Make MergePolicy.setMaxCFSSegmentSizeMB final

[Mike Sokolov (JIRA)]

Mike Sokolov created LUCENE-8248:


 Summary: Make MergePolicy.setMaxCFSSegmentSizeMB final
 Key: LUCENE-8248
 URL: https://issues.apache.org/jira/browse/LUCENE-8248
 Project: Lucene - Core
  Issue Type: Wish
  Components: core/index
Reporter: Mike Sokolov
 Attachments: MergePolicy.patch

MergePolicy.getMaxCFSSegmentSizeMB is final, but the corresponding setter is 
not, which means that overriding it with anything other than a trivial 
delegation can only lead to confusion.

The patch makes the method final and removes the trivial implementations from 
MergePolicyWrapper and NoMergePolicy.

[~mikemccand] also pointed out that the class name is nonstandard for similar 
adapter classes in Lucene, which are usually Filter*.java. Personally I was 
looking for MergePolicyAdapter, but if there is a prevailing convention here 
around Filter, does it make sense to change this class's name to 
FilterMergePolicy?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1688 - Unstable!

[Policeman Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 79, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 6f68f74f7f36b0410dcfc29c03e5a970670c81ee in lucene-solr's branch 
refs/heads/branch_6x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6f68f74 ]

LUCENE-8245: Fix precommit


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: unsubscribe

[Cassandra Targett]

You need to send a mail to the unsubscribe address (
dev-unsubscr...@lucene.apache.org, see
https://lucene.apache.org/solr/community.html#mailing-lists-irc if you have
problems), from the address you used when you originally subscribed.

On Tue, Apr 10, 2018 at 2:50 PM, Sarthak Sugandhi <
sarthaksugand...@gmail.com> wrote:

> Hi team
>
> I want to unsubscribe from mailing list.
>
> Thanks,
> Sarthak
>

[jira] [Updated] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12036:
---
Fix Version/s: master (8.0)
   7.4

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-12036:


Attached draft SOLR-12036-adoc.patch with how the 
https://lucene.apache.org/solr/guide/7_3/streaming-expressions.html#streaming-requests-and-responses
 part of the Solr Reference Guide could be updated. Or would it be preferable 
to somehow mention both the {{StreamFactory}} base class as used in the current 
example and the {{DefaultStreamFactory}} convenience class?

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-12036:
---
Attachment: SOLR-12036-adoc.patch

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12036) factor out DefaultStreamFactory class

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-12036:
--

Assignee: Christine Poerschke

> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036-adoc.patch, SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

unsubscribe

[Sarthak Sugandhi]

Hi team

I want to unsubscribe from mailing list.

Thanks,
Sarthak

[jira] [Commented] (SOLR-12036) factor out DefaultStreamFactory class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12036:


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

SOLR-12036: Factor out DefaultStreamFactory solrj class.


> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12036) factor out DefaultStreamFactory class

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12036:


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

SOLR-12036: Factor out DefaultStreamFactory solrj class.


> factor out DefaultStreamFactory class
> -
>
> Key: SOLR-12036
> URL: https://issues.apache.org/jira/browse/SOLR-12036
> Project: Solr
>  Issue Type: Task
>  Components: streaming expressions
>Reporter: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-12036.patch, SOLR-12036.patch
>
>
> Motivation for the proposed class is to reduce the need for 
> {{withFunctionName}} method calls in client code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-10783) Using Hadoop Credential Provider as SSL/TLS store password source

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10783:


Commit 750c7a98267941166bdca02a0b182476ed6ec2a5 in lucene-solr's branch 
refs/heads/branch_7x from [~mark.mil...@oblivion.ch]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=750c7a9 ]

SOLR-10783: Add support for Hadoop Credential Provider as SSL/TLS store 
password source.


> Using Hadoop Credential Provider as SSL/TLS store password source
> -
>
> Key: SOLR-10783
> URL: https://issues.apache.org/jira/browse/SOLR-10783
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Affects Versions: 7.0
>Reporter: Mano Kovacs
>Assignee: Mark Miller
>Priority: Major
> Attachments: SOLR-10783-fix.patch, SOLR-10783.patch, 
> SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch, 
> SOLR-10783.patch, SOLR-10783.patch, SOLR-10783.patch
>
>
> As a second iteration of SOLR-10307, I propose support of hadoop credential 
> providers as source of SSL store passwords. 
> Motivation: When SOLR is used in hadoop environment, support of  HCP gives 
> better integration and unified method to pass sensitive credentials to SOLR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


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

SOLR-12155: awake threads awaiting UIF. despite of exception.


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12155) Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField()

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12155:


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

SOLR-12155: awake threads awaiting UIF. despite of exception.


> Solr 7.2.1 deadlock in UnInvertedField.getUnInvertedField() 
> 
>
> Key: SOLR-12155
> URL: https://issues.apache.org/jira/browse/SOLR-12155
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2.1
>Reporter: Kishor gandham
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12155.patch, SOLR-12155.patch, SOLR-12155.patch, 
> SOLR-12155.patch, SOLR-12155.patch, stack.txt
>
>
> I am attaching a stack trace from our production Solr (7.2.1). Occasionally, 
> we are seeing SOLR becoming unresponsive. We are then forced to kill the JVM 
> and start solr again.
> We have a lot of facet queries and our index has approximately 15 million 
> documents. We have recently started using json.facet queries and some of the 
> facet fields use DocValues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12207:


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

SOLR-12207: rethowing AssertionError from jdk reflection bug


> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12207:


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

SOLR-12207: rethowing AssertionError from jdk reflection bug


> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-12181:
--

This patch adds {{IndexSizeTrigger}}, tests and supporting changes, among 
others:
* a barebones {{SplitShardSuggester}} to handle SPLITSHARD requests
* stubs to handle the future MERGESHARDS (SOLR-9407)
* extensions to the simulation framework to support index updates, tracking 
index size and document count metrics.

The trigger supports mixed lower and upper bounds defined in terms of index 
size (using the {{INDEX.sizeInBytes}} metric) and document counts (using the 
{{SEARCHER.searcher.numDocs}} metric), as well as defining custom operations to 
perform when bounds are exceeded, both lower and upper ones:

* aboveBytes - upper bound defined using index size in bytes
* aboveDocs - upper bound defined using number of docs
* belowBytes - lower bound defined using index size in bytes
* belowDocs - lower bound defined using number of docs
* aboveOp - operation to perform when any upper bound is exceeded. The default 
operation is SPLITSHARD
* belowOp - operation to perform when any lower bound is exceeded. The default 
operation is MERGESHARDS
* collections - comma-separated list of collections, or empty / none to 
consider all collections

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: master (8.0)
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4560/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 52795 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1026320364
 [ecj-lint] Compiling 20 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1026320364
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 27)
 [ecj-lint] import static org.junit.Assert.assertEquals;
 [ecj-lint]   ^
 [ecj-lint] The import org.junit.Assert.assertEquals is never used
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 28)
 [ecj-lint] import static org.junit.Assert.assertFalse;
 [ecj-lint]   
 [ecj-lint] The import org.junit.Assert.assertFalse is never used
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
 (at line 29)
 [ecj-lint] import static org.junit.Assert.assertTrue;
 [ecj-lint]   ^^^
 [ecj-lint] The import org.junit.Assert.assertTrue is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeoPolygonTest.java
 (at line 27)
 [ecj-lint] import static 
com.carrotsearch.randomizedtesting.RandomizedTest.randomDouble;
 [ecj-lint]   
^^
 [ecj-lint] The import 
com.carrotsearch.randomizedtesting.RandomizedTest.randomDouble is never used
 [ecj-lint] --
 [ecj-lint] 4 problems (4 errors)

BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:633: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/build.xml:208: The 
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2264:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2095:
 The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2128:
 Compile failed; see the compiler error output for details.

Total time: 105 minutes 23 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/Users/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Updated] (SOLR-12210) Perfomance degradation at High Load

[ROMAN NAZARENKO (JIRA)]

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

ROMAN NAZARENKO updated SOLR-12210:
---
Summary: Perfomance degradation at High Load  (was: Perfomance degradation 
at Hghi Load)

> Perfomance degradation at High Load
> ---
>
> Key: SOLR-12210
> URL: https://issues.apache.org/jira/browse/SOLR-12210
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration
>Affects Versions: 7.2
>Reporter: ROMAN NAZARENKO
>Priority: Minor
>
> When hdfsDataFactory is used and the incoming data stream is large, the rate 
> of indexation is degraded. This is not a problem when using a local file 
> system. I think the problem is in cleaning hdfsBlockCache. Because the 
> degradation of the indexing rate occurs precisely when this cache reaches its 
> maximum value. The basis for hdfsBlockCache is caffeine cache, but it is 
> configured to clean only when the maximum size is reached. At the same time, 
> nothing prevents using timeEviction, I suggest testing the indexing speed 
> using this type of cache cleaning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12181) Add trigger based on document count

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-12181:
-
Attachment: SOLR-12181.patch

> Add trigger based on document count
> ---
>
> Key: SOLR-12181
> URL: https://issues.apache.org/jira/browse/SOLR-12181
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-12181.patch
>
>
> This may turn out to be as simple as using a {{MetricTrigger}} but it's 
> likely this will require some specialization, and we may want to add this 
> type of trigger anyway for convenience.
> The two control actions associated with this trigger will be SPLITSHARD and 
> (yet nonexistent) MERGESHARD.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12210) Perfomance degradation at Hghi Load

[ROMAN NAZARENKO (JIRA)]

ROMAN NAZARENKO created SOLR-12210:
--

 Summary: Perfomance degradation at Hghi Load
 Key: SOLR-12210
 URL: https://issues.apache.org/jira/browse/SOLR-12210
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Hadoop Integration
Affects Versions: 7.2
Reporter: ROMAN NAZARENKO


When hdfsDataFactory is used and the incoming data stream is large, the rate of 
indexation is degraded. This is not a problem when using a local file system. I 
think the problem is in cleaning hdfsBlockCache. Because the degradation of the 
indexing rate occurs precisely when this cache reaches its maximum value. The 
basis for hdfsBlockCache is caffeine cache, but it is configured to clean only 
when the maximum size is reached. At the same time, nothing prevents using 
timeEviction, I suggest testing the indexing speed using this type of cache 
cleaning.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 38 - Failure

[Apache Jenkins Server]

Error processing tokens: Error while parsing action 
'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input 
position (line 76, pos 4):
)"}
   ^

java.lang.OutOfMemoryError: Java heap space

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

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180496635
  
--- Diff: 
lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java 
---
@@ -151,6 +152,17 @@ public Explanation explain(LeafReaderContext context, 
int doc) throws IOExceptio
   }
   return Explanation.noMatch("Not a match");
 }
+
+@Override
+public Matches matches(LeafReaderContext context, int doc) throws 
IOException {
+  // The default implementation would delegate to the joinQuery's 
Weight, which
+  // matches on children.  We need to match on the parent instead
+  Scorer scorer = scorer(context);
+  if (scorer == null || scorer.iterator().advance(doc) != doc) {
+return null;
+  }
--- End diff --

let's check the two-phase iterator here as well if applicable?


---

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

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180494440
  
--- Diff: lucene/core/src/java/org/apache/lucene/search/Weight.java ---
@@ -69,6 +69,24 @@ protected Weight(Query query) {
*/
   public abstract void extractTerms(Set terms);
 
+  /**
+   * Returns {@link Matches} for a specific document, or {@code null} if 
the document
+   * does not match the parent query
+   *
+   * A query match that contains no position information (for example, a 
Point or
+   * DocValues query) will return {@link Matches#MATCH_WITH_NO_TERMS}
+   *
+   * @param context the reader's context to create the {@link Matches} for
+   * @param doc the document's id relative to the given context's 
reader
+   */
+  public Matches matches(LeafReaderContext context, int doc) throws 
IOException {
+Scorer scorer = scorer(context);
+if (scorer == null || scorer.iterator().advance(doc) != doc) {
--- End diff --

we might want to check the two-phase iterator instead if there is one so 
that `iterator().advance()` doesn't potentially visit millions of candidates 
before finding one that actually matches. See for instance 
ConstantScoreWeight.explain.


---

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

[jira] [Commented] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12158:


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

SOLR-12158: Allow the monteCarlo Stream Evaluator to support variables


> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[GitHub] lucene-solr pull request #345: LUCENE-8229: Add Weight.matches() method

[jpountz]

Github user jpountz commented on a diff in the pull request:

https://github.com/apache/lucene-solr/pull/345#discussion_r180492694
  
--- Diff: 
lucene/core/src/java/org/apache/lucene/search/DisjunctionMatchesIterator.java 
---
@@ -0,0 +1,168 @@
+/*
+ * 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/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.search;
+
+import java.io.IOException;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Objects;
+
+import org.apache.lucene.index.LeafReaderContext;
+import org.apache.lucene.index.PostingsEnum;
+import org.apache.lucene.index.Term;
+import org.apache.lucene.index.Terms;
+import org.apache.lucene.index.TermsEnum;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.BytesRefIterator;
+import org.apache.lucene.util.PriorityQueue;
+
+/**
+ * A {@link MatchesIterator} that combines matches from a set of 
sub-iterators
+ *
+ * Matches are sorted by their start positions, and then by their end 
positions, so that
+ * prefixes sort first.  Matches may overlap, or be duplicated if they 
appear in more
+ * than one of the sub-iterators.
+ */
+final class DisjunctionMatchesIterator implements MatchesIterator {
+
+  /**
+   * Create a {@link DisjunctionMatchesIterator} over a list of terms
+   *
+   * Only terms that have at least one match in the given document will be 
included
+   */
+  static MatchesIterator fromTerms(LeafReaderContext context, int doc, 
String field, List terms) throws IOException {
+for (Term term : terms) {
+  if (Objects.equals(field, term.field()) == false) {
+throw new IllegalArgumentException("Tried to generate iterator 
from terms in multiple fields: expected [" + field + "] but got [" + 
term.field() + "]");
+  }
+}
+return fromTermsEnum(context, doc, field, asBytesRefIterator(terms));
+  }
+
+  private static BytesRefIterator asBytesRefIterator(List terms) {
+return new BytesRefIterator() {
+  int i = 0;
+  @Override
+  public BytesRef next() {
+if (i >= terms.size())
+  return null;
+return terms.get(i++).bytes();
+  }
+};
+  }
+
+  /**
+   * Create a {@link DisjunctionMatchesIterator} over a list of terms 
extracted from a {@link BytesRefIterator}
+   *
+   * Only terms that have at least one match in the given document will be 
included
+   */
+  static MatchesIterator fromTermsEnum(LeafReaderContext context, int doc, 
String field, BytesRefIterator terms) throws IOException {
+List mis = new ArrayList<>();
+Terms t = context.reader().terms(field);
+if (t == null)
+  return null;
+TermsEnum te = t.iterator();
+PostingsEnum reuse = null;
+for (BytesRef term = terms.next(); term != null; term = terms.next()) {
+  if (te.seekExact(term)) {
+PostingsEnum pe = te.postings(reuse, PostingsEnum.OFFSETS);
+if (pe.advance(doc) == doc) {
+  // TODO do we want to use the copied term here, or instead 
create a label that associates all of the TMIs with a single term?
+  mis.add(new TermMatchesIterator(BytesRef.deepCopyOf(term), pe));
+  reuse = null;
+}
+else {
+  reuse = pe;
+}
+  }
+}
+if (mis.size() == 0)
+  return null;
+if (mis.size() == 1)
+  return mis.get(0);
+return new DisjunctionMatchesIterator(mis);
+  }
+
+  static MatchesIterator fromSubIterators(List mis) 
throws IOException {
+if (mis.size() == 0)
+  return null;
+if (mis.size() == 1)
+  return mis.get(0);
+return new DisjunctionMatchesIterator(mis);
+  }
+
+  private final PriorityQueue queue;
+
+  private boolean started = false;
+
+  private DisjunctionMatchesIterator(List matches) throws 
IOException {
+queue = new 

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1687 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1687/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 35403 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.12s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2264: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 71 minutes 52 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

Commit 48325cf8ce8de647300409def9c0b18c116ea307 in lucene-solr's branch 
refs/heads/branch_7x from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48325cf ]

LUCENE-8245: Fix precommit


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Fix precommit


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12158:


Commit 9ebe11f1d952b083ad5e60bc589efb6aa4148a48 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9ebe11f ]

SOLR-12158: Allow the monteCarlo Stream Evaluator to support variables


> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on LUCENE-8245:


I'm still seeing precommit errors. Am about to push out a fix for them.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/539/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseSerialGC

3 tests failed.
FAILED:  
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.testFullImportInnerEntity

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1

C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001\collection1
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-dataimporthandler\test\J1\temp\solr.handler.dataimport.TestSolrEntityProcessorEndToEnd_59CFAF3F0ADDF322-001\tempDir-001

at 
__randomizedtesting.SeedInfo.seed([59CFAF3F0ADDF322:A8B8038AABBE80B5]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:318)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd$SolrInstance.tearDown(TestSolrEntityProcessorEndToEnd.java:360)
at 
org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.tearDown(TestSolrEntityProcessorEndToEnd.java:142)
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:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:992)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Updated] (SOLR-12205) SOLR-7887 broke javadoc:jar in maven

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-12205:
-
Affects Version/s: (was: 7.3)
   7.4

> SOLR-7887 broke javadoc:jar in maven
> 
>
> Key: SOLR-12205
> URL: https://issues.apache.org/jira/browse/SOLR-12205
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 7.4, master (8.0)
>Reporter: Daniel Collins
>Assignee: Steve Rowe
>Priority: Major
>  Labels: maven
> Fix For: 7.4
>
>
> Commit 27e5c8dd31 added the -proc:none option both to the compiler and to the 
> javadoc command line.  That is not a javadoc option, so mvn javadoc:jar fails 
> both on master and branch_7x.
> The following fix works for me:
> {code:java}
> diff --git a/dev-tools/maven/pom.xml.template 
> b/dev-tools/maven/pom.xml.template
> index 4e21ca0e13..50299a3cda 100644
> --- a/dev-tools/maven/pom.xml.template
> +++ b/dev-tools/maven/pom.xml.template
> @@ -238,7 +238,6 @@
> true
> -Xdoclint:all
> -Xdoclint:-missing
> - -proc:none
> 
> 
> 
> {code}
> The ant build is fine, its just the maven build which is affected.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [1/2] lucene-solr:master: LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Karl Wright]

Should be resolved now.
Sorry for the noise!

Karl


On Tue, Apr 10, 2018 at 9:03 AM, Adrien Grand  wrote:

> Hey Karl,
>
> The calls to Math.toDegrees seem to have made precommit angry.
>
> Le mar. 10 avr. 2018 à 12:57,  a écrit :
>
>> Repository: lucene-solr
>> Updated Branches:
>>   refs/heads/master d45211d53 -> b65229c90
>>
>>
>> LUCENE-8245: Add more tests that demonstrate problems with
>> GeoComplexPolygon.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/
>> 661fdf3a
>> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/661fdf3a
>> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/661fdf3a
>>
>> Branch: refs/heads/master
>> Commit: 661fdf3a43e6d7a8b8b28254f69387209bafcd75
>> Parents: 1cd8597
>> Author: Karl Wright 
>> Authored: Tue Apr 10 06:57:13 2018 -0400
>> Committer: Karl Wright 
>> Committed: Tue Apr 10 06:57:13 2018 -0400
>>
>> --
>>  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  57 +++-
>>  .../geom/RandomGeo3dShapeGenerator.java |   2 +-
>>  .../spatial3d/geom/RandomGeoPolygonTest.java| 141
>> +++
>>  3 files changed, 198 insertions(+), 2 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/
>> 661fdf3a/lucene/spatial3d/src/test/org/apache/lucene/
>> spatial3d/geom/GeoPolygonTest.java
>> --
>> diff --git 
>> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
>> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> index ee2217d..46750d4 100755
>> --- a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> +++ b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/
>> geom/GeoPolygonTest.java
>> @@ -21,12 +21,14 @@ import java.util.List;
>>  import java.util.BitSet;
>>  import java.util.Collections;
>>
>> +import org.apache.lucene.util.LuceneTestCase;
>> +
>>  import org.junit.Test;
>>  import static org.junit.Assert.assertEquals;
>>  import static org.junit.Assert.assertFalse;
>>  import static org.junit.Assert.assertTrue;
>>
>> -public class GeoPolygonTest {
>> +public class GeoPolygonTest extends LuceneTestCase {
>>
>>@Test
>>public void testPolygonPointFiltering() {
>> @@ -1518,5 +1520,58 @@ shape:
>>  final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(12.282452091883385), Geo3DUtil.fromDegrees(-1.
>> 91633079336513E-11));
>>  assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>>}
>> +
>> +  @Test
>> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
>> +  public void testLUCENE8245_case2() {
>> +//POLYGON((5.512285089810178 -26.833721534785912,12.13983320542565
>> -16.085163683089583,4.868755337835201 -9.167423203860656,0.0
>> -5.261747514529465,-15.696549288211289 -21.362181191487718,5.512285089810178
>> -26.833721534785912))
>> +final List points = new ArrayList<>();
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-26.833721534785912), Geo3DUtil.fromDegrees(5.
>> 512285089810178)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-16.085163683089583), Geo3DUtil.fromDegrees(12.
>> 13983320542565)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE, 
>> Geo3DUtil.fromDegrees(-9.167423203860656),
>> Geo3DUtil.fromDegrees(4.868755337835201)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE, 
>> Geo3DUtil.fromDegrees(-5.261747514529465),
>> Geo3DUtil.fromDegrees(0.0)));
>> +points.add(new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-21.362181191487718), Geo3DUtil.fromDegrees(-15.
>> 696549288211289)));
>> +final GeoPolygonFactory.PolygonDescription description = new
>> GeoPolygonFactory.PolygonDescription(points);
>> +final GeoPolygon polygon = GeoPolygonFactory.
>> makeGeoPolygon(PlanetModel.SPHERE, description);
>> +final GeoPolygon largePolygon = GeoPolygonFactory.
>> makeLargeGeoPolygon(PlanetModel.SPHERE, Collections.singletonList(
>> description));
>> +//POINT(-6.994273817216168E-11 -1.6915596606526662E-292)
>> +final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
>> Geo3DUtil.fromDegrees(-1.6915596606526662E-292),
>> Geo3DUtil.fromDegrees(-6.994273817216168E-11));
>> +assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>> +  }
>> +
>> +  @Test
>> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
>> +  public void testLUCENE8245_case3() {
>> +//POLYGON((144.76249846857021 8.828705232593283,166.00162989841027
>> -8.5E-322,157.03429484830787 64.92565566857392,108.64696979831984
>> 

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Fix precommit.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8246) Allow to customize the number of deletes a merge claims

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-8246:


+1

> Allow to customize the number of deletes a merge claims
> ---
>
> Key: LUCENE-8246
> URL: https://issues.apache.org/jira/browse/LUCENE-8246
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 7.4, master (8.0)
>Reporter: Simon Willnauer
>Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8246.patch
>
>
> With the introduction of soft deletes no every merge claims all documents 
> that are marked as deleted in the segment readers. MergePolicies still need 
> to do accurate accounting in order to select segments for merging and need to 
> decide if segments are merged. This chance allows the merge policy to 
> customize the number of deletes a merge of a segment claims.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21795/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 35293 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.11s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 75 minutes 38 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[jira] [Commented] (SOLR-12203) Error in response for field containing date. Unexpected state.

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-12203:
---

Please raise issues like this on the user's list first, when we determine that 
it's a code issue, then we usually raise a JIRA.

Did you change your schema at any point and _not_ rebuild your collection from 
scratch? Or if you upgraded did you use your old schema types or just use a 7x 
one? Because this kind of looks like you have some segments with one definition 
for a field and other segments with a different definition.



> Error in response for field containing date. Unexpected state.
> --
>
> Key: SOLR-12203
> URL: https://issues.apache.org/jira/browse/SOLR-12203
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Schema and Analysis
>Affects Versions: 7.2.1, 7.3
>Reporter: Jeroen Steggink
>Priority: Minor
>
> I get the following error:
> {noformat}
> java.lang.AssertionError: Unexpected state. Field: 
> stored,indexed,tokenized,omitNorms,indexOptions=DOCSds_lastModified:2013-10-04T22:25:11Z
> at org.apache.solr.schema.DatePointField.toObject(DatePointField.java:154)
> at org.apache.solr.schema.PointField.write(PointField.java:198)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:141)
> at 
> org.apache.solr.response.JSONWriter.writeSolrDocument(JSONResponseWriter.java:374)
> at 
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)
> at 
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)
> at 
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)
> at 
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)
> at 
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)
> at 
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)
> at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)
> at org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:788)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
> at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
> at 
> 

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8245:
-

Well, I have a fix committed for case2.  But the fix only narrowly applies to 
that failure, apparently.  The full fix requires new math: I need to be able to 
determine, somehow, if the surface path of a plane which connects two points 
stays everywhere within MINIMUM_RESOLUTION of another plane.  I'll have to 
think that through but there's no more time today.

> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope 
planes.


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12209) add Paging Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-12209:
---

I'm wondering if two separate functions: *skip* and *limit* might make sense?
{code:java}
limit(skip(search(...), 3), 50){code}
 

> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: mosh
>Priority: Major
>
> Currently the closest streaming expression that allows some sort of 
> pagination is top.
> I propose we add a new streaming expression, which is based on the 
> RankedStream class to add offset to the stream. currently it can only be done 
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export", 
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>  
> [~joel.bernstein] what to you think?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12158) Allow the monteCarlo Stream Evaluator to support variables

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-12158:
--
Attachment: SOLR-12158.patch

> Allow the monteCarlo Stream Evaluator to support variables 
> ---
>
> Key: SOLR-12158
> URL: https://issues.apache.org/jira/browse/SOLR-12158
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-12158.patch
>
>
> This ticket will allow the *monteCarlo* function to assign variables on each 
> iteration. This will allow for much more readable and flexible Monte Carlo 
> simulations. Sample syntax:
> {code:java}
> let(a=normalDistribution(10, 5),
> b=normalDistribution(20, 3),
> c=monteCarlo(d=sample(a),
>  e=sample(b),
>  add(d, e),
>  5)){code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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/jdk-10) - Build # 7262 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7262/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
found:2[index.20180410163438748, index.20180410163439057, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180410163438748, 
index.20180410163439057, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([56198242E8539A81:8DB28284ED7BF332]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:966)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:937)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:913)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: Potential BadApple report this week

[Erick Erickson]

Shalin:

Got it, thanks

On Tue, Apr 10, 2018 at 2:26 AM, Shalin Shekhar Mangar
 wrote:
> Hi Erick,
>
> You can go ahead and mark TestTriggerIntegration as BadApple. I don't think
> anyone is working on it. I was working on TriggerIntegrationTest which is a
> different test.
>
> On Mon, Apr 9, 2018 at 10:02 PM, Erick Erickson 
> wrote:
>>
>> OK, this is the first week I have Hoss' report from two weeks ago so
>> the list is rather lengthy.
>>
>>
>> I believe this test is being actively worked on, so no BadApple for it
>>
>> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testEventQueue
>>
>> ***Tests I'll BadApple on Thursday.
>>
>> These are tests that failed in the last week and _also_ are failures
>> in Hoss' report from two weeks ago, so nobody has addressed them in
>> that time-frame.
>>
>> PLEASE LET ME KNOW BEFORE THURSDAY WHICH OF THESE SHOULD NOT BE BADAPPLEd
>>
>>org.apache.lucene.index.TestIndexSorting.testRandom3
>>org.apache.solr.TestDistributedSearch.test
>>
>> org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions
>>org.apache.solr.cloud.AddReplicaTest.test
>>org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
>>org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test
>>
>> org.apache.solr.cloud.CreateRoutedAliasTest.testCollectionNamesMustBeAbsent
>>org.apache.solr.cloud.CreateRoutedAliasTest.testTimezoneAbsoluteDate
>>org.apache.solr.cloud.CreateRoutedAliasTest.testV1
>>org.apache.solr.cloud.CreateRoutedAliasTest.testV2
>>org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
>>
>> org.apache.solr.cloud.TestCloudRecovery.leaderRecoverFromLogOnStartupTest
>>
>> org.apache.solr.cloud.TestLeaderInitiatedRecoveryThread.testPublishDownState
>>org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest
>>
>> org.apache.solr.cloud.api.collections.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateWithoutCoresThenDelete
>>
>> org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testSelectedCollections
>>org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
>>
>> org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeAddedTriggerRestoreState
>>
>> org.apache.solr.common.cloud.TestCollectionStateWatchers.testDeletionsTriggerWatches
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigReplication
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchWithMasterUrl
>>
>> org.apache.solr.handler.TestReplicationHandler.doTestReplicateAfterCoreReload
>>org.apache.solr.handler.TestReplicationHandler.doTestStressReplication
>>org.apache.solr.handler.admin.AutoscalingHistoryHandlerTest.testHistory
>>
>> org.apache.solr.update.processor.TimeRoutedAliasUpdateProcessorTest.test
>>
>>
>> ***Tests currently BadApple-d
>>
>> *AwaitsFix Annotations:
>>
>>
>> Lucene AwaitsFix
>> TestControlledRealTimeReopenThread.java
>>testCRTReopen()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-5737;)
>>
>> TestICUNormalizer2CharFilter.java
>>testRandomStrings()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-5595;)
>>
>> TestMoreLikeThis.java
>>testMultiFieldShouldReturnPerFieldBooleanQuery()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-7161;)
>>
>> UIMABaseAnalyzerTest.java
>>testRandomStrings()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>> UIMABaseAnalyzerTest.java
>>testRandomStringsWithConfigurationParameters()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>> UIMATypeAwareAnalyzerTest.java
>>testRandomStrings()
>>@Test @AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-3869;)
>>
>>
>> Solr AwaitsFix
>> ReplaceNodeNoTargetTest.java
>>ReplaceNodeNoTargetTest suite
>>@LuceneTestCase.AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/SOLR-11067;)
>>
>> TestCollapseQParserPlugin.java
>>testStringCollapse()
>>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/SOLR-11974;)
>>
>> TestImpersonationWithHadoopAuth.java
>>testForwarding()
>>@AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/HADOOP-9893;)
>>
>> TestLTRReRankingPipeline.java
>>testDifferentTopN()
>>@AwaitsFix(bugUrl = "https://issues.apache.org/jira/browse/SOLR-11134;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testDoubleFieldCache()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-6709;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testFloatFieldCache()
>>@AwaitsFix(bugUrl =
>> "https://issues.apache.org/jira/browse/LUCENE-6709;)
>>
>> TestMinMaxOnMultiValuedField.java
>>testIntFieldCache()
>>@AwaitsFix(bugUrl =
>> 

[jira] [Commented] (SOLR-11971) CVE-2018-1308: XXE attack through DIH's dataConfig request parameter

[Walter Underwood (JIRA)]

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

Walter Underwood commented on SOLR-11971:
-

Sorry, figured it out after I posted that.

 

Does the default config enable the dataimporthandler? We only have it enabled 
on the very old clusters (Solr 3). This is a fine excuse for shutting them down.

> CVE-2018-1308: XXE attack through DIH's dataConfig request parameter
> 
>
> Key: SOLR-11971
> URL: https://issues.apache.org/jira/browse/SOLR-11971
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Major
> Fix For: 6.6.3, 7.3, master (8.0)
>
> Attachments: ApacheSolrDIH-XXE.pdf, SOLR-11971.patch
>
>
> We got a security report about an XXE attack when using the 
> {{=}} of Solr's DataImportHandler. See the attached PDF 
> file with full details (I converted it to PDF, originally it was a DOC file).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12209) add Paging Streaming Expression

[mosh (JIRA)]

mosh created SOLR-12209:
---

 Summary: add Paging Streaming Expression
 Key: SOLR-12209
 URL: https://issues.apache.org/jira/browse/SOLR-12209
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: mosh


Currently the closest streaming expression that allows some sort of pagination 
is top.
I propose we add a new streaming expression, which is based on the RankedStream 
class to add offset to the stream. currently it can only be done in code by 
reading the stream until the desired offset is reached.

The new expression will be used as such:
{{paging(rows=3, search(collection1, q="*:*", qt="/export", 
fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc", 
start=100)}}

{{this will offset the returned stream by 100 documents}}

 

[~joel.bernstein] what to you think?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12160) Document Time Routed Aliases separate from API

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-12160:
-

Patch with suggested edits. Goal mostly was to make it so someone skipping 
around in the docs and not reading linearly from start to end would be better 
able to consume the parts and also I decided to use the term "segment" to refer 
to the time interval represented by a collection in the TRA, which I thought 
added some clarity by relating things to "slices" of time without using the 
term "slice" which has meaning/usage in other contexts already.

> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-11-ea+5) - Build # 1686 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1686/
Java: 64bit/jdk-11-ea+5 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 1744 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J0-20180410_124614_15513935629089448698387.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J2-20180410_124614_15516382972640814637937.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 56 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20180410_124614_1554959568969402384072.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 298 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J0-20180410_125314_11416462754829122027670.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J2-20180410_125314_1206139906454236148981.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/test-framework/test/temp/junit4-J1-20180410_125314_11413188431785871423440.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

[...truncated 1068 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J1-20180410_125440_8432075976365707990394.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J0-20180410_125440_84010357564838546165473.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 3 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/common/test/temp/junit4-J2-20180410_125440_84516912221154623117630.syserr
   [junit4] >>> JVM J2 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J2: EOF 

[...truncated 253 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J0-20180410_125621_1135443378818747601414.syserr
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
   [junit4] <<< JVM J0: EOF 

[...truncated 5 lines...]
   [junit4] JVM J2: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/analysis/icu/test/temp/junit4-J2-20180410_125621_11313899141105397098227.syserr
   [junit4] >>> JVM J2 emitted unexpected 

[jira] [Updated] (SOLR-12160) Document Time Routed Aliases separate from API

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-12160:

Attachment: SOLR-12160.patch

> Document Time Routed Aliases separate from API
> --
>
> Key: SOLR-12160
> URL: https://issues.apache.org/jira/browse/SOLR-12160
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-12160.patch, SOLR-12160.patch, 
> time-routed-aliases.adoc
>
>
> Time Routed Aliases ought to have some documentation that is apart from the 
> API details which are already documented (thanks to Gus for that part).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-MAVEN] Lucene-Solr-Maven-master #2232: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2232/

No tests ran.

Build Log:
[...truncated 31651 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:679: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 13 minutes 16 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Comment Edited] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on LUCENE-8245 at 4/10/18 1:42 PM:
---

Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 
{quote}
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
{quote}



was (Author: mkhludnev):
Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8245) GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on LUCENE-8245:
--

Hello, 
I'm afraid it may hurt precommit like 
https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/ 


> GeoComplexPolygon fails when intersection of travel plane with edge is near 
> polygon point
> -
>
> Key: LUCENE-8245
> URL: https://issues.apache.org/jira/browse/LUCENE-8245
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Major
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8245-case2.patch, LUCENE-8245.jpg, 
> LUCENE-8245.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, 
> LUCENE-8245_case3.patch
>
>
> When a travel plane crosses an edge close to an edge point , it is possible 
> that the above and below planes crosses different edges. In the current 
> implementation one of the crosses is missed because we only check edges that 
> are crossed by the main plain and the {{within}} result is wrong.
> One possible fix is to check always the intersection of planes and edges 
> regardless if they are crossed by main plane. That fixed the above issue but 
> shows other issues like travel planes crossing two edges when it should be 
> only one due to the fuzziness at edge intersections.
> Not sure of a fix so I add the test showing the issue.
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12207) WildcardTypeImpl.getUpperBoundASTs AssertionError from SolrPluginUtils.invokeSetters

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on SOLR-12207:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
58s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 42m 
29s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 46m  8s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12207 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12918375/SOLR-12207.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / b65229c |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_152 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/48/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/48/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> WildcardTypeImpl.getUpperBoundASTs AssertionError from 
> SolrPluginUtils.invokeSetters 
> -
>
> Key: SOLR-12207
> URL: https://issues.apache.org/jira/browse/SOLR-12207
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12207.patch, SOLR-12207.patch, SOLR-12207.patch, 
> SOLR-12207.patch
>
>
> java.lang.AssertionError from SolrMetricManager.loadReporters, 
> SolrPluginUtils.invokeSetters, 
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl is encountered during 
> local besting.  See stacktrace in comment. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11251) Ref Guide: Add docs on JSON facet module

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11251:


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

SOLR-11251: documenting debug=timing hint for JSON Facet API.


> Ref Guide: Add docs on JSON facet module
> 
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON 
> facets, but it never made its way into the published guides. During the 
> conversion of the Ref Guide from Confluence, I made sure the page was 
> exported and converted to {{.adoc}} format.
> The doc was never updated after any of the changes that have been made to 
> JSON facet functionality since it was originally written, so it's possibly 
> inaccurate or just out of date. Someone could take a crack at finishing the 
> conversion cleanup and updating it with latest information so someday it can 
> be part of the published Guide.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11251) Ref Guide: Add docs on JSON facet module

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11251:


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

SOLR-11251: documenting debug=timing hint for JSON Facet API.


> Ref Guide: Add docs on JSON facet module
> 
>
> Key: SOLR-11251
> URL: https://issues.apache.org/jira/browse/SOLR-11251
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, Facet Module
>Reporter: Cassandra Targett
>Assignee: Yonik Seeley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11251.patch, faceted-search.adoc
>
>
> The old Confluence Ref Guide had a draft version of basic docs on JSON 
> facets, but it never made its way into the published guides. During the 
> conversion of the Ref Guide from Confluence, I made sure the page was 
> exported and converted to {{.adoc}} format.
> The doc was never updated after any of the changes that have been made to 
> JSON facet functionality since it was originally written, so it's possibly 
> inaccurate or just out of date. Someone could take a crack at finishing the 
> conversion cleanup and updating it with latest information so someday it can 
> be part of the published Guide.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 35299 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.25s), 6 error(s).

BUILD FAILED
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:633: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/build.xml:117: The 
following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/build.xml:119: 
The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2264:
 The following error occurred while executing this line:
/export/home/jenkins/workspace/Lucene-Solr-7.x-Solaris/lucene/common-build.xml:2466:
 Check for forbidden API calls failed, see log.

Total time: 95 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/export/home/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

Re: [1/2] lucene-solr:master: LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Adrien Grand]

Hey Karl,

The calls to Math.toDegrees seem to have made precommit angry.

Le mar. 10 avr. 2018 à 12:57,  a écrit :

> Repository: lucene-solr
> Updated Branches:
>   refs/heads/master d45211d53 -> b65229c90
>
>
> LUCENE-8245: Add more tests that demonstrate problems with
> GeoComplexPolygon.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/lucene-solr/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/661fdf3a
> Tree: http://git-wip-us.apache.org/repos/asf/lucene-solr/tree/661fdf3a
> Diff: http://git-wip-us.apache.org/repos/asf/lucene-solr/diff/661fdf3a
>
> Branch: refs/heads/master
> Commit: 661fdf3a43e6d7a8b8b28254f69387209bafcd75
> Parents: 1cd8597
> Author: Karl Wright 
> Authored: Tue Apr 10 06:57:13 2018 -0400
> Committer: Karl Wright 
> Committed: Tue Apr 10 06:57:13 2018 -0400
>
> --
>  .../lucene/spatial3d/geom/GeoPolygonTest.java   |  57 +++-
>  .../geom/RandomGeo3dShapeGenerator.java |   2 +-
>  .../spatial3d/geom/RandomGeoPolygonTest.java| 141 +++
>  3 files changed, 198 insertions(+), 2 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/661fdf3a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> --
> diff --git
> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> index ee2217d..46750d4 100755
> ---
> a/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> +++
> b/lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/GeoPolygonTest.java
> @@ -21,12 +21,14 @@ import java.util.List;
>  import java.util.BitSet;
>  import java.util.Collections;
>
> +import org.apache.lucene.util.LuceneTestCase;
> +
>  import org.junit.Test;
>  import static org.junit.Assert.assertEquals;
>  import static org.junit.Assert.assertFalse;
>  import static org.junit.Assert.assertTrue;
>
> -public class GeoPolygonTest {
> +public class GeoPolygonTest extends LuceneTestCase {
>
>@Test
>public void testPolygonPointFiltering() {
> @@ -1518,5 +1520,58 @@ shape:
>  final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(12.282452091883385),
> Geo3DUtil.fromDegrees(-1.91633079336513E-11));
>  assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
>}
> +
> +  @Test
> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
> +  public void testLUCENE8245_case2() {
> +//POLYGON((5.512285089810178 -26.833721534785912,12.13983320542565
> -16.085163683089583,4.868755337835201 -9.167423203860656,0.0
> -5.261747514529465,-15.696549288211289
> -21.362181191487718,5.512285089810178 -26.833721534785912))
> +final List points = new ArrayList<>();
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-26.833721534785912),
> Geo3DUtil.fromDegrees(5.512285089810178)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-16.085163683089583),
> Geo3DUtil.fromDegrees(12.13983320542565)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-9.167423203860656),
> Geo3DUtil.fromDegrees(4.868755337835201)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-5.261747514529465), Geo3DUtil.fromDegrees(0.0)));
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-21.362181191487718),
> Geo3DUtil.fromDegrees(-15.696549288211289)));
> +final GeoPolygonFactory.PolygonDescription description = new
> GeoPolygonFactory.PolygonDescription(points);
> +final GeoPolygon polygon =
> GeoPolygonFactory.makeGeoPolygon(PlanetModel.SPHERE, description);
> +final GeoPolygon largePolygon =
> GeoPolygonFactory.makeLargeGeoPolygon(PlanetModel.SPHERE,
> Collections.singletonList(description));
> +//POINT(-6.994273817216168E-11 -1.6915596606526662E-292)
> +final GeoPoint point = new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(-1.6915596606526662E-292),
> Geo3DUtil.fromDegrees(-6.994273817216168E-11));
> +assertTrue(polygon.isWithin(point) == largePolygon.isWithin(point));
> +  }
> +
> +  @Test
> +  @AwaitsFix(bugUrl="https://issues.apache.org/jira/browse/LUCENE-8245;)
> +  public void testLUCENE8245_case3() {
> +//POLYGON((144.76249846857021 8.828705232593283,166.00162989841027
> -8.5E-322,157.03429484830787 64.92565566857392,108.64696979831984
> 39.10241638996957,102.54234512410089 20.471658760034586,144.76249846857021
> 8.828705232593283))
> +final List points = new ArrayList<>();
> +points.add(new GeoPoint(PlanetModel.SPHERE,
> Geo3DUtil.fromDegrees(8.828705232593283),
> 

[jira] [Commented] (SOLR-12194) Deprecate SolrRequest#setBasicAuthCredentials

[JIRA]

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

Jan Høydahl commented on SOLR-12194:


Or is there a better way we could support any auth scheme on a per-request 
basis through being able to e.g. {{request.setCredentialsProvider(provider)}} 
where Solr will check the request for a provider and use that instead of the 
one configured through the client builder? Have not checked the APIs in detail 
but is the principle worth discussing?

> Deprecate SolrRequest#setBasicAuthCredentials
> -
>
> Key: SOLR-12194
> URL: https://issues.apache.org/jira/browse/SOLR-12194
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Reporter: Jan Høydahl
>Priority: Major
> Fix For: 7.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We should deprecate these methods in {{SolrRequest}}:
> {code:java}
>   public SolrRequest setBasicAuthCredentials(String user, String password)
>   public String getBasicAuthPassword()
>   public String getBasicAuthUser()
> {code}
> The only way forward will be using the ClientBuilderFactory.
> For 7.4 we should deprecate these, and for 8.0 (master) remove them. First we 
> need to migrate some tests etc that uses the old methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-11-ea+5) - Build # 21794 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21794/
Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 35339 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading bundled API signatures: jdk-non-portable
[forbidden-apis] Reading bundled API signatures: jdk-reflection
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning classes for violations...
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:177)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:214)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) 
[Use home-grown methods instead]
[forbidden-apis]   in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest 
(RandomGeoPolygonTest.java:216)
[forbidden-apis] Scanned 164 class file(s) for forbidden API invocations (in 
0.12s), 6 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:119: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2264: 
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/common-build.xml:2466: 
Check for forbidden API calls failed, see log.

Total time: 73 minutes 39 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2
Setting 
ANT_1_8_2_HOME=/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2

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

[JENKINS-MAVEN] Lucene-Solr-Maven-7.x #179: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/179/

No tests ran.

Build Log:
[...truncated 31703 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The 
following error occurred while executing this line:
: Java returned: 1

Total time: 13 minutes 13 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Commented] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-12187:
-

Patch for this ticket
 * Each replica will register a CollectionStateWatcher to unload itself when it 
is removed from clusterstate
 * Reverse changes made by SOLR-12176, changes of that issue is no longer 
needed since zombie leader cannot exist with this patch
 * Test
 * Refactoring ZkController.register() for better handling race-condition cases.

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12187) Replica should watch clusterstate and unload itself if its entry is removed

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-12187:

Attachment: SOLR-12187.patch

> Replica should watch clusterstate and unload itself if its entry is removed
> ---
>
> Key: SOLR-12187
> URL: https://issues.apache.org/jira/browse/SOLR-12187
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-12187.patch, SOLR-12187.patch, SOLR-12187.patch
>
>
> With the introduction of autoscaling framework, we have seen an increase in 
> the number of issues related to the race condition between delete a replica 
> and other stuff.
> Case 1: DeleteReplicaCmd failed to send UNLOAD request to a replica, 
> therefore, forcefully remove its entry from clusterstate, but the replica 
> still function normally and be able to become a leader -> SOLR-12176
> Case 2:
>  * DeleteReplicaCmd enqueue a DELETECOREOP (without sending a request to 
> replica because the node is not live)
>  * The node start and the replica get loaded
>  * DELETECOREOP has not processed hence the replica still present in 
> clusterstate --> pass checkStateInZk
>  * DELETECOREOP is executed, DeleteReplicaCmd finished
>  ** result 1: the replica start recovering, finish it and publish itself as 
> ACTIVE --> state of the replica is ACTIVE
>  ** result 2: the replica throw an exception (probably: NPE) 
> --> state of the replica is DOWN, not join leader election



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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