Re: RE: [VOTE] Release Lucene/Solr 6.4.2 RC1

[380382...@qq.com]

i think java 9 have not be release？



380382...@qq.com
 
From: Uwe Schindler
Date: 2017-03-03 15:42
To: dev@lucene.apache.org
Subject: RE: [VOTE] Release Lucene/Solr 6.4.2 RC1
Hi,
 
Jenkins complains about a compile error in the 6.4 branch, failed already 3 
times (it could be a Java 9 bug, but strangely it only happens in the 6.4 
branch):
 
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/124/
Java: 64bit/jdk-9-ea+158 -XX:+UseCompressedOops -XX:+UseG1GC
 
All tests passed
 
Build Log:
[...truncated 9932 lines...]
[javac] Compiling 323 source files to 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build/solr-solrj/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: reference to NamedList is ambiguous
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac]^
[javac]   both constructor NamedList(Map) in 
NamedList and constructor NamedList(List) in NamedList match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac] ^
[javac] reason: cannot infer type-variable(s) T
[javac]   (argument mismatch; List cannot be converted to Map)
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
 
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build.xml:252: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:536: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:484: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:385: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:405: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:1955: 
Compile failed; see the compiler error output for details.
 
 
This does not happen in master and branch_6x.
 
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
 
From: Ishan Chattopadhyaya [mailto:is...@apache.org] 
Sent: Wednesday, March 1, 2017 9:42 PM
To: dev@lucene.apache.org
Subject: [VOTE] Release Lucene/Solr 6.4.2 RC1
 
Please vote for release candidate 1 for Lucene/Solr 6.4.2 The artifacts can be 
downloaded 
from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
 You can run the smoke tester directly with this command: python3 -u 
dev-tools/scripts/smokeTestRelease.py 
\https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
 Here's my +1
SUCCESS! [0:52:41.429385]

RE: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Uwe Schindler]

Hi,

 

Jenkins complains about a compile error in the 6.4 branch, failed already 3 
times (it could be a Java 9 bug, but strangely it only happens in the 6.4 
branch):

 

Build:   
https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/124/

Java: 64bit/jdk-9-ea+158 -XX:+UseCompressedOops -XX:+UseG1GC

 

All tests passed

 

Build Log:

[...truncated 9932 lines...]

[javac] Compiling 323 source files to 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build/solr-solrj/classes/java

[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: reference to NamedList is ambiguous

[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));

[javac]^

[javac]   both constructor NamedList(Map) in 
NamedList and constructor NamedList(List) in NamedList match

[javac]   where T is a type-variable:

[javac] T extends Object declared in class NamedList

[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: incompatible types: cannot infer type arguments for NamedList<>

[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));

[javac] ^

[javac] reason: cannot infer type-variable(s) T

[javac]   (argument mismatch; List cannot be converted to Map)

[javac]   where T is a type-variable:

[javac] T extends Object declared in class NamedList

[javac] Note: Some input files use or override a deprecated API.

[javac] Note: Recompile with -Xlint:deprecation for details.

[javac] Note: Some input files use unchecked or unsafe operations.

[javac] Note: Recompile with -Xlint:unchecked for details.

[javac] 2 errors

 

BUILD FAILED

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:775: The following 
error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:719: The following 
error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:59: The following error 
occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build.xml:252: The following 
error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:536: The 
following error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:484: The 
following error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:385: The 
following error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:405: The 
following error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:

/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:1955: 
Compile failed; see the compiler error output for details.

 

 

This does not happen in master and branch_6x.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Ishan Chattopadhyaya [mailto:is...@apache.org] 
Sent: Wednesday, March 1, 2017 9:42 PM
To: dev@lucene.apache.org
Subject: [VOTE] Release Lucene/Solr 6.4.2 RC1

 

Please vote for release candidate 1 for Lucene/Solr 6.4.2
 
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
 
You can run the smoke tester directly with this command:
 
python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
 
Here's my +1
SUCCESS! [0:52:41.429385]

[JENKINS-EA] Lucene-Solr-6.4-Linux (64bit/jdk-9-ea+158) - Build # 124 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/124/
Java: 64bit/jdk-9-ea+158 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 9932 lines...]
[javac] Compiling 323 source files to 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build/solr-solrj/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: reference to NamedList is ambiguous
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac]^
[javac]   both constructor NamedList(Map) in 
NamedList and constructor NamedList(List) in NamedList match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac] ^
[javac] reason: cannot infer type-variable(s) T
[javac]   (argument mismatch; List cannot be converted to Map)
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build.xml:252: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:536: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:484: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:385: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:405: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:1955: 
Compile failed; see the compiler error output for details.

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



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

[jira] [Closed] (SOLR-7115) UpdateLog can miss closing transaction log objects.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev closed SOLR-7115.
--

> UpdateLog can miss closing transaction log objects.
> ---
>
> Key: SOLR-7115
> URL: https://issues.apache.org/jira/browse/SOLR-7115
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 6.4, 6.x, master (7.0)
>
> Attachments: SOLR-7115-LargeVolumeEmbeddedTest-fail.txt, 
> SOLR-7115.patch, SOLR-7115.patch, tests-failures-7115.txt
>
>
> I've seen this happen on YourKit and in various tests - especially since 
> adding resource release tracking to the log objects. Now I've got a test that 
> catches it in SOLR-7113.
> It seems that in precommit, if prevTlog is not null, we need to close it 
> because we are going to overwrite prevTlog with a new log.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-7115) UpdateLog can miss closing transaction log objects.

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-7115:
---
Fix Version/s: 6.4

> UpdateLog can miss closing transaction log objects.
> ---
>
> Key: SOLR-7115
> URL: https://issues.apache.org/jira/browse/SOLR-7115
> Project: Solr
>  Issue Type: Bug
>Reporter: Mark Miller
>Assignee: Yonik Seeley
> Fix For: 6.4, 6.x, master (7.0)
>
> Attachments: SOLR-7115-LargeVolumeEmbeddedTest-fail.txt, 
> SOLR-7115.patch, SOLR-7115.patch, tests-failures-7115.txt
>
>
> I've seen this happen on YourKit and in various tests - especially since 
> adding resource release tracking to the log objects. Now I've got a test that 
> catches it in SOLR-7113.
> It seems that in precommit, if prevTlog is not null, we need to close it 
> because we are going to overwrite prevTlog with a new log.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9835) Create another replication mode for SolrCloud

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9835:
---
Attachment: SOLR-9835.patch

[~shalinmangar] Newest patch, ignore block introduced by SOLR-6640.

> Create another replication mode for SolrCloud
> -
>
> Key: SOLR-9835
> URL: https://issues.apache.org/jira/browse/SOLR-9835
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Cao Manh Dat
>Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch, 
> SOLR-9835.patch, SOLR-9835.patch, SOLR-9835.patch
>
>
> The current replication mechanism of SolrCloud is called state machine, which 
> replicas start in same initial state and for each input, the input is 
> distributed across replicas so all replicas will end up with same next state. 
> But this type of replication have some drawbacks
> - The commit (which costly) have to run on all replicas
> - Slow recovery, because if replica miss more than N updates on its down 
> time, the replica have to download entire index from its leader.
> So we create create another replication mode for SolrCloud called state 
> transfer, which acts like master/slave replication. In basically
> - Leader distribute the update to other replicas, but the leader only apply 
> the update to IW, other replicas just store the update to UpdateLog (act like 
> replication).
> - Replicas frequently polling the latest segments from leader.
> Pros:
> - Lightweight for indexing, because only leader are running the commit, 
> updates.
> - Very fast recovery, replicas just have to download the missing segments.
> On CAP point of view, this ticket will trying to promise to end users a 
> distributed systems :
> - Partition tolerance
> - Weak Consistency for normal query : clusters can serve stale data. This 
> happen when leader finish a commit and slave is fetching for latest segment. 
> This period can at most {{pollInterval + time to fetch latest segment}}.
> - Consistency for RTG : if we *do not use DQBs*, replicas will consistence 
> with master just like original SolrCloud mode
> - Weak Availability : just like original SolrCloud mode. If a leader down, 
> client must wait until new leader being elected.
> To use this new replication mode, a new collection must be created with an 
> additional parameter {{liveReplicas=1}}
> {code}
> http://localhost:8983/solr/admin/collections?action=CREATE=newCollection=2=1=1
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1705 - Still Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([401B03FFCED6F68A:F9687781B2FE267F]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:919)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction(ExtractingRequestHandlerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//doc[1]/str[.='simple3']
xml response was: 

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_121) - Build # 2984 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2984/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.update.TestInPlaceUpdatesDistrib.test

Error Message:
'sanitycheck' results against client: 
org.apache.solr.client.solrj.impl.HttpSolrClient@7ca9d582 (not leader) wrong 
[docid] for SolrDocument{id=30, 
id_field_copy_that_does_not_support_in_place_update_s=30, title_s=title30, 
id_i=30, inplace_updatable_float=101.0, _version_=1560829624317902848, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0, [docid]=1284} expected:<1225> but 
was:<1284>

Stack Trace:
java.lang.AssertionError: 'sanitycheck' results against client: 
org.apache.solr.client.solrj.impl.HttpSolrClient@7ca9d582 (not leader) wrong 
[docid] for SolrDocument{id=30, 
id_field_copy_that_does_not_support_in_place_update_s=30, title_s=title30, 
id_i=30, inplace_updatable_float=101.0, _version_=1560829624317902848, 
inplace_updatable_int_with_default=666, 
inplace_updatable_float_with_default=42.0, [docid]=1284} expected:<1225> but 
was:<1284>
at 
__randomizedtesting.SeedInfo.seed([112AB613688FE79D:997E89C9C6738A65]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.assertDocIdsAndValuesInResults(TestInPlaceUpdatesDistrib.java:442)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.assertDocIdsAndValuesAgainstAllClients(TestInPlaceUpdatesDistrib.java:413)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.docValuesUpdateTest(TestInPlaceUpdatesDistrib.java:321)
at 
org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:140)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 

[JENKINS] Lucene-Solr-NightlyTests-6.4 - Build # 20 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/20/

4 tests failed.
FAILED:  
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored_idx

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([5A047B097F177FD2:50232A290061DC85]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.waitForRecoveriesToFinish(TestStressCloudBlindAtomicUpdates.java:459)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:304)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_stored_idx(TestStressCloudBlindAtomicUpdates.java:214)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+158) - Build # 19092 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19092/
Java: 64bit/jdk-9-ea+158 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
expected:<3> but was:<2>

Stack Trace:
java.lang.AssertionError: expected:<3> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([ED06E16D2F7E2C9F:A57395D9294D030A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:523)
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:547)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  
org.apache.solr.index.TestSlowCompositeReaderWrapper.testOrdMapsAreCached

Error Message:


Stack 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 3867 - Still Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([4B5D52B89D488BDD:F22E26C6E1605B28]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:919)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction(ExtractingRequestHandlerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//doc[1]/str[.='simple3']
xml response was: 

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_121) - Build # 19091 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19091/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.handler.TestSQLHandler

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.handler.TestSQLHandler: 
1) Thread[id=7410, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler] at java.lang.Thread.sleep(Native Method) 
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSQLHandler: 
   1) Thread[id=7410, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-TestSQLHandler]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.lang.Thread.run(Thread.java:745)
at __randomizedtesting.SeedInfo.seed([C1168D0ED56D1C65]:0)


FAILED:  org.apache.solr.handler.TestSQLHandler.doTest

Error Message:
--> https://127.0.0.1:39592/pm_/n/collection1:Failed to execute sqlQuery 
'select str_s, count(*), sum(field_i), min(field_i), max(field_i), cast(avg(1.0 
* field_i) as float) from collection1 where text='' group by str_s order by 
sum(field_i) asc limit 2' against JDBC connection 'jdbc:calcitesolr:'. Error 
while executing SQL "select str_s, count(*), sum(field_i), min(field_i), 
max(field_i), cast(avg(1.0 * field_i) as float) from collection1 where 
text='' group by str_s order by sum(field_i) asc limit 2": From line 1, 
column 39 to line 1, column 50: No match found for function signature 
min()

