Re: Solr 8.1 issue with collection aliases

[Ishan Chattopadhyaya]

Absolutely. This is a critical feature.
Andrzej, would you have time to do a 8.1.1 release? We also need to
coordinate with Jan, since he's doing a 7.7.2 release right now.

On Thu, May 16, 2019 at 5:18 PM Jörn Franke  wrote:
>
> For the specific client the Solr 8.1 is not usable with this bug.
>
> Collection aliases are also a crucial feature for doing “zero-downtime” 
> reindexing or changing the Schema of a collection or for switching back to an 
> old Index if the new Index structure has bugs etc.
>
> However  I also understand that there are other considerations by other 
> people.
>
> > Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
> > :
> >
> > Does this warrant a 8.1.1 release? I think this is serious enough.
> >
> >> On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
> >>
> >> SOLR-13475
> >>
> >>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> >>> :
> >>>
> >>> Please open a JIRA.
> >>>
>  On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>  Sorry autocorrection. It is not only a admin UI issue. I described in my 
>  previous email that access through the collection alias does not work. I 
>  cannot even do execute the select query handler if I use the collection 
>  alias instead of the collection name.
>  So it is maybe more problematic.
> 
> > Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> >
> > Note only an admin UI issue. Access collections via their alias does 
> > not work.
> >
> >> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
> >>
> >> It seems creating alias in Solr Admin UI is broken. It's a minor issue 
> >> for 8.1.0
> >> I've alias via REST call 
> >> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
> >>   successfully.
> >> Jörn, thanks for reporting.
> >>
> >>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> >>> wrote:
> >>> Hi,
> >>>
> >>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> >>> with
> >>> collection aliases, but I am not 100% sure it is due to the upgrade.
> >>>
> >>> Situation:
> >>> I have a collection called c_testcollection.
> >>> I have an alias called testcollection.
> >>> Alias "testcollection" points to "c_testcollection".
> >>> On Solr 8.0 no issue
> >>>
> >>> After upgrade to Solr 8.1:
> >>> When I do a query on c_testcollection then there is no issue:
> >>> http://localhost:8983/solr/c_testcollection/select?q=test
> >>> When I do a query on testcollection then I receive the stacktrace 
> >>> below
> >>> http://localhost:8983/solr/testcollection/select?q=test
> >>>
> >>> Additionally I observe a strange behavior in the admin ui. When I try 
> >>> to
> >>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> >>> creates two aliases:
> >>> new => c_new
> >>> c_new => c_new
> >>> if i then do a query on the alias new it works without issues. If I 
> >>> remove
> >>> the alias from c_new to c_new then I get the same error. Is this 
> >>> desired
> >>> behaviour?
> >>> It is rather annoying to have unnecessary aliases, because I need to 
> >>> filter
> >>> them out in my application when retrieving all aliases.
> >>> Is there a related issue.
> >>>
> >>> Here the stacktrace:
> >>> {
> >>>  "error":{
> >>>"trace":"java.lang.NullPointerException\n\tat
> >>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> >>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> >>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> >>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> >>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> >>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> >>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> >>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> >>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> >>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> >>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> >>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> >>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> >>> 

Re: Solr 8.1 issue with collection aliases

[Jörn Franke]

For the specific client the Solr 8.1 is not usable with this bug.

Collection aliases are also a crucial feature for doing “zero-downtime” 
reindexing or changing the Schema of a collection or for switching back to an 
old Index if the new Index structure has bugs etc.

However  I also understand that there are other considerations by other people.

> Am 16.05.2019 um 11:55 schrieb Ishan Chattopadhyaya 
> :
> 
> Does this warrant a 8.1.1 release? I think this is serious enough.
> 
>> On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
>> 
>> SOLR-13475
>> 
>>> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
>>> :
>>> 
>>> Please open a JIRA.
>>> 
 On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
 Sorry autocorrection. It is not only a admin UI issue. I described in my 
 previous email that access through the collection alias does not work. I 
 cannot even do execute the select query handler if I use the collection 
 alias instead of the collection name.
 So it is maybe more problematic.
 
> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> 
> Note only an admin UI issue. Access collections via their alias does not 
> work.
> 
>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
>> 
>> It seems creating alias in Solr Admin UI is broken. It's a minor issue 
>> for 8.1.0
>> I've alias via REST call 
>> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
>>   successfully.
>> Jörn, thanks for reporting.
>> 
>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
>>> wrote:
>>> Hi,
>>> 
>>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
>>> with
>>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>> 
>>> Situation:
>>> I have a collection called c_testcollection.
>>> I have an alias called testcollection.
>>> Alias "testcollection" points to "c_testcollection".
>>> On Solr 8.0 no issue
>>> 
>>> After upgrade to Solr 8.1:
>>> When I do a query on c_testcollection then there is no issue:
>>> http://localhost:8983/solr/c_testcollection/select?q=test
>>> When I do a query on testcollection then I receive the stacktrace below
>>> http://localhost:8983/solr/testcollection/select?q=test
>>> 
>>> Additionally I observe a strange behavior in the admin ui. When I try to
>>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>>> creates two aliases:
>>> new => c_new
>>> c_new => c_new
>>> if i then do a query on the alias new it works without issues. If I 
>>> remove
>>> the alias from c_new to c_new then I get the same error. Is this desired
>>> behaviour?
>>> It is rather annoying to have unnecessary aliases, because I need to 
>>> filter
>>> them out in my application when retrieving all aliases.
>>> Is there a related issue.
>>> 
>>> Here the stacktrace:
>>> {
>>>  "error":{
>>>"trace":"java.lang.NullPointerException\n\tat
>>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>>> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>>> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>>> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>>> 

[JENKINS-EA] Lucene-Solr-8.x-Linux (64bit/jdk-13-ea+18) - Build # 567 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/567/
Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Error from server at http://127.0.0.1:39513/w/collection1: non ok status: 500, 
message:Server Error

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:39513/w/collection1: non ok status: 500, 
message:Server Error
at 
__randomizedtesting.SeedInfo.seed([A39AC5116508766:826D938BB8ACEA9E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:579)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:224)
at 
org.apache.solr.BaseDistributedSearchTestCase.add(BaseDistributedSearchTestCase.java:576)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.indexDocAndRandomlyCommit(NestedShardedAtomicUpdateTest.java:221)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.sendWrongRouteParam(NestedShardedAtomicUpdateTest.java:191)
at 
org.apache.solr.cloud.NestedShardedAtomicUpdateTest.test(NestedShardedAtomicUpdateTest.java:55)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[jira] [Commented] (LUCENE-8326) More Like This Params Refactor

[Alessandro Benedetti (JIRA)]

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

Alessandro Benedetti commented on LUCENE-8326:
--

Anyone interested in helping me in refactoring and improving the MLT step by 
step?
This is the first step, in the perspective of cleaning the code and make it 
more maintainable and extendable.
Happy to help and to support the changes necessary.

> More Like This Params Refactor
> --
>
> Key: LUCENE-8326
> URL: https://issues.apache.org/jira/browse/LUCENE-8326
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/query/scoring
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8326.patch, LUCENE-8326.patch, LUCENE-8326.patch, 
> LUCENE-8326.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> More Like This ca be refactored to improve the code readability, test 
> coverage and maintenance.
> Scope of this Jira issue is to start the More Like This refactor from the 
> More Like This Params.
> This Jira will not improve the current More Like This but just keep the same 
> functionality with a refactored code.
> Other Jira issues will follow improving the overall code readability, test 
> coverage and maintenance.



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

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

[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk-11.0.2) - Build # 136 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/136/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 58908 lines...]
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:634: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:507: The following 
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/build.xml:494: Source checkout 
is dirty (unversioned/missing files) after running tests!!! Offending files:
* solr/licenses/noggit-0.8.jar.sha1

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

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

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, 
SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-493022833
 
 
   Pushed again, hope it is enough. Waiting for your suggestions... 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-7.7 - Build # 11 - Still Failing

[Ishan Chattopadhyaya]

I ran generating of backward compatability step for 7.7.0, but it
didn't build anything (as the indexes were already there).

On Thu, May 16, 2019 at 3:59 PM Jan Høydahl  wrote:
>
> Also it appears that Jenkins is building and smoketesting 7.7.1, not 7.7.2, 
> even if 7.7.2 is the version number on branch_7_7
> Could it be that the Jenkins job has some cache and re-using a 7.7.1 release 
> from a point before 7.7.0 back-compat indices were added?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 16. mai 2019 kl. 12:07 skrev Ishan Chattopadhyaya :
>
> Maybe 7.7.0's post release step (generate backward indexes) was not followed?
> I can try to generate them and see if that fixes this.
>
> On Thu, May 16, 2019 at 3:27 PM Jan Høydahl  wrote:
>
>
> There seems to be a problem with backwards compat testing on 7.7 branch:
>
>  [smoker] Verify...
>  [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
> -Dtests.slow=false'...
>  [smoker] test demo with 9...
>  [smoker]   got 229 hits for query "lucene"
>  [smoker] checkindex with 9...
>  [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>  [smoker] find all past Lucene releases...
>  [smoker] run TestBackwardsCompatibility..
>  [smoker] Releases that don't seem to be tested:
>  [smoker]   7.7.0
>
>
> I see the same failures in the last 7.7 Jenkins runs February 14. When I run:
>
>  ant test -Dtestcase=TestBackwardsCompatibility -Dtests.verbose=true | grep 
> -E "TEST: index[\s*=\s*](.*?)(-cfs|-nocfs)$"
>
> then 7.7.0 is indeed included in the output.
>
> What to do about it?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 14. feb. 2019 kl. 21:53 skrev Apache Jenkins Server 
> :
>
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/11/
>
> No tests ran.
>
> Build Log:
> [...truncated 23461 lines...]
> [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
> invalid part, must have at least one section (e.g., chapter, appendix, etc.)
> [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
> part, must have at least one section (e.g., chapter, appendix, etc.)
>[java] Processed 2460 links (2011 relative) to 3224 anchors in 246 files
>[echo] Validated Links & Anchors via: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/
>
> -dist-changes:
>[copy] Copying 4 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/changes
>
> package:
>
> -unpack-solr-tgz:
>
> -ensure-solr-tgz-exists:
>   [mkdir] Created dir: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
>   [untar] Expanding: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.1.tgz
>  into 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
>
> generate-maven-artifacts:
>
> resolve:
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
>
> resolve:
>
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
>
> -ivy-fail-disallowed-ivy-version:
>
> ivy-fail:
>
> 

[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


Commit b11f3a8a0ff8400b2d8b2ec58ac9587dfb2e21e1 in lucene-solr's branch 
refs/heads/branch_8x from Cassandra Targett
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b11f3a8 ]

SOLR-13468: fix ref guide build failures


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



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

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

[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13468:


Commit c726ada1d99fcc4b15cb9f4877aad34d30a2d56e in lucene-solr's branch 
refs/heads/master from Cassandra Targett
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c726ada ]

SOLR-13468: fix ref guide build failures


> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



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

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

[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13468:
--

Actually, the v1 & v2 examples added here don't make any sense. There is no 
"old way" of doing the Autoscaling API requests (i.e., as HTTP request 
parameters). We should only add that when there is a difference in syntax, not 
when the examples are exactly the same. I'm going to distill that into a single 
example, and fix several typos in the text also.

The other errors are from a badly formatted {{[source]}} block, they'll go away 
with the change I'm making above.

> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



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

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

[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13468:
--

[~noble.paul], the Ref Guide commits here broke the Ref Guide builds. It looks 
like you introduced duplicate anchor IDs in the HTML output, and also used 
references that don't exist:

{noformat}
 [java] ID occurs multiple times: v1getcomponent
 [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/config-api.html
 [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-api.html
 [java] ID occurs multiple times: v2getcomponent
 [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/config-api.html
 [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-api.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#write-api
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#create-update-trigger
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#remove-trigger
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-triggers.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#create-and-modify-cluster-preferences
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-policy-preferences.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#create-and-modify-collection-specific-policy
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solrcloud-autoscaling-policy-preferences.html
 [java] Relative link points at id that doesn't exist in dest: 
solrcloud-autoscaling-api.html#change-autoscaling-properties
 [java]  ... source: 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/solr-upgrade-notes.html
 [java] Processed 2511 links (1822 relative) to 3348 anchors in 253 files
 [java] Total of 8 problems found
{noformat}

(from https://builds.apache.org/job/Solr-reference-guide-master/15910/)

> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling 
> configuration sent as a payload . This is helpful in debugging the system or 
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json'  -d '{
> "cluster-policy": [
>   {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
>   ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}



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

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

[GitHub] [lucene-solr] janhoy commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

janhoy commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-493008910
 
 
   Yes, please do only feature related changes in the PR, then you can file 
another JIRA for other formatting changes if needed. I too keep fighting with 
the IDE that wants to auto-format things. But it only creates unnecessary noise 
for reviewers :-(


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: [JENKINS] Lucene-Solr-SmokeRelease-7.7 - Build # 11 - Still Failing

[Ishan Chattopadhyaya]

Maybe 7.7.0's post release step (generate backward indexes) was not followed?
I can try to generate them and see if that fixes this.

On Thu, May 16, 2019 at 3:27 PM Jan Høydahl  wrote:
>
> There seems to be a problem with backwards compat testing on 7.7 branch:
>
> >   [smoker] Verify...
> >   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
> > -Dtests.slow=false'...
> >   [smoker] test demo with 9...
> >   [smoker]   got 229 hits for query "lucene"
> >   [smoker] checkindex with 9...
> >   [smoker]   confirm all releases have coverage in 
> > TestBackwardsCompatibility
> >   [smoker] find all past Lucene releases...
> >   [smoker] run TestBackwardsCompatibility..
> >   [smoker] Releases that don't seem to be tested:
> >   [smoker]   7.7.0
>
> I see the same failures in the last 7.7 Jenkins runs February 14. When I run:
>
>   ant test -Dtestcase=TestBackwardsCompatibility -Dtests.verbose=true | grep 
> -E "TEST: index[\s*=\s*](.*?)(-cfs|-nocfs)$"
>
> then 7.7.0 is indeed included in the output.
>
> What to do about it?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 14. feb. 2019 kl. 21:53 skrev Apache Jenkins Server 
> > :
> >
> > Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/11/
> >
> > No tests ran.
> >
> > Build Log:
> > [...truncated 23461 lines...]
> > [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
> > invalid part, must have at least one section (e.g., chapter, appendix, etc.)
> > [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: 
> > invalid part, must have at least one section (e.g., chapter, appendix, etc.)
> > [java] Processed 2460 links (2011 relative) to 3224 anchors in 246 files
> > [echo] Validated Links & Anchors via: 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/
> >
> > -dist-changes:
> > [copy] Copying 4 files to 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/changes
> >
> > package:
> >
> > -unpack-solr-tgz:
> >
> > -ensure-solr-tgz-exists:
> >[mkdir] Created dir: 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
> >[untar] Expanding: 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.1.tgz
> >  into 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
> >
> > generate-maven-artifacts:
> >
> > resolve:
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > -ivy-fail-disallowed-ivy-version:
> >
> > ivy-fail:
> >
> > ivy-configure:
> > [ivy:configure] :: loading settings :: file = 
> > /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> >
> > resolve:
> >
> > ivy-availability-check:
> > [loadresource] Do not set property disallowed.ivy.jars.list as its length 
> > is 0.
> >
> > 

[JENKINS] Lucene-Solr-Tests-7.7 - Build # 18 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.7/18/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ObjectTracker found 5 object(s) that were not released!!! [InternalHttpClient, 
MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper, SolrCore] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.http.impl.client.InternalHttpClient  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:321)
  at 
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:330)
  at 
org.apache.solr.handler.IndexFetcher.createHttpClient(IndexFetcher.java:225)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:267)  at 
org.apache.solr.handler.ReplicationHandler.inform(ReplicationHandler.java:1202) 
 at org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:696) 
 at org.apache.solr.core.SolrCore.(SolrCore.java:1000)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:699)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.core.SolrCore.getNewIndexDir(SolrCore.java:359)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:738)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:967)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:699)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at 
org.apache.solr.core.SolrCore.initSnapshotMetaDataManager(SolrCore.java:508)  
at org.apache.solr.core.SolrCore.(SolrCore.java:959)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:699)  
at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
 at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
 at java.lang.Thread.run(Thread.java:748)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.lucene.store.MockDirectoryWrapper  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at 
org.apache.solr.core.CachingDirectoryFactory.get(CachingDirectoryFactory.java:348)
  at org.apache.solr.update.SolrIndexWriter.create(SolrIndexWriter.java:95)  at 
org.apache.solr.core.SolrCore.initIndex(SolrCore.java:770)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:967)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:874)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1187)
  at org.apache.solr.core.CoreContainer.lambda$load$13(CoreContainer.java:699)  
at 

[JENKINS] Solr-reference-guide-master - Build # 15912 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15912/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 04b61e3dee440a390ab20a4c65bbdc9523742a45 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 04b61e3dee440a390ab20a4c65bbdc9523742a45
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk 04b61e3dee440a390ab20a4c65bbdc9523742a45 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins1847654282648456971.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 24088 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24088/
Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

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

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

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

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

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

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

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

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

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

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

[...truncated 3 lines...]
   [junit4] JVM J1: stderr was not empty, see: 

Re: [JENKINS] Lucene-Solr-SmokeRelease-7.7 - Build # 11 - Still Failing

[Jan Høydahl]

There seems to be a problem with backwards compat testing on 7.7 branch:

>   [smoker] Verify...
>   [smoker] run tests w/ Java 9 and testArgs='-Dtests.badapples=false 
> -Dtests.slow=false'...
>   [smoker] test demo with 9...
>   [smoker]   got 229 hits for query "lucene"
>   [smoker] checkindex with 9...
>   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
>   [smoker] find all past Lucene releases...
>   [smoker] run TestBackwardsCompatibility..
>   [smoker] Releases that don't seem to be tested:
>   [smoker]   7.7.0

I see the same failures in the last 7.7 Jenkins runs February 14. When I run:

  ant test -Dtestcase=TestBackwardsCompatibility -Dtests.verbose=true | grep -E 
"TEST: index[\s*=\s*](.*?)(-cfs|-nocfs)$"

then 7.7.0 is indeed included in the output.

What to do about it?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 14. feb. 2019 kl. 21:53 skrev Apache Jenkins Server 
> :
> 
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/11/
> 
> No tests ran.
> 
> Build Log:
> [...truncated 23461 lines...]
> [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: 
> invalid part, must have at least one section (e.g., chapter, appendix, etc.)
> [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid 
> part, must have at least one section (e.g., chapter, appendix, etc.)
> [java] Processed 2460 links (2011 relative) to 3224 anchors in 246 files
> [echo] Validated Links & Anchors via: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/
> 
> -dist-changes:
> [copy] Copying 4 files to 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/changes
> 
> package:
> 
> -unpack-solr-tgz:
> 
> -ensure-solr-tgz-exists:
>[mkdir] Created dir: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
>[untar] Expanding: 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.1.tgz
>  into 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked
> 
> generate-maven-artifacts:
> 
> resolve:
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml
> 
> resolve:
> 
> ivy-availability-check:
> [loadresource] Do not set property disallowed.ivy.jars.list as its length is 
> 0.
> 
> -ivy-fail-disallowed-ivy-version:
> 
> ivy-fail:
> 
> ivy-configure:
> [ivy:configure] :: loading settings :: file = 
> 

Re: Solr 8.1 issue with collection aliases

[Ishan Chattopadhyaya]

Does this warrant a 8.1.1 release? I think this is serious enough.

On Thu, May 16, 2019 at 12:03 PM Jörn Franke  wrote:
>
> SOLR-13475
>
> > Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> > :
> >
> > Please open a JIRA.
> >
> >> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
> >> Sorry autocorrection. It is not only a admin UI issue. I described in my 
> >> previous email that access through the collection alias does not work. I 
> >> cannot even do execute the select query handler if I use the collection 
> >> alias instead of the collection name.
> >> So it is maybe more problematic.
> >>
> >>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
> >>>
> >>> Note only an admin UI issue. Access collections via their alias does not 
> >>> work.
> >>>
>  Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
> 
>  It seems creating alias in Solr Admin UI is broken. It's a minor issue 
>  for 8.1.0
>  I've alias via REST call 
>  http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
>    successfully.
>  Jörn, thanks for reporting.
> 
> > On Tue, May 14, 2019 at 11:03 PM Jörn Franke  
> > wrote:
> > Hi,
> >
> > I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue 
> > with
> > collection aliases, but I am not 100% sure it is due to the upgrade.
> >
> > Situation:
> > I have a collection called c_testcollection.
> > I have an alias called testcollection.
> > Alias "testcollection" points to "c_testcollection".
> > On Solr 8.0 no issue
> >
> > After upgrade to Solr 8.1:
> > When I do a query on c_testcollection then there is no issue:
> > http://localhost:8983/solr/c_testcollection/select?q=test
> > When I do a query on testcollection then I receive the stacktrace below
> > http://localhost:8983/solr/testcollection/select?q=test
> >
> > Additionally I observe a strange behavior in the admin ui. When I try to
> > create an alias (e.g. new) for a new collection (e.g. c_new) then it
> > creates two aliases:
> > new => c_new
> > c_new => c_new
> > if i then do a query on the alias new it works without issues. If I 
> > remove
> > the alias from c_new to c_new then I get the same error. Is this desired
> > behaviour?
> > It is rather annoying to have unnecessary aliases, because I need to 
> > filter
> > them out in my application when retrieving all aliases.
> > Is there a related issue.
> >
> > Here the stacktrace:
> > {
> >   "error":{
> > "trace":"java.lang.NullPointerException\n\tat
> > java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> > org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> > org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> > org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
> > 

[JENKINS] Lucene-Solr-Tests-master - Build # 3341 - Failure

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 62063 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1293522341
 [ecj-lint] Compiling 1273 source files to /tmp/ecj1293522341
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
 (at line 74)
 [ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
 [ecj-lint]   ^^
 [ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
 (at line 215)
 [ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'leafReader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
 (at line 142)
 [ecj-lint] return new JavaBinCodec(null, 
stringCache).setReadStringAsCharSeq(true);
 [ecj-lint]^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
 (at line 137)
 [ecj-lint] new JavaBinCodec() {
 [ecj-lint]   SolrParams params;
 [ecj-lint]   AddUpdateCommand addCmd = null;
 [ecj-lint] 
 [ecj-lint]   @Override
 [ecj-lint]   public List readIterator(DataInputInputStream fis) 
throws IOException {
 [ecj-lint] while (true) {
 [ecj-lint]   Object o = readVal(fis);
 [ecj-lint]   if (o == END_OBJ) break;
 [ecj-lint]   if (o instanceof NamedList) {
 [ecj-lint] params = ((NamedList) o).toSolrParams();
 [ecj-lint]   } else {
 [ecj-lint] try {
 [ecj-lint]   if (o instanceof byte[]) {
 [ecj-lint] if (params != null) req.setParams(params);
 [ecj-lint] byte[] buf = (byte[]) o;
 [ecj-lint] contentStreamLoader.load(req, rsp, new 
ContentStreamBase.ByteArrayStream(buf, null), processor);
 [ecj-lint]   } else {
 [ecj-lint] throw new RuntimeException("unsupported type ");
 [ecj-lint]   }
 [ecj-lint] } catch (Exception e) {
 [ecj-lint]   throw new RuntimeException(e);
 [ecj-lint] } finally {
 [ecj-lint]   params = null;
 [ecj-lint]   req.setParams(old);
 [ecj-lint] }
 [ecj-lint]   }
 [ecj-lint] }
 [ecj-lint] return Collections.emptyList();
 [ecj-lint]   }
 [ecj-lint] 
 [ecj-lint] 

[JENKINS] Solr-reference-guide-8.x - Build # 2984 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2984/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins2468556209319905823.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[jira] [Commented] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13475:
--

I can reproduce this using {{bin/solr start -e cloud}} example. There's a bug 
in the conditionals in {{Aliases.resolveAliasesGivenAliasMap:251}}.

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  

[jira] [Comment Edited] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-13475 at 5/16/19 9:43 AM:
--

I wasn't able to reproduce the NPE with simple efforts:
{code}
$ bin/solr -c
$ curl 
"http://localhost:8983/solr/admin/collections?action=CREATE=1=abc;
$  curl 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=myalias=abc;
$  curl "http://localhost:8983/solr/abc/select?q=*:*;
$  curl "http://localhost:8983/solr/myalias/select?q=*:*;
{code}

However,
{code}
$ curl "http://localhost:8983/solr/admin/collections?action=LISTALIASES;
{
  "responseHeader":{
"status":0,
"QTime":7},
  "aliases":{
"abc":"abc",
"myalias":"abc"},
  "properties":{}}
{code}

abc => abc seems new and as per the report.


was (Author: ichattopadhyaya):
I wasn't able to reproduce with simple efforts:
{code}
$ bin/solr -c
$ curl 
"http://localhost:8983/solr/admin/collections?action=CREATE=1=abc;
$  curl 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=myalias=abc;
$  curl "http://localhost:8983/solr/abc/select?q=*:*;
$  curl "http://localhost:8983/solr/myalias/select?q=*:*;
{code}

{code}
$ curl "http://localhost:8983/solr/admin/collections?action=LISTALIASES;
{
  "responseHeader":{
"status":0,
"QTime":7},
  "aliases":{
"abc":"abc",
"myalias":"abc"},
  "properties":{}}
{code}

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> 

[jira] [Comment Edited] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya edited comment on SOLR-13475 at 5/16/19 9:42 AM:
--

I wasn't able to reproduce with simple efforts:
{code}
$ bin/solr -c
$ curl 
"http://localhost:8983/solr/admin/collections?action=CREATE=1=abc;
$  curl 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=myalias=abc;
$  curl "http://localhost:8983/solr/abc/select?q=*:*;
$  curl "http://localhost:8983/solr/myalias/select?q=*:*;
{code}

{code}
$ curl "http://localhost:8983/solr/admin/collections?action=LISTALIASES;
{
  "responseHeader":{
"status":0,
"QTime":7},
  "aliases":{
"abc":"abc",
"myalias":"abc"},
  "properties":{}}
{code}


was (Author: ichattopadhyaya):
I wasn't able to reproduce with simple efforts:
{code}
$ bin/solr -c
$ curl 
"http://localhost:8983/solr/admin/collections?action=CREATE=1=abc;
$  curl 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=myalias=abc;
$  curl "http://localhost:8983/solr/abc/select?q=*:*;
$  curl "http://localhost:8983/solr/myalias/select?q=*:*;
{code}

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> 

[jira] [Commented] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13475:
-

I wasn't able to reproduce with simple efforts:
{code}
$ bin/solr -c
$ curl 
"http://localhost:8983/solr/admin/collections?action=CREATE=1=abc;
$  curl 
"http://localhost:8983/solr/admin/collections?action=CREATEALIAS=myalias=abc;
$  curl "http://localhost:8983/solr/abc/select?q=*:*;
$  curl "http://localhost:8983/solr/myalias/select?q=*:*;
{code}

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> 

[jira] [Commented] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13475:
--

This is likely related to changes in SOLR-13262, I'll provide a fix shortly.

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
> 

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.2) - Build # 5149 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5149/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 62018 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj449363869
 [ecj-lint] Compiling 1273 source files to 
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj449363869
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
 (at line 74)
 [ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
 [ecj-lint]   ^^
 [ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
 (at line 215)
 [ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'leafReader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
 (at line 142)
 [ecj-lint] return new JavaBinCodec(null, 
stringCache).setReadStringAsCharSeq(true);
 [ecj-lint]^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
 (at line 137)
 [ecj-lint] new JavaBinCodec() {
 [ecj-lint]   SolrParams params;
 [ecj-lint]   AddUpdateCommand addCmd = null;
 [ecj-lint] 
 [ecj-lint]   @Override
 [ecj-lint]   public List readIterator(DataInputInputStream fis) 
throws IOException {
 [ecj-lint] while (true) {
 [ecj-lint]   Object o = readVal(fis);
 [ecj-lint]   if (o == END_OBJ) break;
 [ecj-lint]   if (o instanceof NamedList) {
 [ecj-lint] params = ((NamedList) o).toSolrParams();
 [ecj-lint]   } else {
 [ecj-lint] try {
 [ecj-lint]   if (o instanceof byte[]) {
 [ecj-lint] if (params != null) req.setParams(params);
 [ecj-lint] byte[] buf = (byte[]) o;
 [ecj-lint] contentStreamLoader.load(req, rsp, new 
ContentStreamBase.ByteArrayStream(buf, null), processor);
 [ecj-lint]   } else {
 [ecj-lint] throw new RuntimeException("unsupported type ");
 [ecj-lint]   }
 [ecj-lint] } catch (Exception e) {
 [ecj-lint]   throw new RuntimeException(e);
 [ecj-lint] } finally {
 [ecj-lint]   params = null;
 [ecj-lint]   req.setParams(old);
 [ecj-lint] }
 [ecj-lint]   }
 [ecj-lint] }
 [ecj-lint] 

[jira] [Updated] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13475:
-
Fix Version/s: master (9.0)

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat 
> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat 
> 

[jira] [Updated] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13475:
-
Fix Version/s: 8.2

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.2
>
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat 
> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat 
> 

[jira] [Assigned] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  reassigned SOLR-13475:


Assignee: Andrzej Bialecki 

> Nullpointer-Exception when querying collection through collection alias
> ---
>
> Key: SOLR-13475
> URL: https://issues.apache.org/jira/browse/SOLR-13475
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 8.1
>Reporter: Jörn Franke
>Assignee: Andrzej Bialecki 
>Priority: Major
>
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
> collection aliases, but I am not 100% sure it is due to the upgrade.
>  
> Situation:
> I have a collection called c_testcollection. 
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue to query the collection through its alias 
> "testcollection", e.g 
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> [http://localhost:8983/solr/c_testcollection/select?q=test]
> When I do a query on testcollection then I receive the stacktrace below
> [http://localhost:8983/solr/testcollection/select?q=test]
>  
> Additionally I observe a strange behavior in the admin ui. When I try to 
> create an alias (e.g. new) for a new collection (e.g. c_new) then it creates 
> two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove 
> the alias from c_new to c_new then I get the same error. Is this desired 
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to filter 
> them out in my application when retrieving all aliases.
> Is there a related issue.
>  
> Here the stacktrace:
> {
>   "error":{
>     "trace":"java.lang.NullPointerException\n\tat 
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>  
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>  org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>  org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>  
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>  
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>  
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>  
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>  
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>  
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>  
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>  org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat 
> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat 
> 

[JENKINS] Solr-reference-guide-8.0 - Build # 10 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.0/10/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.0
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8_0^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8_0^{commit} # timeout=10
Checking out Revision b5a872d3fd55a67be16a9fc30671b29be0ece013 
(refs/remotes/origin/branch_8_0)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f b5a872d3fd55a67be16a9fc30671b29be0ece013
Commit message: "SOLR-13425: Wrong color in horizontal definition list (#653)"
 > git rev-list --no-walk b5a872d3fd55a67be16a9fc30671b29be0ece013 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.0] $ /bin/bash -xe /tmp/jenkins1200294427301285593.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: can't open signed data `/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
gpg: can't hash datafile: file open error
GPG signature verification failed for 
'/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz' - 
'https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc'! Try to 
install GPG v2 and then fetch the public key:

gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 
409B6B1796C275462A1703113804BB82D39DC0E3 
7D2BAF1CF37B13E2069D6956105BD0E739499BDB

or if it fails:

command curl -sSL https://rvm.io/mpapis.asc | gpg --import -
command curl -sSL https://rvm.io/pkuczynski.asc | gpg --import -

In case of further problems with validation please refer to 
https://rvm.io/rvm/security

Build step 'Execute shell' marked build as failure
Archiving artifacts
Publishing Javadoc
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] Solr-reference-guide-master - Build # 15911 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15911/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 04b61e3dee440a390ab20a4c65bbdc9523742a45 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 04b61e3dee440a390ab20a4c65bbdc9523742a45
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk 04b61e3dee440a390ab20a4c65bbdc9523742a45 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins8025451748984197131.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[JENKINS] Solr-reference-guide-8.x - Build # 2983 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2983/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins7780961959554324431.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-8041:
---

I have a maybe better suggestion instead of:
- Build a TreeMap like before and name it sortedField()
- Then rebuild it as LinkedHashMap

The problem here is that we have to build a possibly huge map, just to copy it 
to a LinkedHashMap, and hotspot can't easily optimize away the creation on 
heap. The result is fine (as said before): The LinkedHashMap needs a bit more 
heap space than a plain HashMap, but should be of almost identical size to a 
TreeMap (which uses a lot of small inner object instances).

My suggestion would be: You just iterate over the fields, do some 
transformations and then finally add them to a TreeMap. Rewrite that to use 
Java Streams - it may not work for all cases (especially if the iteration has 
I/O involved and the order is important), but e.g. for direct fields it may 
work (possibly the IOException needs to be wrapped):

{code:java}
 public DirectFields(SegmentReadState state, Fields fields, int 
minSkipCount, int lowFreqCutoff) throws IOException {
   this.fields = StreamSupport.stream(fields.spliterator(), false)
.sorted()   // <== that's the trick
.collect(Collectors.toMap(Function.identity(), field -> new 
DirectField(state, field, fields.terms(field), minSkipCount, lowFreqCutoff), 
(u,v) -> throw new IllegalArgumentException("Duplicate field name"), 
LinkedHashMap::new));
 }
{code}

This is totally untested, just as an idea! The merge function there is just 
stupid, but it's never called as there should be no duplicate keys. This 
actually is a bit more strict, if Field is wrongly implemented and returns the 
same field name multiple times in its iterator.

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



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

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

[JENKINS] Solr-reference-guide-master - Build # 15910 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15910/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 04b61e3dee440a390ab20a4c65bbdc9523742a45 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 04b61e3dee440a390ab20a4c65bbdc9523742a45
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk 3a88ab616c9c8debe1f3a10e291697083eda3342 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins8221221639517976441.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed 

[jira] [Comment Edited] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Huy Le (JIRA)]

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

Huy Le edited comment on LUCENE-8041 at 5/16/19 7:57 AM:
-

I created a patch that use LinkedHashMap to maintain field name to Fields 
mapping.  

[^LUCENE-8041-LinkedHashMap.patch]


was (Author: huyyuh):
I created a patch that use LinkedHashMap to maintain field name to Fields 
mapping.

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



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

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

[jira] [Updated] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Huy Le (JIRA)]

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

Huy Le updated LUCENE-8041:
---
Attachment: LUCENE-8041-LinkedHashMap.patch

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



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

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

[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(1) not O(log(N))

[Huy Le (JIRA)]

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

Huy Le commented on LUCENE-8041:


I created a patch that use LinkedHashMap to maintain field name to Fields 
mapping.

> All Fields.terms(fld) impls should be O(1) not O(log(N))
> 
>
> Key: LUCENE-8041
> URL: https://issues.apache.org/jira/browse/LUCENE-8041
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: David Smiley
>Priority: Major
> Attachments: LUCENE-8041-LinkedHashMap.patch, LUCENE-8041.patch
>
>
> I've seen apps that have a good number of fields -- hundreds.  The O(log(N)) 
> of TreeMap definitely shows up in a profiler; sometimes 20% of search time, 
> if I recall.  There are many Field implementations that are impacted... in 
> part because Fields is the base class of FieldsProducer.  
> As an aside, I hope Fields to go away some day; FieldsProducer should be 
> TermsProducer and not have an iterator of fields. If DocValuesProducer 
> doesn't have this then why should the terms index part of our API have it?  
> If we did this then the issue here would be a simple transition to a HashMap.
> Or maybe we can switch to HashMap and relax the definition of Fields.iterator 
> to not necessarily be sorted?
> Perhaps the fix can be a relatively simple conversion over to LinkedHashMap 
> in many cases if we can assume when we initialize these internal maps that we 
> consume them in sorted order to begin with.



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

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

Re: [jira] [Created] (SOLR-13473) Ensure that the tests use JSON,javabin to update docs

[Thomas Wöckinger]

I think both, or ideally every used codec should be tested, so i refactored
the test base to allow easy change of the used code when using
EmbeddedSolrServer. The changes are done with PR
https://github.com/apache/lucene-solr/pull/665, test also added for any
multi value field operations which brought up to additional issues.

On Wed, May 15, 2019 at 11:28 PM Noble Paul (JIRA)  wrote:

> Noble Paul created SOLR-13473:
> -
>
>  Summary: Ensure that the tests use JSON,javabin to update docs
>  Key: SOLR-13473
>  URL: https://issues.apache.org/jira/browse/SOLR-13473
>  Project: Solr
>   Issue Type: Improvement
>   Security Level: Public (Default Security Level. Issues are Public)
> Reporter: Noble Paul
>
>
> {{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon
> update format .
> We should change it to use JSON/javabin
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[JENKINS] Solr-reference-guide-8.x - Build # 2982 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2982/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f f5be84e86a3d3bbcef0a7e3e06f3ab0dd87ad480
Commit message: "Updating DOAP for 8.1 release"
 > git rev-list --no-walk 6a3d32728b784dbba66f6e917d6d277b915d9c72 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins686937531692064963.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0

[GitHub] [lucene-solr] thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347

[GitBox]

thomaswoeckinger commented on issue #665: Fixes SOLR-11841, SOLR-13331, 
SOLR-13347
URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-492957537
 
 
   The files where formatted with settings generated by 'ant eclipse', so they
   where wrong before, i can remove the final modifier which i personally
   prefer.
   
   Some additional inflammations about the issues:
   
   The issues are related to each other due to the change from JavaBinCodec to
   use UTF8CharSequence instead of String, which leads to a collection.remove
   calls which are useless  because their type does not match.
   
   The issue was introduced in version 7.7.x and initially detected on our
   side by integration tests. I want to make sure that this issues will not
   occur again in the future so i added missing unit tests and refactored the
   test base to allow easy exchange of the used codec.
   The test written for SOLR-13331 shows up two additional issues described by
   SOLR-13347 and SOLR-11841. Also some unexpected internal state where caused
   by the EmbeddedSolrServer which i corrected to (return null stream instead
   of empty).
   
   So i will remove the final modifiers and push again!
   
   Thx for your time!
   
   Best,
   Tom
   
   Erick Erickson  schrieb am Mi., 15. Mai 2019,
   19:56:
   
   > There are two things that might help with the arbitrary change issue:
   >
   > 1> On the reviewing side, In InteliJ, I can choose an option “ignore all
   > whitespace”, I’m sure other tools have similar. Doesn’t help with final and
   > the like of course.
   >
   > 2> Again in IntelliJ and (presumably) other tools I can set the autoformat
   > to only reformat changed lines rather than entire files.
   >
   > FWIW,
   > Erick
   >
   > > On May 15, 2019, at 6:49 AM, David Smiley 
   > wrote:
   > >
   > > It'd help to review your changes if you made fewer arbitrary changes,
   > like adding 'final' and changing indentation of javadocs that were fine as
   > they were.
   > > Also, it'd help to summarize why 3 different issues are being fixed in
   > one PR. Might be just fine but please add info/context to make reviewer's
   > job either or you may not get a review at all.
   > >
   > > —
   > > You are receiving this because you were mentioned.
   > > Reply to this email directly, view it on GitHub, or mute the thread.
   > >
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or mute the thread
   > 

   > .
   >
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[ANNOUNCE] Apache Solr 8.1.0 released

[Ishan Chattopadhyaya]

= 16 March 2019, Apache Solr™ 8.1.0 available =

The Lucene PMC is pleased to announce the release of Apache Solr 8.1.0

Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search and analytics, rich
document parsing, geospatial search, extensive REST APIs as well as
parallel SQL. Solr is enterprise grade, secure and highly scalable,
providing fault tolerant distributed search and indexing, and powers
the search and navigation features of many of the world's largest
internet sites.

The release is available for immediate download at:

http://www.apache.org/dyn/closer.lua/lucene/solr/8.1.0

Please read CHANGES.txt for a detailed list of changes:

https://lucene.apache.org/solr/8_1_0/changes/Changes.html

== Solr 8.1.0 Release Highlights ==

 * Partial/Atomic Updates for nested documents. This enables atomic
updates for nested documents, without the need to supply the whole
nested hierarchy (which would be overwritten if absent).
 * Category Routed Aliases feature introduced for data driven
assignment of documents to collections based on values of a field
 * JWT Token authentication plugin with OpenID Connect implicit flow
login through Admin UI
 * REINDEXCOLLECTION command for re-indexing of existing collections
 * Collection RENAME command and support using aliases in most
collection admin commands
 * Read-only mode for SolrCloud collections

Solr 8.1.0 also includes many other new features as well as numerous
optimizations and bugfixes of the corresponding Apache Lucene release.

Please report any feedback to the mailing lists
(http://lucene.apache.org/solr/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also goes for Maven access.

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

[jira] [Comment Edited] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized

[adfel (JIRA)]

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

adfel edited comment on SOLR-13472 at 5/16/19 7:42 AM:
---

We tested using versions 7.7.1, 8.0.0 and a snapshot of 7.7.2 that was built 
about a week ago.


was (Author: adfel70):
We tested against versions 7.7.1, 8.0.0 and a snapshot of 7.7.2 that was built 
about a week ago.

> HTTP requests to a node that does not hold a core of the collection are 
> unauthorized
> 
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Priority: Minor
>  Labels: security
>
> When creating collection in SolrCloud, collection is available for queries 
> and updates through all Solr nodes, in particular nodes that does not hold 
> one of collection's cores. This is expected behaviour that works when using 
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for 
> HTTP requests:
>  - executing request to a node that holds part of the collection (core) obey 
> to authorization rules as expected.
>  - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following 
> security.json file to zookeeper:
>  
> {code:java}
> {
>  "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
>  "solr": "'solr' user password_hash",
>  "indexer_app": "'indexer_app' password_hash",
>  "read_user": "'read_user' password_hash"
>}
>  },
>  "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
>  {
>"name": "read",
>"role": "*"
>  },
>  {
>"name": "update",
>"role": [
>  "indexer",
>  "admin"
>]
>  },
>  {
>"name": "all",
>"role": "admin"
>  }
>],
>"user-role": {
>  "solr": "admin",
>  "indexer_app": "indexer"
>}
>  }
> }{code}
>  
> 3. create 'test' collection with one shard on *node_1*.
> -- 
> The following requests expected to succeed but return 403 status 
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>  
> Authenticated '_solr_' user requests works as expected. My guess is due to 
> the special '_all_' role.



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

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

[JENKINS] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-11.0.2) - Build # 59 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/59/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 58991 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-BadApples-8.x-Linux/build.xml:643: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-8.x-Linux/build.xml:507: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-BadApples-8.x-Linux/build.xml:494: Source 
checkout is dirty (unversioned/missing files) after running tests!!! Offending 
files:
* solr/licenses/noggit-0.8.jar.sha1

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

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

[jira] [Commented] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized

[adfel (JIRA)]

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

adfel commented on SOLR-13472:
--

We tested against versions 7.7.1, 8.0.0 and a snapshot of 7.7.2 that was built 
about a week ago.

> HTTP requests to a node that does not hold a core of the collection are 
> unauthorized
> 
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Priority: Minor
>  Labels: security
>
> When creating collection in SolrCloud, collection is available for queries 
> and updates through all Solr nodes, in particular nodes that does not hold 
> one of collection's cores. This is expected behaviour that works when using 
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for 
> HTTP requests:
>  - executing request to a node that holds part of the collection (core) obey 
> to authorization rules as expected.
>  - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following 
> security.json file to zookeeper:
>  
> {code:java}
> {
>  "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
>  "solr": "'solr' user password_hash",
>  "indexer_app": "'indexer_app' password_hash",
>  "read_user": "'read_user' password_hash"
>}
>  },
>  "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
>  {
>"name": "read",
>"role": "*"
>  },
>  {
>"name": "update",
>"role": [
>  "indexer",
>  "admin"
>]
>  },
>  {
>"name": "all",
>"role": "admin"
>  }
>],
>"user-role": {
>  "solr": "admin",
>  "indexer_app": "indexer"
>}
>  }
> }{code}
>  
> 3. create 'test' collection with one shard on *node_1*.
> -- 
> The following requests expected to succeed but return 403 status 
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>  
> Authenticated '_solr_' user requests works as expected. My guess is due to 
> the special '_all_' role.



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

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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 199 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/199/

All tests passed

Build Log:
[...truncated 62462 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj769559510
 [ecj-lint] Compiling 1272 source files to /tmp/ecj769559510
 [ecj-lint] Processing annotations
 [ecj-lint] Annotations processed
 [ecj-lint] Processing annotations
 [ecj-lint] No elements to process
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
/x1/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java
 (at line 265)
 [ecj-lint] throw new SolrException(ErrorCode.BAD_REQUEST, "Unexpected 
number of replicas, replicationFactor, " +
 [ecj-lint]   Replica.Type.NRT + " or " + Replica.Type.TLOG + " 
must be greater than 0");
 [ecj-lint] 
^^^
 [ecj-lint] Resource leak: 'repository' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
 (at line 74)
 [ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
 [ecj-lint]   ^^
 [ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 5. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 6. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
 (at line 215)
 [ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
 [ecj-lint] ^
 [ecj-lint] Resource leak: 'leafReader' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 7. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
 (at line 142)
 [ecj-lint] return new JavaBinCodec(null, 
stringCache).setReadStringAsCharSeq(true);
 [ecj-lint]^^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 8. WARNING in 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
 (at line 137)
 [ecj-lint] new JavaBinCodec() {
 [ecj-lint]   SolrParams params;
 [ecj-lint]   AddUpdateCommand addCmd = null;
 [ecj-lint] 
 [ecj-lint]   @Override
 [ecj-lint]   public List readIterator(DataInputInputStream fis) 
throws IOException {
 [ecj-lint] while (true) {
 [ecj-lint]   Object o = readVal(fis);
 [ecj-lint]   if (o == END_OBJ) break;
 [ecj-lint]   if (o instanceof NamedList) {
 [ecj-lint] params = ((NamedList) o).toSolrParams();
 [ecj-lint]   } else {
 [ecj-lint] try {
 [ecj-lint]   if (o instanceof byte[]) {
 [ecj-lint] if (params != null) req.setParams(params);
 [ecj-lint] 

[ANNOUNCE] Apache Lucene 8.1.0 released

[Ishan Chattopadhyaya]

16 March 2019, Apache Lucene™ 8.1.0 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.1.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html

Lucene 8.1.0 Release Highlights:

 * A query introspection API has been introduced.
 * Luke, well-known GUI for inspecting Lucene indexes, now added as a
Lucene module
 * Merging dimensional points to use radix partitioning, which has
also been optimized
 * Bugfix: LatLonShapePolygonQuery returns incorrect WITHIN results
with shared boundaries
 * TieredMergePolicy#findForcedMerges now tries to create the cheapest merges
 * Build point writers in the BKD tree only when they are needed
 * SynonymQuery can now deboost the document frequency of each term
when blending synonym scores
 * ConstantScoreQuery can early terminate if minimum score > constant
score (total hits are not requested)
 * DateRangePrefixTree can now parse more precise dates

Further details of changes are available in the change log available
at: http://lucene.apache.org/core/8_1_0/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also applies to Maven access.

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

[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-9.0.4) - Build # 258 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/258/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 59028 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:634: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:507: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\build.xml:494: Source 
checkout is dirty (unversioned/missing files) after running tests!!! Offending 
files:
* solr/licenses/noggit-0.8.jar.sha1

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

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

[GitHub] [lucene-solr] asfgit closed pull request #189: Jira/solr 6203

[GitBox]

asfgit closed pull request #189: Jira/solr 6203
URL: https://github.com/apache/lucene-solr/pull/189
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[JENKINS] Solr-reference-guide-master - Build # 15909 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15909/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 3a88ab616c9c8debe1f3a10e291697083eda3342 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3a88ab616c9c8debe1f3a10e291697083eda3342
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to 
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on 
Geo3D. * Better testing for Geo3D."
 > git rev-list --no-walk 3a88ab616c9c8debe1f3a10e291697083eda3342 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins7620140070793470239.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using 

[JENKINS] Solr-reference-guide-8.x - Build # 2981 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2981/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 6a3d32728b784dbba66f6e917d6d277b915d9c72 
(refs/remotes/origin/branch_8x)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 6a3d32728b784dbba66f6e917d6d277b915d9c72
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to 
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on 
Geo3D. * Better testing for Geo3D."
 > git rev-list --no-walk 6a3d32728b784dbba66f6e917d6d277b915d9c72 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins953640033809205929.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using 

[jira] [Commented] (LUCENE-8788) Order LeafReaderContexts by Estimated Number Of Hits

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8788:
-

Folks, any thoughts on this?

 

I am envisioning adding a generic mechanism which can allow users to order 
slices in any custom order. Note that segments within a slice will still be 
ordered by docID to maintain guarantees while collecting hits.

 

This can be useful for custom early termination logic and better control for 
users to customize query execution for thir specific workloads

> Order LeafReaderContexts by Estimated Number Of Hits
> 
>
> Key: LUCENE-8788
> URL: https://issues.apache.org/jira/browse/LUCENE-8788
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
>
> We offer no guarantee on the order in which an IndexSearcher will look at 
> segments during a search operation. This can be improved for use cases where 
> an engine using Lucene invokes early termination and uses the partially 
> collected hits. A better model would be if we sorted segments by the 
> estimated number of hits, thus increasing the probability of the overall 
> relevance of the returned partial results.



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

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

[jira] [Created] (SOLR-13475) Nullpointer-Exception when querying collection through collection alias

[JIRA]

Jörn Franke created SOLR-13475:
--

 Summary: Nullpointer-Exception when querying collection through 
collection alias
 Key: SOLR-13475
 URL: https://issues.apache.org/jira/browse/SOLR-13475
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 8.1
Reporter: Jörn Franke


I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with 
collection aliases, but I am not 100% sure it is due to the upgrade.
 
Situation:
I have a collection called c_testcollection. 
I have an alias called testcollection.
Alias "testcollection" points to "c_testcollection".
On Solr 8.0 no issue to query the collection through its alias 
"testcollection", e.g [http://localhost:8983/solr/testcollection/select?q=test]
 
After upgrade to Solr 8.1:
When I do a query on c_testcollection then there is no issue:
[http://localhost:8983/solr/c_testcollection/select?q=test]
When I do a query on testcollection then I receive the stacktrace below
[http://localhost:8983/solr/testcollection/select?q=test]
 
Additionally I observe a strange behavior in the admin ui. When I try to create 
an alias (e.g. new) for a new collection (e.g. c_new) then it creates two 
aliases:
new => c_new
c_new => c_new
if i then do a query on the alias new it works without issues. If I remove the 
alias from c_new to c_new then I get the same error. Is this desired behaviour?
It is rather annoying to have unnecessary aliases, because I need to filter 
them out in my application when retrieving all aliases.
Is there a related issue.
 
Here the stacktrace:
{
  "error":{
    "trace":"java.lang.NullPointerException\n\tat 
java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
 
org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
 org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat 
org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
 org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
 org.eclipse.jetty.server.Server.handle(Server.java:502)\n\tat 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat 
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
 
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
 
org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat 

Re: Solr 8.1 issue with collection aliases

[Jörn Franke]

SOLR-13475

> Am 16.05.2019 um 05:24 schrieb Ishan Chattopadhyaya 
> :
> 
> Please open a JIRA.
> 
>> On Thu, 16 May, 2019, 8:09 AM Jörn Franke,  wrote:
>> Sorry autocorrection. It is not only a admin UI issue. I described in my 
>> previous email that access through the collection alias does not work. I 
>> cannot even do execute the select query handler if I use the collection 
>> alias instead of the collection name.
>> So it is maybe more problematic.
>> 
>>> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>>> 
>>> Note only an admin UI issue. Access collections via their alias does not 
>>> work.
>>> 
 Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
 
 It seems creating alias in Solr Admin UI is broken. It's a minor issue for 
 8.1.0 
 I've alias via REST call 
 http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
   successfully. 
 Jörn, thanks for reporting. 
 
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke  wrote:
> Hi,
> 
> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
> collection aliases, but I am not 100% sure it is due to the upgrade.
> 
> Situation:
> I have a collection called c_testcollection.
> I have an alias called testcollection.
> Alias "testcollection" points to "c_testcollection".
> On Solr 8.0 no issue
> 
> After upgrade to Solr 8.1:
> When I do a query on c_testcollection then there is no issue:
> http://localhost:8983/solr/c_testcollection/select?q=test
> When I do a query on testcollection then I receive the stacktrace below
> http://localhost:8983/solr/testcollection/select?q=test
> 
> Additionally I observe a strange behavior in the admin ui. When I try to
> create an alias (e.g. new) for a new collection (e.g. c_new) then it
> creates two aliases:
> new => c_new
> c_new => c_new
> if i then do a query on the alias new it works without issues. If I remove
> the alias from c_new to c_new then I get the same error. Is this desired
> behaviour?
> It is rather annoying to have unnecessary aliases, because I need to 
> filter
> them out in my application when retrieving all aliases.
> Is there a related issue.
> 
> Here the stacktrace:
> {
>   "error":{
> "trace":"java.lang.NullPointerException\n\tat
> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\n\tat
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> 

[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 206 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/206/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test

Error Message:
.responseHeader.status:200!=0

Stack Trace:
junit.framework.AssertionFailedError: .responseHeader.status:200!=0
at 
__randomizedtesting.SeedInfo.seed([352B531224281502:BD7F6CC88AD478FA]:0)
at junit.framework.Assert.fail(Assert.java:57)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareSolrResponses(BaseDistributedSearchTestCase.java:999)
at 
org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:1026)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:680)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:643)
at 
org.apache.solr.handler.component.TestDistributedStatsComponentCardinality.test(TestDistributedStatsComponentCardinality.java:194)
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:567)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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 

[JENKINS] Lucene-Solr-NightlyTests-8.x - Build # 99 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/99/

1 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI

Error Message:
{} expected:<2> but was:<0>

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([F5EA7165470B85B0:EA3DED4934007CFB]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:293)
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:1750)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
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:947)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
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:748)




Build Log:
[...truncated 14401 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> Creating dataDir: 

[JENKINS] Solr-reference-guide-master - Build # 15908 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/15908/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from 
https://gitbox.apache.org/repos/asf/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://gitbox.apache.org/repos/asf/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 3a88ab616c9c8debe1f3a10e291697083eda3342 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3a88ab616c9c8debe1f3a10e291697083eda3342
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to 
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on 
Geo3D. * Better testing for Geo3D."
 > git rev-list --no-walk 3a88ab616c9c8debe1f3a10e291697083eda3342 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins4747219219557925200.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
  * It looks like some old stuff is laying around RVM, you can cleanup with: 
rvm cleanup all


Thanks for installing RVM 
Please consider donating to our open collective to help us maintain RVM.

  Donate: https://opencollective.com/rvm/donate


+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up, 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
 Usually this is caused by shell initialization files. Search for 
PATH=... entries.
 You can also re-add RVM to your profile by running: rvm get 
stable --auto-dotfiles
 To fix it temporarily in this shell session run: rvm use 
ruby-2.3.3
 To ignore this error add 
rvm_silence_path_mismatch_check_flag=1 to your 
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using