Stack Trace:
java.io.IOException: --> https://127.0.0.1:39592/pm_/n/collection1:Failed to 
execute sqlQuery 'select str_s, count(*), sum(field_i), min(field_i), 
max(field_i), cast(avg(1.0 * field_i) as float) from collection1 where 
text='' group by str_s order by sum(field_i) asc limit 2' against JDBC 
connection 'jdbc:calcitesolr:'.
Error while executing SQL "select str_s, count(*), sum(field_i), min(field_i), 
max(field_i), cast(avg(1.0 * field_i) as float) from collection1 where 
text='' group by str_s order by sum(field_i) asc limit 2": From line 1, 
column 39 to line 1, column 50: No match found for function signature 
min()
at 
__randomizedtesting.SeedInfo.seed([C1168D0ED56D1C65:665235AAB8D60FDC]:0)
at 
org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:235)
at 
org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:2325)
at 
org.apache.solr.handler.TestSQLHandler.testBasicGrouping(TestSQLHandler.java:651)
at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Tomás Fernández Löbbe]

+1

SUCCESS! [0:39:00.462019]

On Thu, Mar 2, 2017 at 12:57 PM, Mikhail Khludnev  wrote:

> SUCCESS! [1:33:35.205071]
> Windows 10 Core i7
>
> On Wed, Mar 1, 2017 at 11:42 PM, Ishan Chattopadhyaya 
> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 6.4.2The artifacts can 
>> be downloaded 
>> from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542fYou
>>  can run the smoke tester directly with this command:python3 -u 
>> dev-tools/scripts/smokeTestRelease.py 
>> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542fHere's
>>  my +1
>> SUCCESS! [0:52:41.429385]
>>
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

[jira] [Updated] (SOLR-9986) Implement DatePointField

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9986:
---
Attachment: SOLR-9986.patch

[~tomasflobbe] Good idea. Here are modified patch based on your hint.

> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9986.patch, SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Issue Comment Deleted] (SOLR-10220) The failure message will not disappear even if the error was fixed on solr web UI.

[shangpingping (JIRA)]

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

shangpingping updated SOLR-10220:
-
Comment: was deleted

(was: I did not find a solution from the issue SOLR-10021)

> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-10220) The failure message will not disappear even if the error was fixed on solr web UI.

[shangpingping (JIRA)]

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

shangpingping edited comment on SOLR-10220 at 3/3/17 1:12 AM:
--

I did not find a solution from the issue SOLR-10021


was (Author: pp_shang):
I did not find a solution from the link you give me.

> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10220) The failure message will not disappear even if the error was fixed on solr web UI.

[shangpingping (JIRA)]

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

shangpingping commented on SOLR-10220:
--

I did not find a solution from the link you give me.

> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10220) The failure message will not disappear even if the error was fixed on solr web UI.

[shangpingping (JIRA)]

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

shangpingping updated SOLR-10220:
-
Description: 
The failure message will not disappear even if the error was fixed on solr web 
UI.
The solr web UI always shows  "SolrCore Initialization Failures" and the detail 
message even if the error already be fixed.
How to remove that or how to update that?

  was:
The failure message will not disappeared after the error was fixed on solr web 
UI.
The solr web UI always shows  "SolrCore Initialization Failures" and the detail 
message even if the error already be fixed.
How to remove that or how to update that?


> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_121) - Build # 762 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/762/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:65099/solr;,   
"node_name":"127.0.0.1:65099_solr",   "state":"down"}, 
"core_node2":{   "core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:65098/solr;,   
"node_name":"127.0.0.1:65098_solr",   "state":"active",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"1",   "autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/6)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:65099/solr;,
  "node_name":"127.0.0.1:65099_solr",
  "state":"down"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:65098/solr;,
  "node_name":"127.0.0.1:65098_solr",
  "state":"active",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([F657FD80BBA8CECE:A6026583E28978D3]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[jira] [Created] (SOLR-10223) Cloud example will not start as root even with -force option

[Shawn Heisey (JIRA)]

Shawn Heisey created SOLR-10223:
---

 Summary: Cloud example will not start as root even with -force 
option
 Key: SOLR-10223
 URL: https://issues.apache.org/jira/browse/SOLR-10223
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.4.2
Reporter: Shawn Heisey


Tried starting a cloud example.  It refused to start as root.  This is a good 
thing, but the start is acceptable to me for the testing that I will be doing, 
so I added -force.  It still wouldn't start, probably because the -force option 
was not transferred to the true start commands.

Commands that I tried:

bin/solr start -e cloud -force
bin/solr start -force -e cloud




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10220) The failure message will not disappear even if the error was fixed on solr web UI.

[shangpingping (JIRA)]

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

shangpingping updated SOLR-10220:
-
Summary: The failure message will not disappear even if the error was fixed 
on solr web UI.  (was: The failure message will not disappeared after the error 
was fixed on solr web UI.)

> The failure message will not disappear even if the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappeared after the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7191) Improve stability and startup performance of SolrCloud with thousands of collections

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-7191:


Now that SOLR-10130 has been discovered, there's a possibility that the bigger 
problems I ran into with a repeat test on 6.4 might have been related to that.  
When I find some time, I will need to repeat with 6.4.2 or branch_6x.

I disagree with the status of this issue as FIXED.  No changes have been 
committed in relation to this issue.  At best, the problems I encountered with 
5.0 are the same, and may have gotten worse.

> Improve stability and startup performance of SolrCloud with thousands of 
> collections
> 
>
> Key: SOLR-7191
> URL: https://issues.apache.org/jira/browse/SOLR-7191
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Noble Paul
>  Labels: performance, scalability
> Fix For: 6.3
>
> Attachments: lots-of-zkstatereader-updates-branch_5x.log, 
> SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch, 
> SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch
>
>
> A user on the mailing list with thousands of collections (5000 on 4.10.3, 
> 4000 on 5.0) is having severe problems with getting Solr to restart.
> I tried as hard as I could to duplicate the user setup, but I ran into many 
> problems myself even before I was able to get 4000 collections created on a 
> 5.0 example cloud setup.  Restarting Solr takes a very long time, and it is 
> not very stable once it's up and running.
> This kind of setup is very much pushing the envelope on SolrCloud performance 
> and scalability.  It doesn't help that I'm running both Solr nodes on one 
> machine (I started with 'bin/solr -e cloud') and that ZK is embedded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS-EA] Lucene-Solr-6.4-Linux (64bit/jdk-9-ea+158) - Build # 122 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.4-Linux/122/
Java: 64bit/jdk-9-ea+158 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 9935 lines...]
[javac] Compiling 323 source files to 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build/solr-solrj/classes/java
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: reference to NamedList is ambiguous
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac]^
[javac]   both constructor NamedList(Map) in 
NamedList and constructor NamedList(List) in NamedList match
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] 
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/solrj/src/java/org/apache/solr/common/util/NamedList.java:398:
 error: incompatible types: cannot infer type arguments for NamedList<>
[javac] return new NamedList<>( 
Collections.unmodifiableList(copy.nvPairs));
[javac] ^
[javac] reason: cannot infer type-variable(s) T
[javac]   (argument mismatch; List cannot be converted to Map)
[javac]   where T is a type-variable:
[javac] T extends Object declared in class NamedList
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:775: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:719: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/build.xml:59: The following error 
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/build.xml:252: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:536: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:484: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:385: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/solr/common-build.xml:405: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:501: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.4-Linux/lucene/common-build.xml:1955: 
Compile failed; see the compiler error output for details.

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



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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 763 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild

Error Message:
junit.framework.AssertionFailedError: Unexpected wrapped exception type, 
expected CoreIsClosedException

Stack Trace:
java.util.concurrent.ExecutionException: junit.framework.AssertionFailedError: 
Unexpected wrapped exception type, expected CoreIsClosedException
at 
__randomizedtesting.SeedInfo.seed([653C3F89D25453C7:BAB15D36EC3D06A5]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.handler.component.InfixSuggestersTest.testShutdownDuringBuild(InfixSuggestersTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: junit.framework.AssertionFailedError: Unexpected wrapped exception 
type, expected CoreIsClosedException
at 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6430 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6430/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Exception during query

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_121) - Build # 19090 - Unstable!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Exception during query

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

[jira] [Resolved] (SOLR-10219) diagnose HDFS test problems with Java9 and/or re-enable these tests

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10219.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.5

bq. ...  I think you can cherry-pick your last commit in branch_6x.

Yup, yup -- branch_6x tests seemed to be working fine for me as well, so 
pushing the backport & CHANGES entry.

> diagnose HDFS test problems with Java9 and/or re-enable these tests
> ---
>
> Key: SOLR-10219
> URL: https://issues.apache.org/jira/browse/SOLR-10219
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: Java9
> Fix For: 6.5, master (7.0)
>
>
> As part of SOLR-8874, Uwe disabled all HDFS based tests under java9 at the 
> build.xml/pom.xml level by adding a conditional to the existing 
> {{tests.disableHdfs}} system property (Note: this property exists so that 
> HDFS tests can be disabled by default on windows, but still run on cygwin if 
> users wish to set that property)
> We need to get to the bottom of what exactly the issue(s) are with HDFS and 
> file specific bugs to track the problems



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10219) diagnose HDFS test problems with Java9 and/or re-enable these tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10219:


Commit efdef8993c6f8a5d1d00bc3da2c4091c6dcd63a2 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=efdef89 ]

SOLR-10219: stop defaulting to tests.disableHdfs=true under java9

(cherry picked from commit 4851f399d4b25f76eeb494d7c63844bf6b858fd5)


> diagnose HDFS test problems with Java9 and/or re-enable these tests
> ---
>
> Key: SOLR-10219
> URL: https://issues.apache.org/jira/browse/SOLR-10219
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: Java9
>
> As part of SOLR-8874, Uwe disabled all HDFS based tests under java9 at the 
> build.xml/pom.xml level by adding a conditional to the existing 
> {{tests.disableHdfs}} system property (Note: this property exists so that 
> HDFS tests can be disabled by default on windows, but still run on cygwin if 
> users wish to set that property)
> We need to get to the bottom of what exactly the issue(s) are with HDFS and 
> file specific bugs to track the problems



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10219) diagnose HDFS test problems with Java9 and/or re-enable these tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10219:


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

SOLR-10219: re-enable HDFS tests under JDK9 (CHANGES.txt entry)


> diagnose HDFS test problems with Java9 and/or re-enable these tests
> ---
>
> Key: SOLR-10219
> URL: https://issues.apache.org/jira/browse/SOLR-10219
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: Java9
>
> As part of SOLR-8874, Uwe disabled all HDFS based tests under java9 at the 
> build.xml/pom.xml level by adding a conditional to the existing 
> {{tests.disableHdfs}} system property (Note: this property exists so that 
> HDFS tests can be disabled by default on windows, but still run on cygwin if 
> users wish to set that property)
> We need to get to the bottom of what exactly the issue(s) are with HDFS and 
> file specific bugs to track the problems



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10219) diagnose HDFS test problems with Java9 and/or re-enable these tests

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10219:


Commit 708d08063df71e3380f533345a47b87a8ac728b6 in lucene-solr's branch 
refs/heads/branch_6x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=708d080 ]

SOLR-10219: re-enable HDFS tests under JDK9 (CHANGES.txt entry)

(cherry picked from commit da113fde771adf0b1a6b4676533e8e02cab41f9a)


> diagnose HDFS test problems with Java9 and/or re-enable these tests
> ---
>
> Key: SOLR-10219
> URL: https://issues.apache.org/jira/browse/SOLR-10219
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: Java9
>
> As part of SOLR-8874, Uwe disabled all HDFS based tests under java9 at the 
> build.xml/pom.xml level by adding a conditional to the existing 
> {{tests.disableHdfs}} system property (Note: this property exists so that 
> HDFS tests can be disabled by default on windows, but still run on cygwin if 
> users wish to set that property)
> We need to get to the bottom of what exactly the issue(s) are with HDFS and 
> file specific bugs to track the problems



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1704 - Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([1870CB0540326740:A103BF7B3C1AB7B5]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:919)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:886)
at 
org.apache.solr.handler.extraction.ExtractingRequestHandlerTest.testExtraction(ExtractingRequestHandlerTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//doc[1]/str[.='simple3']
xml response was: 

Re: Stop using SHA-1 and MD5 hashes?

[Shawn Heisey]

On 3/1/2017 8:13 AM, Jan Høydahl wrote:
> Working on LUCENE-5143 I’m revising the README.html files we place in
> the dist folders. Then I started documenting how to validate checksum
> of the downloads in addition to GPG signature, Looks like MD5 can
> still be used for integrity checks
> (https://en.wikipedia.org/wiki/MD5), while the Ant guys claim
> otherwise in https://ant.apache.org/manual/Tasks/checksum.html Will
> our .md5 and .sha1 files still provide security for the downloader
> after Google releases their recent findings or are they only useful to
> check that the download was complete and not partial?

>From what I can see, hashes and signatures are both missing on the
download mirrors for Lucene and Solr.  That's probably prudent for
hashes, but should signatures be there?

I'd expect hashes to be used as a quick "did it download right?" check. 
It's a weak form of authentication also, but as researchers have found,
definitely not foolproof.  Also, any download location with an altered
archive could have altered hashes.

I do not think it would be possible for non-committers to create an
altered GPG signature that validates, as long as the end user obtained
the KEYS file directly from Apache.  If I'm wrong about that, then
perhaps we need an entirely new method of validation.

Thanks,
Shawn


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

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Mikhail Khludnev]

SUCCESS! [1:33:35.205071]
Windows 10 Core i7

On Wed, Mar 1, 2017 at 11:42 PM, Ishan Chattopadhyaya 
wrote:

> Please vote for release candidate 1 for Lucene/Solr 6.4.2The artifacts can be 
> downloaded 
> from:https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542fYou
>  can run the smoke tester directly with this command:python3 -u 
> dev-tools/scripts/smokeTestRelease.py 
> \https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542fHere's
>  my +1
> SUCCESS! [0:52:41.429385]
>
>


-- 
Sincerely yours
Mikhail Khludnev

[jira] [Comment Edited] (LUCENE-7398) Nested Span Queries are buggy

[Paul Elschot (JIRA)]

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

Paul Elschot edited comment on LUCENE-7398 at 3/2/17 8:54 PM:
--

One way to view the problem is that when span end positions are used to 
determine the slop, it becomes impossible to determine an order for moving the 
subspans to a next position.

So one direction out of this could be: use NearSpans that determines the slop 
only by the start positions of the subspans. That leaves only the cases in 
which the subspans can start (and maybe also end) at the same position.
To make sure that all the subspans move forward after a match we could move 
them all forward until after the current match, and while doing that also 
count/collect them for scoring/highlighting as long as they are within the 
match. That should solve the bug reported here, which is about scoring a missed 
matching occurrence.

This limits the required slop to using only the starting positions of the 
subspans. Could this work?



was (Author: paul.elsc...@xs4all.nl):
On way to view the problem is that when span end positions are used to 
determine the slop, it becomes impossible to determine an order for moving the 
subspans to a next position.

So one direction out of this could be: use NearSpans that determines the slop 
only by the start positions of the subspans. That leaves only the cases in 
which the subspans can start (and maybe also end) at the same position.
To make sure that all the subspans move forward after a match we could move 
them all forward until after the current match, and while doing that also 
count/collect them for scoring/highlighting as long as they are within the 
match. That should solve the bug reported here, which is about scoring a missed 
matching occurrence.

This limits the required slop to using only the starting positions of the 
subspans. Could this work?


> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398-20160814.patch, LUCENE-7398-20160924.patch, 
> LUCENE-7398-20160925.patch, LUCENE-7398.patch, LUCENE-7398.patch, 
> LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7398) Nested Span Queries are buggy

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7398:
--

On way to view the problem is that when span end positions are used to 
determine the slop, it becomes impossible to determine an order for moving the 
subspans to a next position.

So one direction out of this could be: use NearSpans that determines the slop 
only by the start positions of the subspans. That leaves only the cases in 
which the subspans can start (and maybe also end) at the same position.
To make sure that all the subspans move forward after a match we could move 
them all forward until after the current match, and while doing that also 
count/collect them for scoring/highlighting as long as they are within the 
match. That should solve the bug reported here, which is about scoring a missed 
matching occurrence.

This limits the required slop to using only the starting positions of the 
subspans. Could this work?


> Nested Span Queries are buggy
> -
>
> Key: LUCENE-7398
> URL: https://issues.apache.org/jira/browse/LUCENE-7398
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.5, 6.x
>Reporter: Christoph Goller
>Assignee: Alan Woodward
>Priority: Critical
> Attachments: LUCENE-7398-20160814.patch, LUCENE-7398-20160924.patch, 
> LUCENE-7398-20160925.patch, LUCENE-7398.patch, LUCENE-7398.patch, 
> LUCENE-7398.patch, TestSpanCollection.java
>
>
> Example for a nested SpanQuery that is not working:
> Document: Human Genome Organization , HUGO , is trying to coordinate gene 
> mapping research worldwide.
> Query: spanNear([body:coordinate, spanOr([spanNear([body:gene, body:mapping], 
> 0, true), body:gene]), body:research], 0, true)
> The query should match "coordinate gene mapping research" as well as 
> "coordinate gene research". It does not match  "coordinate gene mapping 
> research" with Lucene 5.5 or 6.1, it did however match with Lucene 4.10.4. It 
> probably stopped working with the changes on SpanQueries in 5.3. I will 
> attach a unit test that shows the problem.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8593) Integrate Apache Calcite into the SQLHandler

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8593:


[~julianhyde] - I opened CALCITE-1667 for the turkish locale. I had tried the 
explicit passing like the user.timezone and that didn't help either.

> Integrate Apache Calcite into the SQLHandler
> 
>
> Key: SOLR-8593
> URL: https://issues.apache.org/jira/browse/SOLR-8593
> Project: Solr
>  Issue Type: Improvement
>  Components: Parallel SQL
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-8593.patch, SOLR-8593.patch, SOLR-8593.patch
>
>
>The Presto SQL Parser was perfect for phase one of the SQLHandler. It was 
> nicely split off from the larger Presto project and it did everything that 
> was needed for the initial implementation.
> Phase two of the SQL work though will require an optimizer. Here is where 
> Apache Calcite comes into play. It has a battle tested cost based optimizer 
> and has been integrated into Apache Drill and Hive.
> This work can begin in trunk following the 6.0 release. The final query plans 
> will continue to be translated to Streaming API objects (TupleStreams), so 
> continued work on the JDBC driver should plug in nicely with the Calcite work.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7715) Simplify NearSpansUnordered

[Paul Elschot (JIRA)]

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

Paul Elschot commented on LUCENE-7715:
--

Thanks Adrien.

> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9401:
-
Attachment: SOLR-9401.patch

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch, 
> SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Reopened] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul reopened SOLR-9401:
--

failures noted again

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Steve Rowe]

+1

Changes, docs and javadocs look good, and the smoke tester is happy: SUCCESS! 
[0:26:36.341312]

--
Steve
www.lucidworks.com

> On Mar 2, 2017, at 11:54 AM, Adrien Grand  wrote:
> 
> +1 SUCCESS! [1:28:36.969549]
> 
> Le jeu. 2 mars 2017 à 17:47, David Smiley  a écrit :
> The 2nd time I ran it, it worked (47min).  The first time I hit an error that 
> didn't reproduce from TestDistribIDF.testSimpleQuery in which the connection 
> to ZooKeeper was lost (couldn't connect within 30sec).  I saved the stdout 
> log from this portion of the run.  This test isn't listed as a problem in 
> Mark's excel sheet in SOLR-10032; I checked.  If anyone wants further 
> details; I can email, post to JIRA, or whatever.
> 
> I'll be taking this RC and deploying to sizable cluster today/tomorrow and 
> see how it goes.
> 
> ~ David
> 
> On Thu, Mar 2, 2017 at 8:10 AM Shalin Shekhar Mangar  
> wrote:
> +1
> 
> SUCCESS! [1:04:02.154978]
> 
> On Thu, Mar 2, 2017 at 2:12 AM, Ishan Chattopadhyaya  wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.4.2
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > Here's my +1
> > SUCCESS! [0:52:41.429385]
> >
> 
> 
> 
> --
> Regards,
> Shalin Shekhar Mangar.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
> http://www.solrenterprisesearchserver.com


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

[jira] [Commented] (SOLR-9986) Implement DatePointField

[JIRA]

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

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

Looks good. 
{code}
-assertQ(req("q", "dateRemove:*", "indent", "true"), "//result[@numFound = 
'4']");
+if (!isPointField) {
+  assertQ(req("q", "dateRemove:*", "indent", "true"), "//result[@numFound 
= '4']");
+}
{code}
In other cases I modified the query to something like {{dateRemove:\[* TO *\]}} 
to avoid skipping it

> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7730) Better encode length normalization in similarities

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7730:


 Summary: Better encode length normalization in similarities
 Key: LUCENE-7730
 URL: https://issues.apache.org/jira/browse/LUCENE-7730
 Project: Lucene - Core
  Issue Type: Task
Reporter: Adrien Grand


Now that index-time boosts are gone (LUCENE-6819) and that indices record the 
version that was used to create them (for backward compatibility, LUCENE-7703), 
we can look into storing the length normalization factor more efficiently.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9999) Instrument DirectUpdateHandler2

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-:
-

+1 LGTM

> Instrument DirectUpdateHandler2
> ---
>
> Key: SOLR-
> URL: https://issues.apache.org/jira/browse/SOLR-
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-.patch
>
>
> The DirectUpdateHandler2 should implement MetricsProducer and expose stats 
> via the metrics api and configured reporters.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (LUCENE-6819) Deprecate index-time boosts?

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6819.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-6819-deprecation.patch, 
> LUCENE-6819-deprecation.patch, LUCENE-6819-deprecation.patch, 
> LUCENE-6819.patch, LUCENE-6819.patch, LUCENE-6819-wip.patch
>
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-6819) Deprecate index-time boosts?

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6819: Remove index-time boosts.


> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6819-deprecation.patch, 
> LUCENE-6819-deprecation.patch, LUCENE-6819-deprecation.patch, 
> LUCENE-6819.patch, LUCENE-6819.patch, LUCENE-6819-wip.patch
>
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-6819) Deprecate index-time boosts?

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-6819: Deprecate index-time boosts.


> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6819-deprecation.patch, 
> LUCENE-6819-deprecation.patch, LUCENE-6819-deprecation.patch, 
> LUCENE-6819.patch, LUCENE-6819.patch, LUCENE-6819-wip.patch
>
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10219) diagnose HDFS test problems with Java9 and/or re-enable these tests

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-10219:
--

Hi Hoss,
Policeman did not see any new Java 9 test failures. I think you can cherry-pick 
your last commit in branch_6x.

> diagnose HDFS test problems with Java9 and/or re-enable these tests
> ---
>
> Key: SOLR-10219
> URL: https://issues.apache.org/jira/browse/SOLR-10219
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
>  Labels: Java9
>
> As part of SOLR-8874, Uwe disabled all HDFS based tests under java9 at the 
> build.xml/pom.xml level by adding a conditional to the existing 
> {{tests.disableHdfs}} system property (Note: this property exists so that 
> HDFS tests can be disabled by default on windows, but still run on cygwin if 
> users wish to set that property)
> We need to get to the bottom of what exactly the issue(s) are with HDFS and 
> file specific bugs to track the problems



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10076) Hiding keystore and truststore passwords from /admin/info/* outputs

[Mark Miller (JIRA)]

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

Mark Miller reassigned SOLR-10076:
--

Assignee: Mark Miller

> Hiding keystore and truststore passwords from /admin/info/* outputs
> ---
>
> Key: SOLR-10076
> URL: https://issues.apache.org/jira/browse/SOLR-10076
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Mano Kovacs
>Assignee: Mark Miller
> Attachments: SOLR-10076.patch
>
>
> Passing keystore and truststore password is done by system properties, via 
> cmd line parameter.
> As result, {{/admin/info/properties}} and {{/admin/info/system}} will print 
> out the received password.
> Proposing solution to automatically redact value of any system property 
> before output, containing the word {{password}}, and replacing its value with 
> {{**}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (LUCENE-7725) it should be possible to run "ant precommit" with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7725 at 3/2/17 5:49 PM:
---

bq. Stay tuned.

Not working :-( (ECJ 4.6.1)


was (Author: thetaphi):
bq. Stay tuned.

Not working :-(

> it should be possible to run "ant precommit" with java9
> ---
>
> Key: LUCENE-7725
> URL: https://issues.apache.org/jira/browse/LUCENE-7725
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>  Labels: Java9
>
> Eventually we'll want to be sure that {{ant precommit}} works even if you are 
> using java9.
> This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
> linter we use doesn't work on java9 -- so we're blocked on that, and the 
> build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
> currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7725) it should be possible to run "ant precommit" with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7725:
---

bq. Stay tuned.

Not working :-(

> it should be possible to run "ant precommit" with java9
> ---
>
> Key: LUCENE-7725
> URL: https://issues.apache.org/jira/browse/LUCENE-7725
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>  Labels: Java9
>
> Eventually we'll want to be sure that {{ant precommit}} works even if you are 
> using java9.
> This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
> linter we use doesn't work on java9 -- so we're blocked on that, and the 
> build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
> currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7725) it should be possible to run "ant precommit" with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7725:
---

FYI, I also changed the Markdown converter from pegdown to flexmark: LUCENE-7727
You can now build documentation with Java 9. I did not yet try linting with our 
own python-based linter...

> it should be possible to run "ant precommit" with java9
> ---
>
> Key: LUCENE-7725
> URL: https://issues.apache.org/jira/browse/LUCENE-7725
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>  Labels: Java9
>
> Eventually we'll want to be sure that {{ant precommit}} works even if you are 
> using java9.
> This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
> linter we use doesn't work on java9 -- so we're blocked on that, and the 
> build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
> currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7725) it should be possible to run "ant precommit" with java9

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7725:
---

I have no full overview of all bugs (same like you). There is not much visible 
activity around ECJ and Java 9. I am currently trying the latest ECJ version... 
Stay tuned.

> it should be possible to run "ant precommit" with java9
> ---
>
> Key: LUCENE-7725
> URL: https://issues.apache.org/jira/browse/LUCENE-7725
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>  Labels: Java9
>
> Eventually we'll want to be sure that {{ant precommit}} works even if you are 
> using java9.
> This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
> linter we use doesn't work on java9 -- so we're blocked on that, and the 
> build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
> currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Adrien Grand]

+1 SUCCESS! [1:28:36.969549]

Le jeu. 2 mars 2017 à 17:47, David Smiley  a
écrit :

> The 2nd time I ran it, it worked (47min).  The first time I hit an error
> that didn't reproduce from TestDistribIDF.testSimpleQuery in which the
> connection to ZooKeeper was lost (couldn't connect within 30sec).  I saved
> the stdout log from this portion of the run.  This test isn't listed as a
> problem in Mark's excel sheet in SOLR-10032; I checked.  If anyone wants
> further details; I can email, post to JIRA, or whatever.
>
> I'll be taking this RC and deploying to sizable cluster today/tomorrow and
> see how it goes.
>
> ~ David
>
> On Thu, Mar 2, 2017 at 8:10 AM Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
> +1
>
> SUCCESS! [1:04:02.154978]
>
> On Thu, Mar 2, 2017 at 2:12 AM, Ishan Chattopadhyaya 
> wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.4.2
> >
> > The artifacts can be downloaded from:
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > Here's my +1
> > SUCCESS! [0:52:41.429385]
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

[jira] [Updated] (LUCENE-7725) it should be possible to run "ant precommit" with java9

[Hoss Man (JIRA)]

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

Hoss Man updated LUCENE-7725:
-
Description: 
Eventually we'll want to be sure that {{ant precommit}} works even if you are 
using java9.

This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
linter we use doesn't work on java9 -- so we're blocked on that, and the 
build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



  was:Eventually we'll want to be sure that {{ant precommit}} works even if you 
are using java9.


bq. Nevertheless, we can remove the hard fail and just print the warning. But 
I'd not be happy.

I am all in favor of the hard fail (by default) until it works completely -- i 
just wanted to be sure we have open issues for all the "known" java9 problems 
so people reviewing the list in jira have an accurate picture of the situation.

I've updated the description based on the added context you provided. (Thanks)

As far as the upstream bug blocking this: i found the two URLs below, do you 
know if there is a more specific ECJ bug# we can link to?

* https://wiki.eclipse.org/Java9
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=456778



> it should be possible to run "ant precommit" with java9
> ---
>
> Key: LUCENE-7725
> URL: https://issues.apache.org/jira/browse/LUCENE-7725
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>  Labels: Java9
>
> Eventually we'll want to be sure that {{ant precommit}} works even if you are 
> using java9.
> This is currently not possible because the ECJ (Eclipse JDT based) javadoc 
> linter we use doesn't work on java9 -- so we're blocked on that, and the 
> build.xml explicitly fails fast.  (The fail fast logic in build.xml can 
> currently be bypassed via a {{-Dis.jenkins.build=true}} system prop)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[David Smiley]

The 2nd time I ran it, it worked (47min).  The first time I hit an error
that didn't reproduce from TestDistribIDF.testSimpleQuery in which the
connection to ZooKeeper was lost (couldn't connect within 30sec).  I saved
the stdout log from this portion of the run.  This test isn't listed as a
problem in Mark's excel sheet in SOLR-10032; I checked.  If anyone wants
further details; I can email, post to JIRA, or whatever.

I'll be taking this RC and deploying to sizable cluster today/tomorrow and
see how it goes.

~ David

On Thu, Mar 2, 2017 at 8:10 AM Shalin Shekhar Mangar 
wrote:

> +1
>
> SUCCESS! [1:04:02.154978]
>
> On Thu, Mar 2, 2017 at 2:12 AM, Ishan Chattopadhyaya 
> wrote:
> > Please vote for release candidate 1 for Lucene/Solr 6.4.2
> >
> > The artifacts can be downloaded from:
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > You can run the smoke tester directly with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
> >
> > Here's my +1
> > SUCCESS! [0:52:41.429385]
> >
>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Resolved] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved LUCENE-7727.
---
Resolution: Fixed

> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7727: Replace end-of-life Markdown parser "Pegdown" by "Flexmark" for 
compatibility with Java 9


> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7727: Replace end-of-life Markdown parser "Pegdown" by "Flexmark" for 
compatibility with Java 9


> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10220) The failure message will not disappeared after the error was fixed on solr web UI.

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10220.
---
Resolution: Duplicate

First, please ask questions like this on the user's list before raising a JIRA, 
if it's determined that this is indeed an but _then_ raise a JIRA.

Second, I believe this is fixed by of SOLR-10021

> The failure message will not disappeared after the error was fixed on solr 
> web UI.
> --
>
> Key: SOLR-10220
> URL: https://issues.apache.org/jira/browse/SOLR-10220
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 5.3.1
>Reporter: shangpingping
>
> The failure message will not disappeared after the error was fixed on solr 
> web UI.
> The solr web UI always shows  "SolrCore Initialization Failures" and the 
> detail message even if the error already be fixed.
> How to remove that or how to update that?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 3866 - Unstable!

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at http://127.0.0.1:65481/solr/awhollynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 510HTTP ERROR: 510 Problem 
accessing /solr/awhollynewcollection_0/select. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:7},code=510}
 http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028   

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


Error 510 


HTTP ERROR: 510
Problem accessing /solr/awhollynewcollection_0/select. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:7},code=510}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([23F772886C475875:6B82063C6A7477E0]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:595)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:439)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:391)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1361)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1112)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1215)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:523)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 

Re: Solr JMX changes and backwards (in)compatibility

[David Smiley]

Agreed.  I tried to do my share of being a voice of maintaining backwards
compatibility (register MBeans in old place still along with the new place)
but apparently those changes weren't enough?  Andrzej attempted to get your
input
https://issues.apache.org/jira/browse/SOLR-9947?focusedCommentId=15815089=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15815089
but
you didn't respond or notice.  If he hadn't '@' you, I would have as it's
obvious you might have opinions on this matter ;-)
And also related: https://issues.apache.org/jira/browse/SOLR-10035

On Thu, Mar 2, 2017 at 10:45 AM Otis Gospodnetić 
wrote:

> Hi,
>
> While I love all the new metrics in Solr, I think metrics should be
> treated like code/features in terms of how backwards
> compatibility/deprecation is handled. Otherwise, on upgrade, people's
> monitoring breaks and monitoring is kind of important...
>
> Note: Looks like recent Solr metrics changes broke/changed
> previously-existing MBeans...
>
> Don't have the details about what was changed and how exactly, but I see
> people using Sematext SPM for monitoring Solr are reporting this with Solr
> 6.4.1.
>
>
> Otis
> --
> Monitoring - Log Management - Alerting - Anomaly Detection
> Solr & Elasticsearch Consulting Support Training - http://sematext.com/
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Resolved] (SOLR-10221) Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of long lists of synonyms

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10221.
---
Resolution: Invalid

First of all, please raise questions like this on the user's list first before 
raising a JIRA to see if the behavior you see is really a bug or not.

In this case it's not. The problem you're having is that wildcards do not go 
through synonym expansion because synonym filters are not "MultiTermAware". 
That is, they may produce more than one token on output per input token, so 
there is no "correct" behavior. See: 
https://lucidworks.com/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/

> Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of 
> long lists of synonyms
> ---
>
> Key: SOLR-10221
> URL: https://issues.apache.org/jira/browse/SOLR-10221
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.10.4, 6.2
>Reporter: Alexandar Mitsev
>
> We have a field with SynonymFilterFactory for dutch synonyms. Both on index 
> and on query. The word "jacob" and other spellings of "jacob" are presented 
> in 3 very long list of synonyms.
> We have the word "jacobus" indexed in there.
> Search for "jac*", "jacob*" and etc. does not work. It does work for other 
> words. And it does work if the synonyms are not used. Or if the synonyms are 
> only used on query time.
> The two lists of synonyms which somehow brake it are:
> {noformat}
> cobes, cobis, cobus, coobes, iakobus, iakop, ijacob, ijacobis, ijacobus, 
> ijapick, jaacke, jaacob, jaaipik, jaakes, jaakob, jaakoob, jaap, jaapik, 
> jabec, jac., jaccob, jaces, jachop, jacke, jackes, jackob, jackop, jacob, 
> jacobes, jacobis, jacobp, jacobs, jacobus, jacoch, jacoob, jacop, jacq, 
> jacque, jacques, jacquis, jacub, jacus, jaecke, jaeckob, jaecob, jaecques, 
> jaeke, jaekes, jaekob, jaep, jak, jak., jake, jakis, jakke, jakkob, jakkop, 
> jakob, jakobes, jakobi, jakobis, jakobje, jakobus, jakoob, jakoobes, jakop, 
> jakques, jakus, james, japek, japick, japijck, japijk, japik, japje, jappe, 
> jappik, japyck, japyk, jaques, jaquez, jaquis, jeems, jeppik, kobbis, kobes, 
> kobis, kobise, kobus, kobuse, koobes, koobis, koobus, koos, yacob, yacobis, 
> yacobus, yapick => JAKOB
> cobes, cobis, cobus, coobes, coobus, iakobus, iakops, ijacobs, ijapicks, 
> jaabse, jaackis, jaacobs, jaakes, jaakobs, jaakoobs, jaapiks, jaaps, jabex, 
> jabics, jabiks, jac., jacacobs, jaccobs, jaccobsdr, jaccobsz, jaces, jachops, 
> jacis, jackes, jackobes, jackobhs, jackobs, jackops, jacob, jacobdr, jacobes, 
> jacobesz, jacobi, jacobij, jacobis, jacobo, jacobpsz, jacobs, jacobsd, 
> jacobsdr, jacobse, jacobsen, jacobsens, jacobss, jacobsz, jacobszen, 
> jacobszn, jacobszoon, jacobus, jacobussen, jacobusz, jacoby, jacobz, jacobzn, 
> jacochs, jacoobes, jacoobs, jacopdr, jacops, jacopsdr, jacopsz, jacopszn, 
> jacos, jacques, jac.s, jacubs, jacus, jaeckes, jaeckesdr, jaeckobs, jaeckops, 
> jaecobs, jaecobsz, jaekes, jaekobs, jaeques, jakes, jakis, jakkobs, jakkops, 
> jakob, jakobes, jakobessen, jakobij, jakobis, jakobjes, jakobs, jakobsdr, 
> jakobse, jakobsen, jakobus, jakoby, jakobz, jakoobs, jakoops, jakop, jakops, 
> jakques, jaks, jakus, james, jaobs, japeks, japicks, japicksdr, japics, 
> japicx, japiks, japikx, japix, jappedr, jappes, jappesdr, jappesz, jappeszn, 
> jappezn, jappiks, jappis, jaques, jaquesdr, jaquis, jaquisdr, jaquusdr, 
> jcobs, jeppicx, jeppiks, kobbis, kobes, kobijs, kobis, kobises, kobus, 
> kobuses, kobys, koobes, koobis, koobus, yacobs, yapicks => JAKOBS
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Solr JMX changes and backwards (in)compatibility

[Otis Gospodnetić]

Hi,

While I love all the new metrics in Solr, I think metrics should be treated
like code/features in terms of how backwards compatibility/deprecation is
handled. Otherwise, on upgrade, people's monitoring breaks and
monitoring is kind of important...

Note: Looks like recent Solr metrics changes broke/changed
previously-existing MBeans...

Don't have the details about what was changed and how exactly, but I see
people using Sematext SPM for monitoring Solr are reporting this with Solr
6.4.1.


Otis
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/

[jira] [Issue Comment Deleted] (SOLR-9898) Documentation for metrics collection and /admin/metrics

[Otis Gospodnetic (JIRA)]

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

Otis Gospodnetic updated SOLR-9898:
---
Comment: was deleted

(was: While I love all the new metrics you are adding, I think metrics should 
be treated like code/features in terms of how backwards 
compatibility/deprecation is handled.  Otherwise, on upgrade, people's 
monitoring breaks and monitoring is kind of important... :)

Note: Looks like recent metrics changes broke/changed previously-existing 
MBeans...)

> Documentation for metrics collection and /admin/metrics
> ---
>
> Key: SOLR-9898
> URL: https://issues.apache.org/jira/browse/SOLR-9898
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 6.4, master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Cassandra Targett
>
> Draft documentation follows.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9898) Documentation for metrics collection and /admin/metrics

[Otis Gospodnetic (JIRA)]

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

Otis Gospodnetic commented on SOLR-9898:


While I love all the new metrics you are adding, I think metrics should be 
treated like code/features in terms of how backwards compatibility/deprecation 
is handled.  Otherwise, on upgrade, people's monitoring breaks and 
monitoring is kind of important... :)

Note: Looks like recent metrics changes broke/changed previously-existing 
MBeans...

> Documentation for metrics collection and /admin/metrics
> ---
>
> Key: SOLR-9898
> URL: https://issues.apache.org/jira/browse/SOLR-9898
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 6.4, master (7.0)
>Reporter: Andrzej Bialecki 
>Assignee: Cassandra Targett
>
> Draft documentation follows.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7619) Add WordDelimiterGraphFilter

[Jigar Shah (JIRA)]

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

Jigar Shah commented on LUCENE-7619:


I will go for snapshot for now. Thanks for suggesting direction :)

Many Thanks!

> Add WordDelimiterGraphFilter
> 
>
> Key: LUCENE-7619
> URL: https://issues.apache.org/jira/browse/LUCENE-7619
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: after.png, before.png, LUCENE-7619.patch, 
> LUCENE-7619.patch, LUCENE-7619.patch
>
>
> Currently, {{WordDelimiterFilter}} doesn't try to set the {{posLen}} 
> attribute and so it creates graphs like this:
> !before.png!
> but with this patch (still a work in progress) it creates this graph instead:
> !after.png!
> This means (today) positional queries when using WDF at search time are 
> buggy, but since we fixed LUCENE-7603, with this change here you should be 
> able to use positional queries with WDGF.
> I'm also trying to produce holes properly (removes logic from the current WDF 
> that swallows a hole when whole token is just delimiters).
> Surprisingly, it's actually quite easy to tweak WDF to create a graph (unlike 
> e.g. {{SynonymGraphFilter}}) because it's already creating the necessary new 
> positions, and its output graph never has side paths, except for single 
> tokens that skip nodes because they have {{posLen > 1}}.  I.e. the only fix 
> to make, I think, is to set {{posLen}} properly.  And it really helps that it 
> does its own "new token buffering + sorting" already.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10221) Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of long lists of synonyms

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-10221:
--

I am not sure that JIRA is the right avenue to resolve it, just yet. You should 
ask this question on the Mailing List first and then - if there is an actual 
bug - it can be tracked in JIRA.

I would recommend doing a couple more tests before going to the Solr mailing 
list. For example:
*) Can you reproduce this with a much smaller synonym set. If you think it is 
about 'jacobus' specifically, then you should be able to see it with just one 
or two synonyms. If it is about the synonym list length, it should happen with 
later terms too
*) What is the significance of two synonyms list. Especially since they both 
contain 'jacobus' (and other terms) but map differently. Perhaps your issue is 
around that, the terms that show up in both lists. I am not actually sure what 
behavior you expect with this configuration
*) What version of Solr is it?
*) What is the field definition?
*) What happens when you test your terms in the Admin UI's Analysis screen 
which shows step by step transformation?

These steps would help you to isolate and explain the situation to get the 
maximum help possible from the list participants.

> Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of 
> long lists of synonyms
> ---
>
> Key: SOLR-10221
> URL: https://issues.apache.org/jira/browse/SOLR-10221
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 4.10.4, 6.2
>Reporter: Alexandar Mitsev
>
> We have a field with SynonymFilterFactory for dutch synonyms. Both on index 
> and on query. The word "jacob" and other spellings of "jacob" are presented 
> in 3 very long list of synonyms.
> We have the word "jacobus" indexed in there.
> Search for "jac*", "jacob*" and etc. does not work. It does work for other 
> words. And it does work if the synonyms are not used. Or if the synonyms are 
> only used on query time.
> The two lists of synonyms which somehow brake it are:
> {noformat}
> cobes, cobis, cobus, coobes, iakobus, iakop, ijacob, ijacobis, ijacobus, 
> ijapick, jaacke, jaacob, jaaipik, jaakes, jaakob, jaakoob, jaap, jaapik, 
> jabec, jac., jaccob, jaces, jachop, jacke, jackes, jackob, jackop, jacob, 
> jacobes, jacobis, jacobp, jacobs, jacobus, jacoch, jacoob, jacop, jacq, 
> jacque, jacques, jacquis, jacub, jacus, jaecke, jaeckob, jaecob, jaecques, 
> jaeke, jaekes, jaekob, jaep, jak, jak., jake, jakis, jakke, jakkob, jakkop, 
> jakob, jakobes, jakobi, jakobis, jakobje, jakobus, jakoob, jakoobes, jakop, 
> jakques, jakus, james, japek, japick, japijck, japijk, japik, japje, jappe, 
> jappik, japyck, japyk, jaques, jaquez, jaquis, jeems, jeppik, kobbis, kobes, 
> kobis, kobise, kobus, kobuse, koobes, koobis, koobus, koos, yacob, yacobis, 
> yacobus, yapick => JAKOB
> cobes, cobis, cobus, coobes, coobus, iakobus, iakops, ijacobs, ijapicks, 
> jaabse, jaackis, jaacobs, jaakes, jaakobs, jaakoobs, jaapiks, jaaps, jabex, 
> jabics, jabiks, jac., jacacobs, jaccobs, jaccobsdr, jaccobsz, jaces, jachops, 
> jacis, jackes, jackobes, jackobhs, jackobs, jackops, jacob, jacobdr, jacobes, 
> jacobesz, jacobi, jacobij, jacobis, jacobo, jacobpsz, jacobs, jacobsd, 
> jacobsdr, jacobse, jacobsen, jacobsens, jacobss, jacobsz, jacobszen, 
> jacobszn, jacobszoon, jacobus, jacobussen, jacobusz, jacoby, jacobz, jacobzn, 
> jacochs, jacoobes, jacoobs, jacopdr, jacops, jacopsdr, jacopsz, jacopszn, 
> jacos, jacques, jac.s, jacubs, jacus, jaeckes, jaeckesdr, jaeckobs, jaeckops, 
> jaecobs, jaecobsz, jaekes, jaekobs, jaeques, jakes, jakis, jakkobs, jakkops, 
> jakob, jakobes, jakobessen, jakobij, jakobis, jakobjes, jakobs, jakobsdr, 
> jakobse, jakobsen, jakobus, jakoby, jakobz, jakoobs, jakoops, jakop, jakops, 
> jakques, jaks, jakus, james, jaobs, japeks, japicks, japicksdr, japics, 
> japicx, japiks, japikx, japix, jappedr, jappes, jappesdr, jappesz, jappeszn, 
> jappezn, jappiks, jappis, jaques, jaquesdr, jaquis, jaquisdr, jaquusdr, 
> jcobs, jeppicx, jeppiks, kobbis, kobes, kobijs, kobis, kobises, kobus, 
> kobuses, kobys, koobes, koobis, koobus, yacobs, yapicks => JAKOBS
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_121) - Build # 761 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/761/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"", "path":"/test1", "httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([800D6A0B5AD88B72:5840475CAD052ED2]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Comment Edited] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-7727 at 3/2/17 1:53 PM:
---

New patch with cleanup:

- remove of Pegdown compatibility layer (minimal dependencies)
- auto-generate IDs (remove {{}}, so I also removed the regex for 
website publishing
- extract HTML title from AST). I verified the autogen'd IDs are identical.

I think that's ready. I will commit it later this afternoon.


was (Author: thetaphi):
New patch with cleanup:
- remove of Pegdown compatibility layer (minimal dependencies)
- auto-generate IDs (remove {{}}, so I also removed the regex for 
website publishing
- extract HTML title from AST
I think that's ready. I will commit it later this afternoon.

> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7727:
--
Fix Version/s: 6.5
   master (7.0)

> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7672) CachingNaiveBayesClassifier doesn't compute log prior.

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7672:
-
Affects Version/s: (was: 6.5.0)

> CachingNaiveBayesClassifier doesn't compute log prior.
> --
>
> Key: LUCENE-7672
> URL: https://issues.apache.org/jira/browse/LUCENE-7672
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/classification
>Affects Versions: master (7.0), 6.3, 6.4, 6.5, 6.4.1
>Reporter: Kevin Crosby
>  Labels: newbie, patch
> Fix For: master (7.0)
>
> Attachments: LUCENE-7672.patch
>
>
> The CachingNaiveBayesClassifier gives different results than the 
> SimpleNaiveBayesClassifier.  This is due to the fact that the 
> CachineNaiveBayesClassifier does not calculate the log prior on the class 
> (category) names, as it should.
> This bug has been fixed, and a patch has been attached to this issue.
> This affects master, as well as previous releases up to version 6.4.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7662) Index with missing files should throw CorruptIndexException

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7662:
-
Fix Version/s: (was: 6.5.0)
   6.5

> Index with missing files should throw CorruptIndexException
> ---
>
> Key: LUCENE-7662
> URL: https://issues.apache.org/jira/browse/LUCENE-7662
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 6.4
>Reporter: Mike Drob
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7662.patch, LUCENE-7662.patch, LUCENE-7662.patch
>
>
> Similar to what we did in LUCENE-7592 for EOF, we should catch missing files 
> and rethrow those as CorruptIndexException.
> If a particular codec can handle missing files, it should be proactive check 
> for those optional files and not throw anything, so I think we can safely do 
> this at SegmentReader or SegmentCoreReaders level.
> Stack trace copied from SOLR-10006:
> {noformat}
> Caused by: java.nio.file.NoSuchFileException: 
> /Users/Erick/apache/solrVersions/trunk/solr/example/cloud/node3/solr/eoe_shard1_replica1/data/index/_1_Lucene50_0.doc
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
>   at java.nio.channels.FileChannel.open(FileChannel.java:287)
>   at java.nio.channels.FileChannel.open(FileChannel.java:335)
>   at 
> org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:238)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:192)
>   at 
> org.apache.solr.core.MetricsDirectoryFactory$MetricsDirectory.openInput(MetricsDirectoryFactory.java:334)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader.(Lucene50PostingsReader.java:81)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat.fieldsProducer(Lucene50PostingsFormat.java:442)
>   at 
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:292)
>   at 
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:372)
>   at 
> org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:109)
>   at org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
>   at 
> org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:143)
>   at 
> org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:195)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103)
>   at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:473)
>   at 
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103)
>   at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79)
>   at 
> org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39)
>   at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1958)
>   ... 12 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7707) Only assign ScoreDoc#shardIndex if it was already assigned to non default (-1) value

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7707:
-
Fix Version/s: (was: 6.5.0)
   6.5

> Only assign ScoreDoc#shardIndex if it was already assigned to non default 
> (-1) value
> 
>
> Key: LUCENE-7707
> URL: https://issues.apache.org/jira/browse/LUCENE-7707
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7707.patch, LUCENE-7707.patch, LUCENE-7707.patch, 
> LUCENE-7707.patch, LUCENE-7707.patch, LUCENE-7707.patch, LUCENE-7707.patch, 
> LUCENE-7707.patch
>
>
> When you use TopDocs.merge today it always overrides the ScoreDoc#shardIndex 
> value. The assumption that is made here is that all shard results are merges 
> at once which is not necessarily the case. If for instance incremental merge 
> phases are applied the shard index doesn't correspond to the index in the 
> outer TopDocs array. To make this a backwards compatible but yet 
> non-controversial change we could change the internals of TopDocs#merge to 
> only assign this value unless it's not been assigned before to a non-default 
> (-1) value to allow multiple or sparse top docs merging.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7704) SysnonymGraphFilter doesn't respect ignoreCase parameter

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7704:
-
Fix Version/s: (was: 6.5.0)
   6.5

> SysnonymGraphFilter doesn't respect ignoreCase parameter
> 
>
> Key: LUCENE-7704
> URL: https://issues.apache.org/jira/browse/LUCENE-7704
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 6.4.1
>Reporter: Sebastian Yonekura Baeza
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7704.patch
>
>
> Hi, it seems that SynonymGraphFilter doesn't respect ignoreCase parameter. In 
> particular this test doesn't pass:
> {code:title=UppercaseSynonymMapTest.java|borderStyle=solid}
> package com.mapcity.suggest.lucene;
> import org.apache.lucene.analysis.Analyzer;
> import org.apache.lucene.analysis.TokenStream;
> import org.apache.lucene.analysis.Tokenizer;
> import org.apache.lucene.analysis.core.WhitespaceTokenizer;
> import org.apache.lucene.analysis.synonym.SynonymGraphFilter;
> import org.apache.lucene.analysis.synonym.SynonymMap;
> import org.apache.lucene.util.CharsRef;
> import org.apache.lucene.util.CharsRefBuilder;
> import org.junit.Test;
> import java.io.IOException;
> import static 
> org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents;
> /**
>  * @author Sebastian Yonekura
>  * Created on 22-02-17
>  */
> public class UppercaseSynonymMapTest {
> @Test
> public void analyzerTest01() throws IOException {
> // This passes
> testAssertMapping("word", "synonym");
> // this one not
> testAssertMapping("word".toUpperCase(), "synonym");
> }
> private void testAssertMapping(String inputString, String outputString) 
> throws IOException {
> SynonymMap.Builder builder = new SynonymMap.Builder(false);
> CharsRef input = SynonymMap.Builder.join(inputString.split(" "), new 
> CharsRefBuilder());
> CharsRef output = SynonymMap.Builder.join(outputString.split(" "), 
> new CharsRefBuilder());
> builder.add(input, output, true);
> Analyzer analyzer = new CustomAnalyzer(builder.build());
> TokenStream tokenStream = analyzer.tokenStream("field", inputString);
> assertTokenStreamContents(tokenStream, new String[]{
> outputString, inputString
> });
> }
> static class CustomAnalyzer extends Analyzer {
> private SynonymMap synonymMap;
> CustomAnalyzer(SynonymMap synonymMap) {
> this.synonymMap = synonymMap;
> }
> @Override
> protected TokenStreamComponents createComponents(String s) {
> Tokenizer tokenizer = new WhitespaceTokenizer();
> TokenStream tokenStream = new SynonymGraphFilter(tokenizer, 
> synonymMap, true); // Ignore case True
> return new TokenStreamComponents(tokenizer, tokenStream);
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7664) Deprecate GeoPointField & queries

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7664:
-
Fix Version/s: (was: 6.5.0)
   6.5

> Deprecate GeoPointField & queries
> -
>
> Key: LUCENE-7664
> URL: https://issues.apache.org/jira/browse/LUCENE-7664
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7664.patch
>
>
> The new dimensional points implementations for geo distance, polygon, shape 
> filtering are substantially faster and creates a smaller index than the 
> postings based {{GeoPointField}}.  They also offer nearest neighbor search, 
> which {{GeoPointField}} doesn't.
> I think we should deprecate {{GeoPointField}} and focus on the points 
> implementations.
> We have still other legacy postings based geo implementations but I think we 
> should keep them for now since they have functionality that points doesn't 
> yet have: the ability to index a shape and search for shapes overlapping the 
> indexed shapes.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (LUCENE-7715) Simplify NearSpansUnordered

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7715.
--
   Resolution: Fixed
Fix Version/s: 6.5
   master (7.0)

> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Fix For: master (7.0), 6.5
>
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7715) Simplify NearSpansUnordered

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7715: NearSpansUnordered simplifications.


> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7715) Simplify NearSpansUnordered

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7715: NearSpansUnordered simplifications.


> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10104) BlockDirectoryCache release hooks do not work with multiple directories

[Mike Drob (JIRA)]

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

Mike Drob commented on SOLR-10104:
--

{quote}I have been considering the non global cache a bug. Just kept it around 
for
Back compact mostly. And that global is kind of configured funky being in 
solrconfig.xml.
{quote}
I filed SOLR-10222 for this

> BlockDirectoryCache release hooks do not work with multiple directories
> ---
>
> Key: SOLR-10104
> URL: https://issues.apache.org/jira/browse/SOLR-10104
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Affects Versions: 6.4
>Reporter: Mike Drob
>Assignee: Mark Miller
> Fix For: 6.5, master (7.0)
>
>
> https://github.com/apache/lucene-solr/blob/5738c293f0c3f346b3e3e52c937183060d59cba1/solr/core/src/java/org/apache/solr/store/blockcache/BlockDirectoryCache.java#L53
> {code}
> if (releaseBlocks) {
>   keysToRelease = Collections.newSetFromMap(new 
> ConcurrentHashMap(1024, 0.75f, 512));
>   blockCache.setOnRelease(new OnRelease() {
> 
> @Override
> public void release(BlockCacheKey key) {
>   keysToRelease.remove(key);
> }
>   });
> }
> {code}
> If we're using the global block cache option and create multiple directories 
> using the same factory, we will lose the release hook for the first 
> directory. I think we can verify that by creating a server with multiple 
> cores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10222) Remove per-core blockcache

[Mike Drob (JIRA)]

Mike Drob created SOLR-10222:


 Summary: Remove per-core blockcache
 Key: SOLR-10222
 URL: https://issues.apache.org/jira/browse/SOLR-10222
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: hdfs
Reporter: Mike Drob


We should clean up some of the details around the use of the block cache.

Can we deprecate the per-core blockcache usage in Solr 6.x and remove it from 
7? Or does that need to happen in 7 and 8?

Maybe it makes sense to move the configuration to solr.xml at the same time



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9401:
--

>From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6429/]:

{noformat}
Checking out Revision f57d829fa051e96b10a430f5e54017e58e5c8101 
(refs/remotes/origin/master)
{noformat}

So: yes, that is the master commit on this issue.

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.4.2 RC1

[Shalin Shekhar Mangar]

+1

SUCCESS! [1:04:02.154978]

On Thu, Mar 2, 2017 at 2:12 AM, Ishan Chattopadhyaya  wrote:
> Please vote for release candidate 1 for Lucene/Solr 6.4.2
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.4.2-RC1-rev34a975ca3d4bd7fa121340e5bcbf165929e0542f
>
> Here's my +1
> SUCCESS! [0:52:41.429385]
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9401:
--

Is it after the latest commit? 

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-9401:
--

Looks like the timestamp in the header isn't being updated on retry, so retry 
due to exceeded TTL will always fail?: From 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6429/]:

{noformat}
  [junit4]   2> 80196 ERROR 
(TEST-TestPKIAuthenticationPlugin.test-seed#[4FFA59D74D1DF2B7]) [] 
o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 1488454415787 , 
received timestamp: 1488454421527 , TTL: 5000
  [junit4]   2> 80197 ERROR 
(TEST-TestPKIAuthenticationPlugin.test-seed#[4FFA59D74D1DF2B7]) [] 
o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 1488454415787 , 
received timestamp: 1488454421544 , TTL: 5000
  [junit4]   2> 80198 ERROR 
(TEST-TestPKIAuthenticationPlugin.test-seed#[4FFA59D74D1DF2B7]) [] 
o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 1488454415787 , 
received timestamp: 1488454421544 , TTL: 5000
  [junit4]   2> 80198 INFO  
(TEST-TestPKIAuthenticationPlugin.test-seed#[4FFA59D74D1DF2B7]) [] 
o.a.s.SolrTestCaseJ4 ###Ending test
  [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestPKIAuthenticationPlugin -Dtests.method=test 
-Dtests.seed=4FFA59D74D1DF2B7 -Dtests.slow=true -Dtests.locale=ar-SY 
-Dtests.timezone=CST -Dtests.asserts=true -Dtests.file.encoding=Cp1252
  [junit4] FAILURE 5.89s J1 | TestPKIAuthenticationPlugin.test <<<
  [junit4]> Throwable #1: java.lang.AssertionError: No principal obtained
  [junit4]> at 
__randomizedtesting.SeedInfo.seed([4FFA59D74D1DF2B7:C7AE660DE3E19F4F]:0)
  [junit4]> at 
org.apache.solr.security.TestPKIAuthenticationPlugin.run(TestPKIAuthenticationPlugin.java:178)
  [junit4]> at 
org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:104)
{noformat}

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_121) - Build # 6429 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6429/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery

Error Message:
Expected a collection with one shard and two replicas null Last available 
state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node1":{   "core":"MissingSegmentRecoveryTest_shard1_replica2",   
"base_url":"http://127.0.0.1:58648/solr;,   
"node_name":"127.0.0.1:58648_solr",   "state":"active",   
"leader":"true"}, "core_node2":{   
"core":"MissingSegmentRecoveryTest_shard1_replica1",   
"base_url":"http://127.0.0.1:58651/solr;,   
"node_name":"127.0.0.1:58651_solr",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"1",   
"autoAddReplicas":"false"}

Stack Trace:
java.lang.AssertionError: Expected a collection with one shard and two replicas
null
Last available state: 
DocCollection(MissingSegmentRecoveryTest//collections/MissingSegmentRecoveryTest/state.json/8)={
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node1":{
  "core":"MissingSegmentRecoveryTest_shard1_replica2",
  "base_url":"http://127.0.0.1:58648/solr;,
  "node_name":"127.0.0.1:58648_solr",
  "state":"active",
  "leader":"true"},
"core_node2":{
  "core":"MissingSegmentRecoveryTest_shard1_replica1",
  "base_url":"http://127.0.0.1:58651/solr;,
  "node_name":"127.0.0.1:58651_solr",
  "state":"down",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"1",
  "autoAddReplicas":"false"}
at 
__randomizedtesting.SeedInfo.seed([4FFA59D74D1DF2B7:1FAFC1D4143C44AA]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:265)
at 
org.apache.solr.cloud.MissingSegmentRecoveryTest.testLeaderRecovery(MissingSegmentRecoveryTest.java:105)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 

[jira] [Updated] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9401:
-
Fix Version/s: master (7.0)

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-9401.
--
   Resolution: Fixed
Fix Version/s: 6.5

> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Fix For: 6.5
>
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9401:
---

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

SOLR-9401: NPE in TestPKIAuthenticationPlugin. tests would retry for timeout


> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.4 - Build # 19 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.4/19/

6 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsChaosMonkeySafeLeaderTest.test

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

Stack Trace:
java.lang.AssertionError: expected:<0> but was:<1>
at 
__randomizedtesting.SeedInfo.seed([D1031592F6C27740:59572A48583E1AB8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.test(ChaosMonkeySafeLeaderTest.java:146)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:811)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:462)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Updated] (LUCENE-7727) Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated LUCENE-7727:
--
Attachment: LUCENE-7727.patch

New patch with cleanup:
- remove of Pegdown compatibility layer (minimal dependencies)
- auto-generate IDs (remove {{}}, so I also removed the regex for 
website publishing
- extract HTML title from AST
I think that's ready. I will commit it later this afternoon.

> Replace EOL'ed pegdown by flexmark-java for Java 9 compatibility
> 
>
> Key: LUCENE-7727
> URL: https://issues.apache.org/jira/browse/LUCENE-7727
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Attachments: LUCENE-7727.patch, LUCENE-7727.patch
>
>
> The documentation tasks use a library called "pegdown" to convert Markdown to 
> HTML. Unfortunately, the developer of pegdown EOLed it and points the users 
> to a faster replacement: flexmark-java 
> (https://github.com/vsch/flexmark-java).
> This would not be important for us, if pegdown would work with Java 9, but it 
> is also affected by the usual "setAccessible into private Java APIs" issue 
> (see my talk at FOSDEM: 
> https://fosdem.org/2017/schedule/event/jigsaw_challenges/).
> The migration should not be too hard, its just a bit of Groovy Code rewriting 
> and dependency changes.
> This is the pegdown problem:
> {noformat}
> Caused by: java.lang.RuntimeException: Could not determine whether class 
> 'org.pegdown.Parser$$parboiled' has already been loaded
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:213)
> at 
> org.parboiled.transform.ParserTransformer.transformParser(ParserTransformer.java:35)
> at org.parboiled.Parboiled.createParser(Parboiled.java:54)
> ... 50 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make 
> protected final java.lang.Class 
> java.lang.ClassLoader.findLoadedClass(java.lang.String) accessible: module 
> java.base does not "opens java.lang" to unnamed module @551b6736
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:278)
> at 
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:196)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:190)
> at org.parboiled.transform.AsmUtils.findLoadedClass(AsmUtils.java:206)
> ... 52 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9401:
---

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

SOLR-9401: NPE in TestPKIAuthenticationPlugin. tests would retry for timeout


> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9986) Implement DatePointField

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-9986:
---
Attachment: SOLR-9986.patch

Patch for this ticket.
[~tomasflobbe] Please take a look at the patch. 

> Implement DatePointField
> 
>
> Key: SOLR-9986
> URL: https://issues.apache.org/jira/browse/SOLR-9986
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Tomás Fernández Löbbe
> Attachments: SOLR-9986.patch
>
>
> Followup task of SOLR-8396



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10153) UnifiedSolrHighlighter support for CustomSeparatorBreakIterator (LUCENE-6485)

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-10153:
-

[~dsmiley] LUCENE-7729 has incorporated string type separator for 
CustomSeparatorBreakIterator as discussed. I have linked the issue to this JIRA 
itself and patch can be applied on current updated branch. Thanks for 
committing. 

> UnifiedSolrHighlighter support for CustomSeparatorBreakIterator (LUCENE-6485)
> -
>
> Key: SOLR-10153
> URL: https://issues.apache.org/jira/browse/SOLR-10153
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: Amrit Sarkar
>Assignee: David Smiley
> Fix For: 6.5
>
> Attachments: SOLR-10153.patch, SOLR-10153.patch, 
> SOLR_10153_UH_and_PH_hl_customSeparatorChar.patch, 
> SOLR_10153_UH_and_PH_hl_customSeparatorChar.patch
>
>
> Lucene 5.3 added a CustomSeparatorBreakIterator (see LUCENE-6485)
> UnifiedSolrHighlighter should support *CustomSeparatorBreakIterator* along 
> with existing ones, WholeBreakIterator etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar updated LUCENE-7729:
-
Attachment: LUCENE-7729.patch

LUCENE-7729.patch uploaded:

{noformat}
modified:   
lucene/highlighter/src/java/org/apache/lucene/search/postingshighlight/CustomSeparatorBreakIterator.java
modified:   
lucene/highlighter/src/test/org/apache/lucene/search/postingshighlight/TestCustomSeparatorBreakIterator.java
modified:   
lucene/highlighter/src/test/org/apache/lucene/search/uhighlight/LengthGoalBreakIteratorTest.java
modified:   
solr/core/src/java/org/apache/solr/highlight/PostingsSolrHighlighter.java
modified:   
solr/core/src/java/org/apache/solr/highlight/UnifiedSolrHighlighter.java
modified:   
solr/core/src/test/org/apache/solr/highlight/TestPostingsSolrHighlighter.java
modified:   
solr/core/src/test/org/apache/solr/highlight/TestUnifiedSolrHighlighter.java
{noformat}

[~dsmiley] here is our string type separator for Custom break iterator. I used 
char-by-char strings matching technique.

The patch can be applied on current updated branch. Thank you.

> Support for string type separator for CustomSeparatorBreakIterator
> --
>
> Key: LUCENE-7729
> URL: https://issues.apache.org/jira/browse/LUCENE-7729
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: Amrit Sarkar
> Attachments: LUCENE-7729.patch
>
>
> LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
> _char_ passed is found.
> Improved CustomSeparatorBreakIterator; as it now supports separator of string 
> type of arbitrary length.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9401) TestPKIAuthenticationPlugin NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-9401:
---

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

SOLR-9401: NPE in TestPKIAuthenticationPlugin. tests would retry for timeout


> TestPKIAuthenticationPlugin NPE
> ---
>
> Key: SOLR-9401
> URL: https://issues.apache.org/jira/browse/SOLR-9401
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Noble Paul
> Attachments: SOLR-9401.patch, SOLR-9401.patch, SOLR-9401.patch
>
>
> Failure from my Jenkins, doesn't reproduce for me (this is 
> {{tests-failures.txt}}):
> {noformat}
>   2> Creating dataDir: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugi
> n_7AC33B2240CB767D-001/init-core-data-001
>   2> 14521 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (fal
> se) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, 
> clientAuth=NaN)
>   2> 14540 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Starting test
>   2> 15553 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin No SolrAuth header present
>   2> 15843 ERROR 
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.s.PKIAuthenticationPlugin Invalid key request timestamp: 9 ,
>  received timestamp: 1470760833176 , TTL: 5000
>   2> 15843 INFO  
> (TEST-TestPKIAuthenticationPlugin.test-seed#[7AC33B2240CB767D]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending test
>   2> NOTE: download the large Jenkins line-docs file by running 'ant 
> get-jenkins-line-docs' in the lucene directory.
>   2> NOTE: reproduce with: ant test  -Dtestcase=TestPKIAuthenticationPlugin 
> -Dtests.method=test -Dtests.seed=7AC33B2240CB767D -Dtests.slow=true -Dtests.li
> nedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=cs -Dtests.timezone=Europe/Tirane -Dtests.asserts=true 
> -Dtests.file.encoding=U
> TF-8
> [12:40:32.094] ERROR   1.35s J7  | TestPKIAuthenticationPlugin.test <<<
>> Throwable #1: java.lang.NullPointerException
>>at 
> __randomizedtesting.SeedInfo.seed([7AC33B2240CB767D:F29704F8EE371B85]:0)
>>at 
> org.apache.solr.security.TestPKIAuthenticationPlugin.test(TestPKIAuthenticationPlugin.java:144)
> [...]
>   2> 15867 INFO  
> (SUITE-TestPKIAuthenticationPlugin-seed#[7AC33B2240CB767D]-worker) [] 
> o.a.s.SolrTestCaseJ4 ###deleteCore
>   2> NOTE: leaving temporary files on disk at: 
> /var/lib/jenkins/jobs/Lucene-Solr-tests-master/workspace/solr/build/solr-core/test/J7/temp/solr.security.TestPKIAuthenticationPlugin_7AC33B2240CB767D-001
>   2> NOTE: test params are: codec=Asserting(Lucene62): {}, docValues:{}, 
> maxPointsInLeafNode=752, maxMBSortInHeap=5.390190554185364, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=cs, timezone=Europe/Tirane
>   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 1.8.0_77 
> (64-bit)/cpus=16,threads=1,free=255922760,total=336592896
>   2> NOTE: All tests run in this JVM: [TestIndexingPerformance, 
> TestPKIAuthenticationPlugin]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7715) Simplify NearSpansUnordered

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7715:
--

OK, I just applied the patch to understand how it works. It looks good to me, 
I'll merge it soon. Thanks Paul!

> Simplify NearSpansUnordered
> ---
>
> Key: LUCENE-7715
> URL: https://issues.apache.org/jira/browse/LUCENE-7715
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Paul Elschot
>Priority: Minor
> Attachments: LUCENE-7715.patch
>
>
> {code}
> git diff --stat master...
>  .../spans/NearSpansUnordered.java   | 211 -
>  1 file changed, 59 insertions(+), 152 deletions(-)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7729) Support for string type separator for CustomSeparatorBreakIterator

[Amrit Sarkar (JIRA)]

Amrit Sarkar created LUCENE-7729:


 Summary: Support for string type separator for 
CustomSeparatorBreakIterator
 Key: LUCENE-7729
 URL: https://issues.apache.org/jira/browse/LUCENE-7729
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/highlighter
Reporter: Amrit Sarkar


LUCENE-6485: currently CustomSeparatorBreakIterator breaks the text when the 
_char_ passed is found.

Improved CustomSeparatorBreakIterator; as it now supports separator of string 
type of arbitrary length.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-6819) Deprecate index-time boosts?

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6819:
-
Attachment: LUCENE-6819-deprecation.patch

Here is an updated 6.x deprecation patch with CHANGES entries. If there are no 
objections, I will merge shortly as these large patches do not age well and can 
become hard to apply in case of conflicting changes.

> Deprecate index-time boosts?
> 
>
> Key: LUCENE-6819
> URL: https://issues.apache.org/jira/browse/LUCENE-6819
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6819-deprecation.patch, 
> LUCENE-6819-deprecation.patch, LUCENE-6819-deprecation.patch, 
> LUCENE-6819.patch, LUCENE-6819.patch, LUCENE-6819-wip.patch
>
>
> Follow-up of this comment: 
> https://issues.apache.org/jira/browse/LUCENE-6818?focusedCommentId=14934801=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14934801
> Index-time boosts are a very expert feature whose behaviour is tight to the 
> Similarity impl. Additionally users have often be confused by the poor 
> precision due to the fact that we encode values on a single byte. But now we 
> have doc values that allow you to encode any values the way you want with as 
> much precision as you need so maybe we should deprecate index-time boosts and 
> recommend to encode index-time scoring factors into doc values fields instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10221) Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of long lists of synonyms

[Alexandar Mitsev (JIRA)]

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

Alexandar Mitsev updated SOLR-10221:

Description: 
We have a field with SynonymFilterFactory for dutch synonyms. Both on index and 
on query. The word "jacob" and other spellings of "jacob" are presented in 3 
very long list of synonyms.

We have the word "jacobus" indexed in there.

Search for "jac*", "jacob*" and etc. does not work. It does work for other 
words. And it does work if the synonyms are not used. Or if the synonyms are 
only used on query time.

The two lists of synonyms which somehow brake it are:
{noformat}
cobes, cobis, cobus, coobes, iakobus, iakop, ijacob, ijacobis, ijacobus, 
ijapick, jaacke, jaacob, jaaipik, jaakes, jaakob, jaakoob, jaap, jaapik, jabec, 
jac., jaccob, jaces, jachop, jacke, jackes, jackob, jackop, jacob, jacobes, 
jacobis, jacobp, jacobs, jacobus, jacoch, jacoob, jacop, jacq, jacque, jacques, 
jacquis, jacub, jacus, jaecke, jaeckob, jaecob, jaecques, jaeke, jaekes, 
jaekob, jaep, jak, jak., jake, jakis, jakke, jakkob, jakkop, jakob, jakobes, 
jakobi, jakobis, jakobje, jakobus, jakoob, jakoobes, jakop, jakques, jakus, 
james, japek, japick, japijck, japijk, japik, japje, jappe, jappik, japyck, 
japyk, jaques, jaquez, jaquis, jeems, jeppik, kobbis, kobes, kobis, kobise, 
kobus, kobuse, koobes, koobis, koobus, koos, yacob, yacobis, yacobus, yapick => 
JAKOB

cobes, cobis, cobus, coobes, coobus, iakobus, iakops, ijacobs, ijapicks, 
jaabse, jaackis, jaacobs, jaakes, jaakobs, jaakoobs, jaapiks, jaaps, jabex, 
jabics, jabiks, jac., jacacobs, jaccobs, jaccobsdr, jaccobsz, jaces, jachops, 
jacis, jackes, jackobes, jackobhs, jackobs, jackops, jacob, jacobdr, jacobes, 
jacobesz, jacobi, jacobij, jacobis, jacobo, jacobpsz, jacobs, jacobsd, 
jacobsdr, jacobse, jacobsen, jacobsens, jacobss, jacobsz, jacobszen, jacobszn, 
jacobszoon, jacobus, jacobussen, jacobusz, jacoby, jacobz, jacobzn, jacochs, 
jacoobes, jacoobs, jacopdr, jacops, jacopsdr, jacopsz, jacopszn, jacos, 
jacques, jac.s, jacubs, jacus, jaeckes, jaeckesdr, jaeckobs, jaeckops, jaecobs, 
jaecobsz, jaekes, jaekobs, jaeques, jakes, jakis, jakkobs, jakkops, jakob, 
jakobes, jakobessen, jakobij, jakobis, jakobjes, jakobs, jakobsdr, jakobse, 
jakobsen, jakobus, jakoby, jakobz, jakoobs, jakoops, jakop, jakops, jakques, 
jaks, jakus, james, jaobs, japeks, japicks, japicksdr, japics, japicx, japiks, 
japikx, japix, jappedr, jappes, jappesdr, jappesz, jappeszn, jappezn, jappiks, 
jappis, jaques, jaquesdr, jaquis, jaquisdr, jaquusdr, jcobs, jeppicx, jeppiks, 
kobbis, kobes, kobijs, kobis, kobises, kobus, kobuses, kobys, koobes, koobis, 
koobus, yacobs, yapicks => JAKOBS
{noformat}

  was:
We have a field with SynonymFilterFactory for dutch synonyms. Both on index and 
on query. The word "jacob" and other spellings of "jacob" are presented in 3 
very long list of synonyms.

We have the word "jacobus" there.

Search for "jac*", "jacob*" and etc. does not work. It does work for other 
words. And it does work if the synonyms are not used. Or if the synonyms are 
only used on query time.

The two lists of synonyms which somehow brake it are:
{noformat}
cobes, cobis, cobus, coobes, iakobus, iakop, ijacob, ijacobis, ijacobus, 
ijapick, jaacke, jaacob, jaaipik, jaakes, jaakob, jaakoob, jaap, jaapik, jabec, 
jac., jaccob, jaces, jachop, jacke, jackes, jackob, jackop, jacob, jacobes, 
jacobis, jacobp, jacobs, jacobus, jacoch, jacoob, jacop, jacq, jacque, jacques, 
jacquis, jacub, jacus, jaecke, jaeckob, jaecob, jaecques, jaeke, jaekes, 
jaekob, jaep, jak, jak., jake, jakis, jakke, jakkob, jakkop, jakob, jakobes, 
jakobi, jakobis, jakobje, jakobus, jakoob, jakoobes, jakop, jakques, jakus, 
james, japek, japick, japijck, japijk, japik, japje, jappe, jappik, japyck, 
japyk, jaques, jaquez, jaquis, jeems, jeppik, kobbis, kobes, kobis, kobise, 
kobus, kobuse, koobes, koobis, koobus, koos, yacob, yacobis, yacobus, yapick => 
JAKOB

cobes, cobis, cobus, coobes, coobus, iakobus, iakops, ijacobs, ijapicks, 
jaabse, jaackis, jaacobs, jaakes, jaakobs, jaakoobs, jaapiks, jaaps, jabex, 
jabics, jabiks, jac., jacacobs, jaccobs, jaccobsdr, jaccobsz, jaces, jachops, 
jacis, jackes, jackobes, jackobhs, jackobs, jackops, jacob, jacobdr, jacobes, 
jacobesz, jacobi, jacobij, jacobis, jacobo, jacobpsz, jacobs, jacobsd, 
jacobsdr, jacobse, jacobsen, jacobsens, jacobss, jacobsz, jacobszen, jacobszn, 
jacobszoon, jacobus, jacobussen, jacobusz, jacoby, jacobz, jacobzn, jacochs, 
jacoobes, jacoobs, jacopdr, jacops, jacopsdr, jacopsz, jacopszn, jacos, 
jacques, jac.s, jacubs, jacus, jaeckes, jaeckesdr, jaeckobs, jaeckops, jaecobs, 
jaecobsz, jaekes, jaekobs, jaeques, jakes, jakis, jakkobs, jakkops, jakob, 
jakobes, jakobessen, jakobij, jakobis, jakobjes, jakobs, jakobsdr, jakobse, 
jakobsen, jakobus, jakoby, jakobz, jakoobs, jakoops, jakop, jakops, jakques, 
jaks, jakus, james, jaobs, japeks, japicks, 

[jira] [Created] (SOLR-10221) Search for "jac*" or "jacob*" does not work for "jacobus" when it is part of long lists of synonyms

[Alexandar Mitsev (JIRA)]

Alexandar Mitsev created SOLR-10221:
---

 Summary: Search for "jac*" or "jacob*" does not work for "jacobus" 
when it is part of long lists of synonyms
 Key: SOLR-10221
 URL: https://issues.apache.org/jira/browse/SOLR-10221
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2, 4.10.4
Reporter: Alexandar Mitsev


We have a field with SynonymFilterFactory for dutch synonyms. Both on index and 
on query. The word "jacob" and other spellings of "jacob" are presented in 3 
very long list of synonyms.

We have the word "jacobus" there.

Search for "jac*", "jacob*" and etc. does not work. It does work for other 
words. And it does work if the synonyms are not used. Or if the synonyms are 
only used on query time.

The two lists of synonyms which somehow brake it are:
{noformat}
cobes, cobis, cobus, coobes, iakobus, iakop, ijacob, ijacobis, ijacobus, 
ijapick, jaacke, jaacob, jaaipik, jaakes, jaakob, jaakoob, jaap, jaapik, jabec, 
jac., jaccob, jaces, jachop, jacke, jackes, jackob, jackop, jacob, jacobes, 
jacobis, jacobp, jacobs, jacobus, jacoch, jacoob, jacop, jacq, jacque, jacques, 
jacquis, jacub, jacus, jaecke, jaeckob, jaecob, jaecques, jaeke, jaekes, 
jaekob, jaep, jak, jak., jake, jakis, jakke, jakkob, jakkop, jakob, jakobes, 
jakobi, jakobis, jakobje, jakobus, jakoob, jakoobes, jakop, jakques, jakus, 
james, japek, japick, japijck, japijk, japik, japje, jappe, jappik, japyck, 
japyk, jaques, jaquez, jaquis, jeems, jeppik, kobbis, kobes, kobis, kobise, 
kobus, kobuse, koobes, koobis, koobus, koos, yacob, yacobis, yacobus, yapick => 
JAKOB

cobes, cobis, cobus, coobes, coobus, iakobus, iakops, ijacobs, ijapicks, 
jaabse, jaackis, jaacobs, jaakes, jaakobs, jaakoobs, jaapiks, jaaps, jabex, 
jabics, jabiks, jac., jacacobs, jaccobs, jaccobsdr, jaccobsz, jaces, jachops, 
jacis, jackes, jackobes, jackobhs, jackobs, jackops, jacob, jacobdr, jacobes, 
jacobesz, jacobi, jacobij, jacobis, jacobo, jacobpsz, jacobs, jacobsd, 
jacobsdr, jacobse, jacobsen, jacobsens, jacobss, jacobsz, jacobszen, jacobszn, 
jacobszoon, jacobus, jacobussen, jacobusz, jacoby, jacobz, jacobzn, jacochs, 
jacoobes, jacoobs, jacopdr, jacops, jacopsdr, jacopsz, jacopszn, jacos, 
jacques, jac.s, jacubs, jacus, jaeckes, jaeckesdr, jaeckobs, jaeckops, jaecobs, 
jaecobsz, jaekes, jaekobs, jaeques, jakes, jakis, jakkobs, jakkops, jakob, 
jakobes, jakobessen, jakobij, jakobis, jakobjes, jakobs, jakobsdr, jakobse, 
jakobsen, jakobus, jakoby, jakobz, jakoobs, jakoops, jakop, jakops, jakques, 
jaks, jakus, james, jaobs, japeks, japicks, japicksdr, japics, japicx, japiks, 
japikx, japix, jappedr, jappes, jappesdr, jappesz, jappeszn, jappezn, jappiks, 
jappis, jaques, jaquesdr, jaquis, jaquisdr, jaquusdr, jcobs, jeppicx, jeppiks, 
kobbis, kobes, kobijs, kobis, kobises, kobus, kobuses, kobys, koobes, koobis, 
koobus, yacobs, yapicks => JAKOBS
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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