Re: VOTE: Release Apache Solr Ref Guide for 7.7

[Furkan KAMACI]

Hi,

+1

Thanks for doing this!

Kind Regards,
Furkan KAMACI

On Fri, Mar 8, 2019 at 9:03 AM Tomás Fernández Löbbe 
wrote:

> +1
>
> On Thu, Mar 7, 2019 at 11:14 AM Anshum Gupta 
> wrote:
>
>> +1
>>
>> Thanks for doing this, Jason!
>>
>> *  *Anshum
>>
>>
>> On Mar 4, 2019, at 7:28 AM, Jason Gerlowski 
>> wrote:
>>
>> Please vote to release the Solr Ref Guide for 7.7.
>>
>> The PDF artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/
>>
>> $ cat apache-solr-ref-guide-7.7.pdf.sha512
>>
>> a4a89cf56c90a2f05874e4770726cf3635bbbde3c8e7dace92b51bd01e08d486754de06f753c0c1a6d7fab63068898e991d9bfeb024e945b2f898cce18ee8d3d
>> apache-solr-ref-guide-7.7.pdf
>>
>>
>> The PDF is up to 1431 pages!
>>
>> The online version is available at:
>> http://lucene.apache.org/solr/guide/7_7/
>>
>> Here's my +1.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>

[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 62 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/62/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  org.apache.solr.cloud.BasicDistributedZkTest.test

Error Message:
Could not load collection from ZK: multiunload2

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
multiunload2
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1366)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:748)
at 
org.apache.solr.common.cloud.ClusterState$CollectionRef.get(ClusterState.java:386)
at 
org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:400)
at 
org.apache.solr.cloud.BasicDistributedZkTest.testStopAndStartCoresInOneInstance(BasicDistributedZkTest.java:625)
at 
org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:428)
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 
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 
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 

Re: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Anshum Gupta]

Having done these releases more than a few times, I completely understand
the frustration caused by such delays but I think that SOLR-13285 is
something that really breaks Solr in a major version release. We can always
have a 8.0.1 release that fixes it but I feel like it would not be a good
thing to offer an 8.0.0 version to end-users knowing that it would cause
issues for anyone using enum fields.

I am sorry that it would require more time and effort at the end of the RM
but In my opinion, this is worth a respin.

Anshum

On Thu, Mar 7, 2019 at 10:52 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> In case we go through with this RC, I can volunteer to release a 8.0.1
> (with SOLR-13285) immediately after 8.0.0 release.
> @Adrien, Jim, I really understand the frustrations of an RM, and I also
> apologize for the delay I caused to this release due to the intermediate
> 7.7.1 release where I didn't do it as quickly as I could have (delay in
> building the RC, delay in backporting the backward compatibility indexes
> etc).
>
>
> On Fri, Mar 8, 2019 at 10:52 AM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> I understand the frustration with the delay and the number of respins,
>> and I don't want to be disrespectful of Jim's time as RC, but from what I
>> can see, SOLR-13285 would prevent anyone with enum fields to use Solr 8.0,
>> and the fix is already available.
>>
>> -0
>>
>> On Thu, Mar 7, 2019 at 2:14 PM Nhat Nguyen 
>> wrote:
>>
>>> +1 SUCCESS! [0:54:05.261238]
>>>
>>> > On Mar 7, 2019, at 4:44 PM, Adrien Grand  wrote:
>>> >
>>> > +1 SUCCESS! [1:25:54.239684]
>>> >
>>> > On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi  wrote:
>>> >>
>>> >> Please vote for release candidate 3 for Lucene/Solr 8.0.0
>>> >>
>>> >> The artifacts can be downloaded from
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>>> >> You can run the smoke tester directly with this command:
>>> >> python3 -u dev-tools/scripts/smokeTestRelease.py
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>>> >>
>>> >> Here’s my +1
>>> >> SUCCESS! [1:14:08.843490]
>>> >
>>> >
>>> >
>>> > --
>>> > Adrien
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

[jira] [Commented] (SOLR-13268) Clean up any test failures resulting from defaulting to async logging

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 160 new or modified 
test files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m  3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m  3s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m  
7s{color} | {color:green} tools in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  1m 
15s{color} | {color:green} ltr in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 42m 
18s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  5m 
41s{color} | {color:green} solrj in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
25s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 57s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13268 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12961499/SOLR-13268.patch |
| Optional Tests |  ratsources  validatesourcepatterns  compile  javac  unit  
checkforbiddenapis  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 20de3d2 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/330/testReport/ |
| modules | C: lucene/tools solr/contrib/ltr solr/core solr/solrj 
solr/test-framework U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/330/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Clean up any test failures resulting from defaulting to async logging
> -
>
> Key: SOLR-13268
> URL: https://issues.apache.org/jira/browse/SOLR-13268
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: SOLR-13268.patch, SOLR-13268.patch
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This is a catch-all for test failures due to the async logging changes. So 
> far, the I see a couple failures on JDK13 only. I'll collect a "starter set" 
> here, these are likely systemic, once the root cause is found/fixed, then 
> others are likely fixed as well.
> JDK13:
> ant test  -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV 
> -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8
> ant test  -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E 
> -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk 
> -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8



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

Re: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Ishan Chattopadhyaya]

In case we go through with this RC, I can volunteer to release a 8.0.1
(with SOLR-13285) immediately after 8.0.0 release.
@Adrien, Jim, I really understand the frustrations of an RM, and I also
apologize for the delay I caused to this release due to the intermediate
7.7.1 release where I didn't do it as quickly as I could have (delay in
building the RC, delay in backporting the backward compatibility indexes
etc).


On Fri, Mar 8, 2019 at 10:52 AM Tomás Fernández Löbbe 
wrote:

> I understand the frustration with the delay and the number of respins, and
> I don't want to be disrespectful of Jim's time as RC, but from what I can
> see, SOLR-13285 would prevent anyone with enum fields to use Solr 8.0, and
> the fix is already available.
>
> -0
>
> On Thu, Mar 7, 2019 at 2:14 PM Nhat Nguyen 
> wrote:
>
>> +1 SUCCESS! [0:54:05.261238]
>>
>> > On Mar 7, 2019, at 4:44 PM, Adrien Grand  wrote:
>> >
>> > +1 SUCCESS! [1:25:54.239684]
>> >
>> > On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi  wrote:
>> >>
>> >> Please vote for release candidate 3 for Lucene/Solr 8.0.0
>> >>
>> >> The artifacts can be downloaded from
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>> >> You can run the smoke tester directly with this command:
>> >> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>> >>
>> >> Here’s my +1
>> >> SUCCESS! [1:14:08.843490]
>> >
>> >
>> >
>> > --
>> > Adrien
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Security Contact for Solr?

[Ishan Chattopadhyaya]

secur...@lucene.apache.org
Please send your security reports here ^


On Fri, Mar 8, 2019 at 7:37 AM Martin Gainty  wrote:

> svan-
>
> BECAUSE solr can deploy to n number of containers
> Jetty/Tomcat/Docker/Websphere/Weblogic (i'm certain i have  omitted a few
> implementation containers)
> Implementing comprehensive PKI Infrastructure is heavily dependent on the
> container solr is deployed to
>
> i have  a few spare cycles to help out if need be
>
> martin-
>
> --
> *From:* s...@apple.com  on behalf of Sven Blumenstein
> 
> *Sent:* Thursday, March 7, 2019 3:24 PM
> *To:* dev@lucene.apache.org
> *Subject:* Security Contact for Solr?
>
> Hi .*,
>
> what is the proper contact for reporting security vulnerabilities in Solr?
> Do you have a security@ address or a non-public mailing list/bug
> component? Unfortunately I could not find any information in that regard on
> the Solr website, hence my reach out to this mailing list.
>
> Thanks!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-13284) NPE on passing Invalid response writer as request parameter

[Lucene/Solr QA (JIRA)]

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

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

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} | 
{color:green}  1m 28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 22m 20s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 28m 57s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.search.TestStandardQParsers |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13284 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12961104/SOLR-13284.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon 
Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 20de3d2 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_191 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/329/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/329/testReport/ |
| modules | C: solr/core solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/329/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> NPE on passing Invalid response writer as request parameter
> ---
>
> Key: SOLR-13284
> URL: https://issues.apache.org/jira/browse/SOLR-13284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-13284.patch, SOLR-13284.patch
>
>
> V1 API or the old API uses default response writer when non-existent response 
> writer is specified in the request whereas V2 API fails with NPE with below 
> stack trace
> {noformat}
> {trace=java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:776)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>   at 
> 

Re: VOTE: Release Apache Solr Ref Guide for 7.7

[Tomás Fernández Löbbe]

+1

On Thu, Mar 7, 2019 at 11:14 AM Anshum Gupta 
wrote:

> +1
>
> Thanks for doing this, Jason!
>
> *  *Anshum
>
>
> On Mar 4, 2019, at 7:28 AM, Jason Gerlowski 
> wrote:
>
> Please vote to release the Solr Ref Guide for 7.7.
>
> The PDF artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/
>
> $ cat apache-solr-ref-guide-7.7.pdf.sha512
>
> a4a89cf56c90a2f05874e4770726cf3635bbbde3c8e7dace92b51bd01e08d486754de06f753c0c1a6d7fab63068898e991d9bfeb024e945b2f898cce18ee8d3d
> apache-solr-ref-guide-7.7.pdf
>
>
> The PDF is up to 1431 pages!
>
> The online version is available at:
> http://lucene.apache.org/solr/guide/7_7/
>
> Here's my +1.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateCollWithDefaultClusterPropertiesOldFormat

Error Message:
expected:<[2]> but was:<[null]>

Stack Trace:
org.junit.ComparisonFailure: expected:<[2]> but was:<[null]>
at 
__randomizedtesting.SeedInfo.seed([6C87D6BC0B1D7A63:654F9597F7656DC]:0)
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateCollWithDefaultClusterPropertiesOldFormat(CollectionsAPISolrJTest.java:138)
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 14010 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPISolrJTest
   [junit4]   2> Creating dataDir: 

Re: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Tomás Fernández Löbbe]

I understand the frustration with the delay and the number of respins, and
I don't want to be disrespectful of Jim's time as RC, but from what I can
see, SOLR-13285 would prevent anyone with enum fields to use Solr 8.0, and
the fix is already available.

-0

On Thu, Mar 7, 2019 at 2:14 PM Nhat Nguyen 
wrote:

> +1 SUCCESS! [0:54:05.261238]
>
> > On Mar 7, 2019, at 4:44 PM, Adrien Grand  wrote:
> >
> > +1 SUCCESS! [1:25:54.239684]
> >
> > On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi  wrote:
> >>
> >> Please vote for release candidate 3 for Lucene/Solr 8.0.0
> >>
> >> The artifacts can be downloaded from
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> >> You can run the smoke tester directly with this command:
> >> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> >>
> >> Here’s my +1
> >> SUCCESS! [1:14:08.843490]
> >
> >
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Updated] (SOLR-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-13285:
-
Affects Version/s: (was: 8.1)

> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during 
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
>  Labels: newbie, replication
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing 
> the following errors in the SolrCloud elected master for a given collection 
> when updates are written.  This was after a full reindex of data (fresh 
> build).
> {code:java}
> request: 
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence 
> cannot be cast to java.lang.String
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  ~[metrics-core-3.2.6.jar:3.2.6]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_191]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ClassCastException: 
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to 
> java.lang.String
> at 
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:191)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
> at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
> at 
> 

[jira] [Commented] (LUCENE-7929) WordDelimiterGraphFilter doesn't split HTTPRequest properly

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7929:
--

Looks nice to me; thanks for contributing.  I sympathize that it's tough to get 
the attention that your patch deserves; we committers are a busy bunch.

> WordDelimiterGraphFilter doesn't split HTTPRequest properly
> ---
>
> Key: LUCENE-7929
> URL: https://issues.apache.org/jira/browse/LUCENE-7929
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Nicolás Lichtmaier
>Priority: Major
>
> The current implementation of WordDelimiterGraphFilter doesn't properly deal 
> with all uppercase parts, and also it doesn't handle numbers well in some 
> cases.
> I've created a pull request with changes to fix that: 
> https://github.com/apache/lucene-solr/pull/231
> With my patch HTTPRequest is split into HTTP and Request.



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

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 2316 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2316/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
Captured an uncaught exception in thread: Thread[id=34228, 
name=testExecutor-10144-thread-2, state=RUNNABLE, 
group=TGRP-BasicDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=34228, name=testExecutor-10144-thread-2, 
state=RUNNABLE, group=TGRP-BasicDistributedZkTest]
at 
__randomizedtesting.SeedInfo.seed([717364A55D82B79A:F9275B7FF37EDA62]:0)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:55489/mg_zmt/cr: ADDREPLICA failed to create 
replica
at __randomizedtesting.SeedInfo.seed([717364A55D82B79A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:649)
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.cloud.BasicDistributedZkTest.lambda$createCollectionInOneInstance$1(BasicDistributedZkTest.java:657)
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)




Build Log:
[...truncated 14095 lines...]
   [junit4] Suite: org.apache.solr.cloud.BasicDistributedZkTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.BasicDistributedZkTest_717364A55D82B79A-001/init-core-data-001
   [junit4]   2> 1918950 WARN  
(SUITE-BasicDistributedZkTest-seed#[717364A55D82B79A]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=31 numCloses=31
   [junit4]   2> 1918950 INFO  
(SUITE-BasicDistributedZkTest-seed#[717364A55D82B79A]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=true
   [junit4]   2> 1918952 INFO  
(SUITE-BasicDistributedZkTest-seed#[717364A55D82B79A]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 1918952 INFO  
(SUITE-BasicDistributedZkTest-seed#[717364A55D82B79A]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 1918952 INFO  
(SUITE-BasicDistributedZkTest-seed#[717364A55D82B79A]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/mg_zmt/cr
   [junit4]   2> 1918956 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1918957 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1918957 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 1919058 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer start zk server on port:65482
   [junit4]   2> 1919058 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:65482
   [junit4]   2> 1919058 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer connecting to 127.0.0.1 65482
   [junit4]   2> 1919065 INFO  (zkConnectionManagerCallback-12097-thread-1) [   
 ] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1919069 INFO  (zkConnectionManagerCallback-12099-thread-1) [   
 ] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1919071 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer put 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1919073 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 
o.a.s.c.ZkTestServer put 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/core/src/test-files/solr/collection1/conf/schema.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1919075 INFO  
(TEST-BasicDistributedZkTest.test-seed#[717364A55D82B79A]) [] 

[jira] [Commented] (SOLR-13283) when facet with certain terms via {!terms}, facet.limit, facet.offset does not work

[superman369 (JIRA)]

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

superman369 commented on SOLR-13283:


@[~mkhludnev],   hello， how is the progress？ I  very need the feature,  thank 
you very much!

> when facet with certain terms via {!terms}, facet.limit, facet.offset does 
> not work
> ---
>
> Key: SOLR-13283
> URL: https://issues.apache.org/jira/browse/SOLR-13283
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Affects Versions: 7.7
>Reporter: superman369
>Priority: Major
>
> h4.  I do a test in solr7.7.   Limiting field facet with certain terms via 
> \{!terms}  is work use facet.sort=count, but facet.limit, facet.offset does 
> not work. What's wrong?
> h4. for example: 
> facet.field=\{!terms='1453,1452,1248'}location.authorIds=true=1=1,
>   facet result  : "location.authorIds" has 3 items.  I think it should  have 
> one item. 



--
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-13307) Ensure HDFS tests clear System properties they set

[Kevin Risden (JIRA)]

Kevin Risden created SOLR-13307:
---

 Summary: Ensure HDFS tests clear System properties they set
 Key: SOLR-13307
 URL: https://issues.apache.org/jira/browse/SOLR-13307
 Project: Solr
  Issue Type: Test
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Kevin Risden
Assignee: Kevin Risden
 Fix For: 8.x, master (9.0)


While looking at SOLR-13297, found there are system properties that are not 
cleared in HDFS tests. This can cause other HDFS tests in the same JVM to have 
weird configs.



--
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-13297) StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13297:
-

Well I think I found part of the problem. There are HDFS tests that don't clear 
the system properties they set. I found it by mistake by setting some HDFS 
system properties and caused the tests to fail every time. I looked through the 
logs and saw that there are a few HDFS tests that don't clear the set 
properties at the end.

> StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3
> -
>
> Key: SOLR-13297
> URL: https://issues.apache.org/jira/browse/SOLR-13297
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: builds.a.o_solr_badapple_nightly_8x_7.txt.gz, 
> builds.a.o_solr_badapple_nightly_master_51.txt.gz, 
> builds.a.o_solr_nightly_8x_36.txt.gz, builds.a.o_solr_repro_2965.txt.gz
>
>
> As reported by [~hossman] on SOLR-9515, StressHdfsTest and 
> HdfsUnloadDistributedZkTest are failing more regularly. Should figure out 
> what is going on here.



--
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-repro - Build # 2991 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2991/

[...truncated 29 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/38/consoleText

[repro] Revision: bb5b7f08b1b3bb22b0cb8549c446abe7e3a4f3ca

[repro] Ant options: -Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
[repro] Repro line:  ant test  -Dtestcase=HdfsAutoAddReplicasIntegrationTest 
-Dtests.method=testSimple -Dtests.seed=E32FDD5C22C55C4D -Dtests.multiplier=2 
-Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-IE -Dtests.timezone=Europe/Berlin -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b
[repro] git fetch
[repro] git checkout bb5b7f08b1b3bb22b0cb8549c446abe7e3a4f3ca

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   HdfsAutoAddReplicasIntegrationTest
[repro] ant compile-test

[...truncated 3575 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror 
-Dtests.multiplier=2 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.seed=E32FDD5C22C55C4D -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt
 -Dtests.locale=en-IE -Dtests.timezone=Europe/Berlin -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1

[...truncated 4853 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   2/5 failed: 
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest
[repro] git checkout 20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 6 lines...]

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

Re: Security Contact for Solr?

[Martin Gainty]

svan-

BECAUSE solr can deploy to n number of containers
Jetty/Tomcat/Docker/Websphere/Weblogic (i'm certain i have  omitted a few 
implementation containers)
Implementing comprehensive PKI Infrastructure is heavily dependent on the 
container solr is deployed to

i have  a few spare cycles to help out if need be

martin-


From: s...@apple.com  on behalf of Sven Blumenstein 

Sent: Thursday, March 7, 2019 3:24 PM
To: dev@lucene.apache.org
Subject: Security Contact for Solr?

Hi .*,

what is the proper contact for reporting security vulnerabilities in Solr? Do 
you have a security@ address or a non-public mailing list/bug component? 
Unfortunately I could not find any information in that regard on the Solr 
website, hence my reach out to this mailing list.

Thanks!


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

[jira] [Commented] (SOLR-13254) wrong log when reconnect to zk

[hu xiaodong (JIRA)]

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

hu xiaodong commented on SOLR-13254:


Thank you [~cpoerschke] ，can you change assigntee to me.:)

> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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-NightlyTests-8.0 - Build # 14 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.0/14/

1 tests failed.
FAILED:  org.apache.solr.core.OpenCloseCoreStressTest.test10Minutes

Error Message:
Core 0_core bad! expected:<11862> but was:<11436>

Stack Trace:
java.lang.AssertionError: Core 0_core bad! expected:<11862> but was:<11436>
at 
__randomizedtesting.SeedInfo.seed([728780917FE3B4B8:62025438ED467E93]: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.core.OpenCloseCoreStressTest.checkResults(OpenCloseCoreStressTest.java:280)
at 
org.apache.solr.core.OpenCloseCoreStressTest.doStress(OpenCloseCoreStressTest.java:179)
at 
org.apache.solr.core.OpenCloseCoreStressTest.test10Minutes(OpenCloseCoreStressTest.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 13390 lines...]

[jira] [Commented] (SOLR-12923) The new AutoScaling tests are way to flaky and need special attention.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12923:


Commit 5abc75460753a301087ef80dd8d8dc9301f7aeba in lucene-solr's branch 
refs/heads/branch_7x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5abc754 ]

SOLR-12923: harden TestSimLargeCluster

- added logging
- ensure start/finish trigger action counters are incremented before latches 
are released
- replace arbitrary sleep calls with a trigger listener countdown latch
- increase all await() times: This means that 'real' failures (which should be 
rare and hopefully
  reproducible) will be 'slow', but the trade off will be less hard to 
reproduce 'false failures'
  due to thread contention on slow or heavily loaded (ie: jenkins) machines

(cherry picked from commit 20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b)

Conflicts:

solr/core/src/test/org/apache/solr/cloud/autoscaling/sim/TestSimLargeCluster.java


> The new AutoScaling tests are way to flaky and need special attention.
> --
>
> Key: SOLR-12923
> URL: https://issues.apache.org/jira/browse/SOLR-12923
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
> I've already done some work here (not posted yet). We need to address this, 
> these tests are too new to fail so often and easily.
> I want to add beasting to precommit (LUCENE-8545) to help prevent tests that 
> fail so easily from being committed.



--
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-7929) WordDelimiterGraphFilter doesn't split HTTPRequest properly

[JIRA]

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

Nicolás Lichtmaier commented on LUCENE-7929:


No comments at all since 2017? I thought this could be useful. At least say it 
isn't. (It is for us, at Wolfram, this is being used in Mathematica).

> WordDelimiterGraphFilter doesn't split HTTPRequest properly
> ---
>
> Key: LUCENE-7929
> URL: https://issues.apache.org/jira/browse/LUCENE-7929
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Nicolás Lichtmaier
>Priority: Major
>
> The current implementation of WordDelimiterGraphFilter doesn't properly deal 
> with all uppercase parts, and also it doesn't handle numbers well in some 
> cases.
> I've created a pull request with changes to fix that: 
> https://github.com/apache/lucene-solr/pull/231
> With my patch HTTPRequest is split into HTTP and Request.



--
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-12923) The new AutoScaling tests are way to flaky and need special attention.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12923:


Commit 27aeb11a37e258c9dae7c4c71361cb005026a746 in lucene-solr's branch 
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=27aeb11 ]

SOLR-12923: harden TestSimLargeCluster

- added logging
- ensure start/finish trigger action counters are incremented before latches 
are released
- replace arbitrary sleep calls with a trigger listener countdown latch
- increase all await() times: This means that 'real' failures (which should be 
rare and hopefully
  reproducible) will be 'slow', but the trade off will be less hard to 
reproduce 'false failures'
  due to thread contention on slow or heavily loaded (ie: jenkins) machines

(cherry picked from commit 20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b)


> The new AutoScaling tests are way to flaky and need special attention.
> --
>
> Key: SOLR-12923
> URL: https://issues.apache.org/jira/browse/SOLR-12923
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
> I've already done some work here (not posted yet). We need to address this, 
> these tests are too new to fail so often and easily.
> I want to add beasting to precommit (LUCENE-8545) to help prevent tests that 
> fail so easily from being committed.



--
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-12923) The new AutoScaling tests are way to flaky and need special attention.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12923:


Commit 6b606b787f70451edeb5acc13818802e5e41b0a4 in lucene-solr's branch 
refs/heads/branch_8_0 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6b606b7 ]

SOLR-12923: harden TestSimLargeCluster

- added logging
- ensure start/finish trigger action counters are incremented before latches 
are released
- replace arbitrary sleep calls with a trigger listener countdown latch
- increase all await() times: This means that 'real' failures (which should be 
rare and hopefully
  reproducible) will be 'slow', but the trade off will be less hard to 
reproduce 'false failures'
  due to thread contention on slow or heavily loaded (ie: jenkins) machines

(cherry picked from commit 20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b)

Conflicts:

solr/core/src/test/org/apache/solr/cloud/autoscaling/sim/TestSimLargeCluster.java


> The new AutoScaling tests are way to flaky and need special attention.
> --
>
> Key: SOLR-12923
> URL: https://issues.apache.org/jira/browse/SOLR-12923
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
> I've already done some work here (not posted yet). We need to address this, 
> these tests are too new to fail so often and easily.
> I want to add beasting to precommit (LUCENE-8545) to help prevent tests that 
> fail so easily from being committed.



--
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-12923) The new AutoScaling tests are way to flaky and need special attention.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-12923:


Commit 20de3d2ee0d234d04bbcf7c2cddc18ff67a09f8b in lucene-solr's branch 
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=20de3d2 ]

SOLR-12923: harden TestSimLargeCluster

- added logging
- ensure start/finish trigger action counters are incremented before latches 
are released
- replace arbitrary sleep calls with a trigger listener countdown latch
- increase all await() times: This means that 'real' failures (which should be 
rare and hopefully
  reproducible) will be 'slow', but the trade off will be less hard to 
reproduce 'false failures'
  due to thread contention on slow or heavily loaded (ie: jenkins) machines


> The new AutoScaling tests are way to flaky and need special attention.
> --
>
> Key: SOLR-12923
> URL: https://issues.apache.org/jira/browse/SOLR-12923
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Mark Miller
>Priority: Major
>
> I've already done some work here (not posted yet). We need to address this, 
> these tests are too new to fail so often and easily.
> I want to add beasting to precommit (LUCENE-8545) to help prevent tests that 
> fail so easily from being committed.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.ShardRoutingTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([B8AF8B02B5A1E087]:0)


FAILED:  org.apache.solr.cloud.ShardRoutingTest.test

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([B8AF8B02B5A1E087]:0)




Build Log:
[...truncated 15689 lines...]
   [junit4] Suite: org.apache.solr.cloud.ShardRoutingTest
   [junit4]   2> 1336005 INFO  
(SUITE-ShardRoutingTest-seed#[B8AF8B02B5A1E087]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.ShardRoutingTest_B8AF8B02B5A1E087-001/init-core-data-001
   [junit4]   2> 1336006 WARN  
(SUITE-ShardRoutingTest-seed#[B8AF8B02B5A1E087]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 1336006 INFO  
(SUITE-ShardRoutingTest-seed#[B8AF8B02B5A1E087]-worker) [] 
o.a.s.SolrTestCaseJ4 Using TrieFields (NUMERIC_POINTS_SYSPROP=false) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 1336007 INFO  
(SUITE-ShardRoutingTest-seed#[B8AF8B02B5A1E087]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1336008 INFO  
(SUITE-ShardRoutingTest-seed#[B8AF8B02B5A1E087]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/jq_mfo/gv
   [junit4]   2> 1336011 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1336012 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1336012 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 1336112 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer start zk server on port:41527
   [junit4]   2> 1336112 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:41527
   [junit4]   2> 1336112 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer connecting to 127.0.0.1 41527
   [junit4]   2> 1336117 INFO  (zkConnectionManagerCallback-7550-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1336119 INFO  (zkConnectionManagerCallback-7552-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 1336120 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 1336121 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 1336121 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 1336122 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 1336122 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 1336122 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 1336123 INFO  
(TEST-ShardRoutingTest.test-seed#[B8AF8B02B5A1E087]) [] 
o.a.s.c.ZkTestServer put 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml
 to /configs/conf1/enumsConfig.xml
   [junit4]   2> 1336123 INFO  

[jira] [Commented] (SOLR-13305) ZkClientClusterStateProvider Zookeeper timeout should be configurable

[Danny Shih (JIRA)]

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

Danny Shih commented on SOLR-13305:
---

We have increased the timeout and re-built the SOLRJ jar.  If that is 
sufficient, we could submit a patch.  However, it seems like this should be 
configurable.

> ZkClientClusterStateProvider Zookeeper timeout should be configurable
> -
>
> Key: SOLR-13305
> URL: https://issues.apache.org/jira/browse/SOLR-13305
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.4
>Reporter: Danny Shih
>Priority: Major
>
> This timeout is hardcoded to 1 ms.  It should be made configurable by 
> SOLR_WAIT_FOR_ZK.
> http://lucene.472066.n3.nabble.com/SOLR-zookeeper-connection-timeout-during-startup-is-hardcoded-to-1ms-td4403341.html#a4403671



--
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: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Nhat Nguyen]

+1 SUCCESS! [0:54:05.261238]

> On Mar 7, 2019, at 4:44 PM, Adrien Grand  wrote:
> 
> +1 SUCCESS! [1:25:54.239684]
> 
> On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi  wrote:
>> 
>> Please vote for release candidate 3 for Lucene/Solr 8.0.0
>> 
>> The artifacts can be downloaded from 
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>> You can run the smoke tester directly with this command:
>> python3 -u dev-tools/scripts/smokeTestRelease.py 
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>> 
>> Here’s my +1
>> SUCCESS! [1:14:08.843490]
> 
> 
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[JENKINS] Lucene-Solr-Tests-8.x - Build # 60 - Still Unstable

[Apache Jenkins Server]

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

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

Error Message:
 Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/7)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"collection1_shard1_replica_n1",   
"base_url":"http://127.0.0.1:38355/solr;,   
"node_name":"127.0.0.1:38355_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"collection1_shard1_replica_n2",   
"base_url":"http://127.0.0.1:38220/solr;,   
"node_name":"127.0.0.1:38220_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"} Live Nodes: [127.0.0.1:38220_solr, 127.0.0.1:38355_solr] 
Last available state: 
DocCollection(collection1//collections/collection1/state.json/7)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{"shard1":{   
"range":"8000-7fff",   "state":"active",   "replicas":{ 
"core_node3":{   "core":"collection1_shard1_replica_n1",   
"base_url":"http://127.0.0.1:38355/solr;,   
"node_name":"127.0.0.1:38355_solr",   "state":"down",   
"type":"NRT",   "force_set_state":"false"}, "core_node4":{  
 "core":"collection1_shard1_replica_n2",   
"base_url":"http://127.0.0.1:38220/solr;,   
"node_name":"127.0.0.1:38220_solr",   "state":"active",   
"type":"NRT",   "force_set_state":"false",   
"leader":"true",   "router":{"name":"compositeId"},   
"maxShardsPerNode":"2",   "autoAddReplicas":"false",   "nrtReplicas":"2",   
"tlogReplicas":"0"}

Stack Trace:
java.lang.AssertionError: 
Timeout waiting to see state for collection=collection1 
:DocCollection(collection1//collections/collection1/state.json/7)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"http://127.0.0.1:38355/solr;,
  "node_name":"127.0.0.1:38355_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"collection1_shard1_replica_n2",
  "base_url":"http://127.0.0.1:38220/solr;,
  "node_name":"127.0.0.1:38220_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
Live Nodes: [127.0.0.1:38220_solr, 127.0.0.1:38355_solr]
Last available state: 
DocCollection(collection1//collections/collection1/state.json/7)={
  "pullReplicas":"0",
  "replicationFactor":"2",
  "shards":{"shard1":{
  "range":"8000-7fff",
  "state":"active",
  "replicas":{
"core_node3":{
  "core":"collection1_shard1_replica_n1",
  "base_url":"http://127.0.0.1:38355/solr;,
  "node_name":"127.0.0.1:38355_solr",
  "state":"down",
  "type":"NRT",
  "force_set_state":"false"},
"core_node4":{
  "core":"collection1_shard1_replica_n2",
  "base_url":"http://127.0.0.1:38220/solr;,
  "node_name":"127.0.0.1:38220_solr",
  "state":"active",
  "type":"NRT",
  "force_set_state":"false",
  "leader":"true",
  "router":{"name":"compositeId"},
  "maxShardsPerNode":"2",
  "autoAddReplicas":"false",
  "nrtReplicas":"2",
  "tlogReplicas":"0"}
at 
__randomizedtesting.SeedInfo.seed([1C2B38848628A8B5:947F075E28D4C54D]:0)
at org.junit.Assert.fail(Assert.java:88)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:310)
at 
org.apache.solr.cloud.SolrCloudTestCase.waitForState(SolrCloudTestCase.java:288)
at 
org.apache.solr.cloud.TestCloudRecovery2.test(TestCloudRecovery2.java:61)
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 

Re: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Adrien Grand]

+1 SUCCESS! [1:25:54.239684]

On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi  wrote:
>
> Please vote for release candidate 3 for Lucene/Solr 8.0.0
>
> The artifacts can be downloaded from 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>
> Here’s my +1
> SUCCESS! [1:14:08.843490]



-- 
Adrien

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 5079 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5079/
Java: 64bit/jdk-9 -XX:+UseCompressedOops -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

Error Message:
Should be exactly one group with 1 entry of 10 for null for field intGSF 
expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: Should be exactly one group with 1 entry of 10 for 
null for field intGSF expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([D58FA9DAE994FFE8:4E34C782A4CCCDB6]: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.DocValuesNotIndexedTest.doGroupingDvOnly(DocValuesNotIndexedTest.java:395)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:321)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)

[jira] [Commented] (SOLR-13254) wrong log when reconnect to zk

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13254:


Commit c55415cda830f6ea65016c424977cdf16a93802b in lucene-solr's branch 
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c55415c ]

SOLR-13254: Correct message that is logged in solrj's ConnectionManager when an 
exception occurred while reconnecting to ZooKeeper. (hu xiaodong via Christine 
Poerschke)


> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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] [Resolved] (SOLR-13254) wrong log when reconnect to zk

[Christine Poerschke (JIRA)]

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

Christine Poerschke resolved SOLR-13254.

   Resolution: Fixed
Fix Version/s: 8.1
   master (9.0)

Thanks [~xiaodong.hu]!

> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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-13296) Example of Preanalyzed JSON in ref guide invalid

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13296:


Commit 48f2ddc4ff888a6b818180babb4d3f7187366cd9 in lucene-solr's branch 
refs/heads/branch_8_0 from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=48f2ddc ]

SOLR-13296 fix doc example so that it can be accepted by Solr
(previously caused error due to decreasing offsets)


> Example of Preanalyzed JSON in ref guide invalid
> 
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I 
> decided to first check that the config could successfully accept a chunk of 
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception 
> writing document id 1 to the index; possible analysis error: startOffset must 
> be non-negative, and endOffset must be >= startOffset, and offsets must not 
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field 
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a 
> patch to make the (mostly nonsensical) example at least technically valid



--
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-13305) ZkClientClusterStateProvider Zookeeper timeout should be configurable

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13305:
-

[~dshih] - are you able / planning to provide a patch/PR for this change?

> ZkClientClusterStateProvider Zookeeper timeout should be configurable
> -
>
> Key: SOLR-13305
> URL: https://issues.apache.org/jira/browse/SOLR-13305
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.4
>Reporter: Danny Shih
>Priority: Major
>
> This timeout is hardcoded to 1 ms.  It should be made configurable by 
> SOLR_WAIT_FOR_ZK.
> http://lucene.472066.n3.nabble.com/SOLR-zookeeper-connection-timeout-during-startup-is-hardcoded-to-1ms-td4403341.html#a4403671



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

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

[jira] [Updated] (SOLR-13305) ZkClientClusterStateProvider Zookeeper timeout should be configurable

[Kevin Risden (JIRA)]

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

Kevin Risden updated SOLR-13305:

Summary: ZkClientClusterStateProvider Zookeeper timeout should be 
configurable  (was: SOLR zookeeper timeout in ZkClientClusterStateProvider) 
should be configurable)

> ZkClientClusterStateProvider Zookeeper timeout should be configurable
> -
>
> Key: SOLR-13305
> URL: https://issues.apache.org/jira/browse/SOLR-13305
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 7.4
>Reporter: Danny Shih
>Priority: Major
>
> This timeout is hardcoded to 1 ms.  It should be made configurable by 
> SOLR_WAIT_FOR_ZK.
> http://lucene.472066.n3.nabble.com/SOLR-zookeeper-connection-timeout-during-startup-is-hardcoded-to-1ms-td4403341.html#a4403671



--
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-13254) wrong log when reconnect to zk

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13254:


Commit 683aa3d3e9b7e8d66b5be737dade3ffc0690c7c5 in lucene-solr's branch 
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=683aa3d ]

SOLR-13254: Correct message that is logged in solrj's ConnectionManager when an 
exception occurred while reconnecting to ZooKeeper. (hu xiaodong via Christine 
Poerschke)


> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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: Security Contact for Solr?

[Sven Blumenstein]

That was what I was looking for, I must have missed that page. Thank you!

> On 7 Mar 2019, at 21:29, Kevin Risden  wrote:
> 
> From [1] If you believe you have discovered a vulnerability in Lucene or 
> Solr, please follow these ASF guidelines [2] for reporting it.
> 
> [1] https://wiki.apache.org/solr/SolrSecurity 
> 
> [2] https://www.apache.org/security/ 
> 
> Kevin Risden
> 
> 
> On Thu, Mar 7, 2019 at 3:24 PM Sven Blumenstein  
> wrote:
> Hi .*,
> 
> what is the proper contact for reporting security vulnerabilities in Solr? Do 
> you have a security@ address or a non-public mailing list/bug component? 
> Unfortunately I could not find any information in that regard on the Solr 
> website, hence my reach out to this mailing list.
> 
> Thanks! 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

[jira] [Comment Edited] (SOLR-13297) StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-13297 at 3/7/19 8:55 PM:
-

Found one reproducing seed for HdfsUnloadDistributedZkTest so far:

ant test -Dtestcase=HdfsUnloadDistributedZkTest -Dtests.seed=B3481DA6733BF9BC 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.asserts=true


was (Author: risdenk):
Found one reproducing seed for HdfsUnloadDistributedZkTest so far:

ant test  -Dtestcase=HdfsUnloadDistributedZkTest -Dtests.method=test 
-Dtests.seed=B3481DA6733BF9BC -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=de-LU -Dtests.timezone=Europe/Bratislava 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

> StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3
> -
>
> Key: SOLR-13297
> URL: https://issues.apache.org/jira/browse/SOLR-13297
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: builds.a.o_solr_badapple_nightly_8x_7.txt.gz, 
> builds.a.o_solr_badapple_nightly_master_51.txt.gz, 
> builds.a.o_solr_nightly_8x_36.txt.gz, builds.a.o_solr_repro_2965.txt.gz
>
>
> As reported by [~hossman] on SOLR-9515, StressHdfsTest and 
> HdfsUnloadDistributedZkTest are failing more regularly. Should figure out 
> what is going on here.



--
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] [Comment Edited] (SOLR-13297) StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-13297 at 3/7/19 8:51 PM:
-

Found one reproducing seed for StressHdfsTest so far:

ant test -Dtestcase=StressHdfsTest -Dtests.seed=7CEDDB984CC02F13 
-Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true 
-Dtests.asserts=true


was (Author: risdenk):
Found one reproducing seed for StressHdfsTest so far:

ant test  -Dtestcase=StressHdfsTest -Dtests.method=test 
-Dtests.seed=7CEDDB984CC02F13 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-TW 
-Dtests.timezone=Africa/Libreville -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

> StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3
> -
>
> Key: SOLR-13297
> URL: https://issues.apache.org/jira/browse/SOLR-13297
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: builds.a.o_solr_badapple_nightly_8x_7.txt.gz, 
> builds.a.o_solr_badapple_nightly_master_51.txt.gz, 
> builds.a.o_solr_nightly_8x_36.txt.gz, builds.a.o_solr_repro_2965.txt.gz
>
>
> As reported by [~hossman] on SOLR-9515, StressHdfsTest and 
> HdfsUnloadDistributedZkTest are failing more regularly. Should figure out 
> what is going on here.



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

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

[jira] [Updated] (SOLR-13303) WrappedLongValuesSource should always return `true` for advanceExact

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-13303:

Fix Version/s: (was: 8.0)

> WrappedLongValuesSource should always return `true` for advanceExact
> 
>
> Key: SOLR-13303
> URL: https://issues.apache.org/jira/browse/SOLR-13303
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0
>Reporter: Andrzej Wislowski
>Priority: Major
> Attachments: SOLR-13303.patch
>
>
> Following 
> https://issues.apache.org/jira/browse/SOLR-13126?focusedCommentId=16786635=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16786635
> WrappedLongValuesSource exposes an iterator and expects to jump over missing 
> documents, while VS has an exists() method but still returns a value even if 
> exists() is false.  The wrapper code to convert VS to WrappedLongValuesSource 
> checks whether or not the value exists, but instead it should always return 
> `true`.
> This change is similar to the one made to WrappedLongValuesSource in  
> https://issues.apache.org/jira/browse/SOLR-13126
>  
>  



--
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: Security Contact for Solr?

[Christine Poerschke (BLOOMBERG/ LONDON)]

Thanks for your question Sven!

I wonder if/how we could make the two links Kevin shared more discoverable from 
the Solr website, something on the Community [3] page perhaps somehow?

[3] http://lucene.apache.org/solr/community.html

From: dev@lucene.apache.org At: 03/07/19 20:29:18To:  dev@lucene.apache.org
Subject: Re: Security Contact for Solr?

From [1] If you believe you have discovered a vulnerability in Lucene or Solr, 
please follow these ASF guidelines [2] for reporting it.

[1] https://wiki.apache.org/solr/SolrSecurity
[2] https://www.apache.org/security/

Kevin Risden

On Thu, Mar 7, 2019 at 3:24 PM Sven Blumenstein  wrote:

Hi .*,

what is the proper contact for reporting security vulnerabilities in Solr? Do 
you have a security@ address or a non-public mailing list/bug component? 
Unfortunately I could not find any information in that regard on the Solr 
website, hence my reach out to this mailing list.

Thanks! 


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

Re: Security Contact for Solr?

[Kevin Risden]

>From [1] If you believe you have discovered a vulnerability in Lucene or
Solr, please follow these ASF guidelines [2] for reporting it.

[1] https://wiki.apache.org/solr/SolrSecurity
[2] https://www.apache.org/security/

Kevin Risden


On Thu, Mar 7, 2019 at 3:24 PM Sven Blumenstein 
wrote:

> Hi .*,
>
> what is the proper contact for reporting security vulnerabilities in Solr?
> Do you have a security@ address or a non-public mailing list/bug
> component? Unfortunately I could not find any information in that regard on
> the Solr website, hence my reach out to this mailing list.
>
> Thanks!
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Security Contact for Solr?

[Sven Blumenstein]

Hi .*,

what is the proper contact for reporting security vulnerabilities in Solr? Do 
you have a security@ address or a non-public mailing list/bug component? 
Unfortunately I could not find any information in that regard on the Solr 
website, hence my reach out to this mailing list.

Thanks! 


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

[jira] [Assigned] (SOLR-13254) wrong log when reconnect to zk

[Christine Poerschke (JIRA)]

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

Christine Poerschke reassigned SOLR-13254:
--

Assignee: Christine Poerschke

> wrong log when reconnect to zk
> --
>
> Key: SOLR-13254
> URL: https://issues.apache.org/jira/browse/SOLR-13254
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.7
>Reporter: hu xiaodong
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-13254.patch
>
>
> When exception occurred while reconnecting to zk, it is clear that it waits 
> for 5 seconds and retry, but the log does recorded 1 second.



--
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-8599) Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent state

[Christine Poerschke (JIRA)]

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

Christine Poerschke commented on SOLR-8599:
---

bq. ... maybe fix it in another Jira ...

SOLR-13254 has a fix.

> Errors in construction of SolrZooKeeper cause Solr to go into an inconsistent 
> state
> ---
>
> Key: SOLR-8599
> URL: https://issues.apache.org/jira/browse/SOLR-8599
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Reporter: Keith Laban
>Assignee: Dennis Gove
>Priority: Major
> Fix For: 5.5.1, 6.0
>
> Attachments: SOLR-8599.patch, SOLR-8599.patch, SOLR-8599.patch, 
> SOLR-8599.patch
>
>
> We originally saw this happen due to a DNS exception (see stack trace below). 
> Although any exception thrown in the constructor of SolrZooKeeper or the 
> parent class, ZooKeeper, will cause DefaultConnectionStrategy to fail to 
> update the zookeeper client. Once it gets into this state, it will not try to 
> connect again until the process is restarted. The node itself will also 
> respond successfully to query requests, but not to update requests.
> Two things should be address here:
> 1) Fix the error handling and issue some number of retries
> 2) If we are stuck in a state like this stop responding to all requests 
> {code}
> 2016-01-23 13:49:20.222 ERROR ConnectionManager [main-EventThread] - 
> :java.net.UnknownHostException: HOSTNAME: unknown error
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$2.lookupAllHostAddr(InetAddress.java:928)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1323)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1276)
> at java.net.InetAddress.getAllByName(InetAddress.java:1192)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at 
> org.apache.zookeeper.client.StaticHostProvider.(StaticHostProvider.java:61)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:445)
> at org.apache.zookeeper.ZooKeeper.(ZooKeeper.java:380)
> at org.apache.solr.common.cloud.SolrZooKeeper.(SolrZooKeeper.java:41)
> at 
> org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:53)
> at 
> org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:132)
> at 
> org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:522)
> at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:498)
> 2016-01-23 13:49:20.222 INFO ConnectionManager [main-EventThread] - 
> Connected:false
> 2016-01-23 13:49:20.222 INFO ClientCnxn [main-EventThread] - EventThread shut 
> down
> {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-13306) Add a request parameter to execute a streaming expression locally

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13306:
-

Initial patch as food for thought attached

> Add a request parameter to execute a streaming expression locally
> -
>
> Key: SOLR-13306
> URL: https://issues.apache.org/jira/browse/SOLR-13306
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
> Attachments: SOLR-13306.patch
>
>
> In some cases it is known (due to routing configuration) that all documents 
> required for a streaming expression are co-located on the same server. In 
> this case it is inefficient to send JSON over the wire, and it would be more 
> efficient to issue the same expression to N servers, thereby saving transport 
> and merge costs. Details, Patch and example to follow



--
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-13306) Add a request parameter to execute a streaming expression locally

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13306:
-

A specific example of this is the de-normalization of two documents into a 
single document using a join followed by an update expression. When the join 
key has a 1-1 relationship with the routable section of the id used for 
routing, then both parent and child documents are available localy, and 
co-locating the denormalized form output by the update may be desirable as 
well. 

Also of interest would be any steps to avoid needless conversion to and 
re-parsing from JSON (I'm still trying to determine if this is happening with 
the patch I'm about to attach). In the specific case of an expression that ends 
in an update it would be ideal if only the output from update listing the batch 
sizes were serialized to JSON.


> Add a request parameter to execute a streaming expression locally
> -
>
> Key: SOLR-13306
> URL: https://issues.apache.org/jira/browse/SOLR-13306
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
>
> In some cases it is known (due to routing configuration) that all documents 
> required for a streaming expression are co-located on the same server. In 
> this case it is inefficient to send JSON over the wire, and it would be more 
> efficient to issue the same expression to N servers, thereby saving transport 
> and merge costs. Details, Patch and example to follow



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

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

[jira] [Updated] (SOLR-13306) Add a request parameter to execute a streaming expression locally

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13306:

Attachment: SOLR-13306.patch

> Add a request parameter to execute a streaming expression locally
> -
>
> Key: SOLR-13306
> URL: https://issues.apache.org/jira/browse/SOLR-13306
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 8.0
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
> Attachments: SOLR-13306.patch
>
>
> In some cases it is known (due to routing configuration) that all documents 
> required for a streaming expression are co-located on the same server. In 
> this case it is inefficient to send JSON over the wire, and it would be more 
> efficient to issue the same expression to N servers, thereby saving transport 
> and merge costs. Details, Patch and example to follow



--
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-repro - Build # 2988 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-repro/2988/

[...truncated 41 lines...]
[repro] Jenkins log URL: 
https://builds.apache.org/job/Lucene-Solr-Tests-8.x/59/consoleText

[repro] Revision: bb5b7f08b1b3bb22b0cb8549c446abe7e3a4f3ca

[repro] Repro line:  ant test  -Dtestcase=TestTestInjection 
-Dtests.seed=86F49CF0B9DEB6E8 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-ME -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[repro] git rev-parse --abbrev-ref HEAD
[repro] git rev-parse HEAD
[repro] Initial local git branch/revision: 
1e09268e781039b62e856cc696aba0e519079bbc
[repro] git fetch
[repro] git checkout bb5b7f08b1b3bb22b0cb8549c446abe7e3a4f3ca

[...truncated 2 lines...]
[repro] git merge --ff-only

[...truncated 1 lines...]
[repro] ant clean

[...truncated 6 lines...]
[repro] Test suites by module:
[repro]solr/core
[repro]   TestTestInjection
[repro] ant compile-test

[...truncated 3575 lines...]
[repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 
-Dtests.class="*.TestTestInjection" -Dtests.showOutput=onerror  
-Dtests.seed=86F49CF0B9DEB6E8 -Dtests.multiplier=2 -Dtests.slow=true 
-Dtests.locale=sr-ME -Dtests.timezone=Etc/GMT-8 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII

[...truncated 364 lines...]
[repro] Setting last failure code to 256

[repro] Failures:
[repro]   3/5 failed: org.apache.solr.util.TestTestInjection
[repro] git checkout 1e09268e781039b62e856cc696aba0e519079bbc

[...truncated 2 lines...]
[repro] Exiting with code 256

[...truncated 5 lines...]

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

[jira] [Created] (SOLR-13306) Add a request parameter to execute a streaming expression locally

[Gus Heck (JIRA)]

Gus Heck created SOLR-13306:
---

 Summary: Add a request parameter to execute a streaming expression 
locally
 Key: SOLR-13306
 URL: https://issues.apache.org/jira/browse/SOLR-13306
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Affects Versions: 8.0
Reporter: Gus Heck
Assignee: Gus Heck


In some cases it is known (due to routing configuration) that all documents 
required for a streaming expression are co-located on the same server. In this 
case it is inefficient to send JSON over the wire, and it would be more 
efficient to issue the same expression to N servers, thereby saving transport 
and merge costs. Details, Patch and example to follow





--
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-13305) SOLR zookeeper timeout in ZkClientClusterStateProvider) should be configurable

[Danny Shih (JIRA)]

Danny Shih created SOLR-13305:
-

 Summary: SOLR zookeeper timeout in ZkClientClusterStateProvider) 
should be configurable
 Key: SOLR-13305
 URL: https://issues.apache.org/jira/browse/SOLR-13305
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrJ
Affects Versions: 7.4
Reporter: Danny Shih


This timeout is hardcoded to 1 ms.  It should be made configurable by 
SOLR_WAIT_FOR_ZK.

http://lucene.472066.n3.nabble.com/SOLR-zookeeper-connection-timeout-during-startup-is-hardcoded-to-1ms-td4403341.html#a4403671



--
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: VOTE: Release Apache Solr Ref Guide for 7.7

[Anshum Gupta]

+1

Thanks for doing this, Jason!

  Anshum


> On Mar 4, 2019, at 7:28 AM, Jason Gerlowski  wrote:
> 
> Please vote to release the Solr Ref Guide for 7.7.
> 
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/
> 
> $ cat apache-solr-ref-guide-7.7.pdf.sha512
> a4a89cf56c90a2f05874e4770726cf3635bbbde3c8e7dace92b51bd01e08d486754de06f753c0c1a6d7fab63068898e991d9bfeb024e945b2f898cce18ee8d3d
> apache-solr-ref-guide-7.7.pdf
> 
> 
> The PDF is up to 1431 pages!
> 
> The online version is available at: http://lucene.apache.org/solr/guide/7_7/
> 
> Here's my +1.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: VOTE: Release Apache Solr Ref Guide for 7.7

[Jason Gerlowski]

Still looking for one more vote to finish (or respin) the release.
Please take a look if you can find the time!

On Wed, Mar 6, 2019 at 3:34 PM Cassandra Targett  wrote:
>
> +1. Thanks Jason for running this release.
>
> Cassandra
> On Mar 4, 2019, 9:29 AM -0600, Jason Gerlowski , 
> wrote:
>
> Please vote to release the Solr Ref Guide for 7.7.
>
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/
>
> $ cat apache-solr-ref-guide-7.7.pdf.sha512
> a4a89cf56c90a2f05874e4770726cf3635bbbde3c8e7dace92b51bd01e08d486754de06f753c0c1a6d7fab63068898e991d9bfeb024e945b2f898cce18ee8d3d
> apache-solr-ref-guide-7.7.pdf
>
>
> The PDF is up to 1431 pages!
>
> The online version is available at: http://lucene.apache.org/solr/guide/7_7/
>
> Here's my +1.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Adrien Grand]

It's not clear whether you are only asking for a backport or also for a respin.

I'm reluctant to respin: we built the first release candidate more
than 3 week ago now and have had to postpone it since then because of
late bugs. This is asking too much to the release manager in my
opinion. I am +1 to backport this change so that it makes it to 8.0.1,
or 8.0 if we decide to respin for another bug, but I think it's time
to raise the bar in terms of what bugs should be considered blockers
for 8.0.


On Thu, Mar 7, 2019 at 7:51 PM Noble Paul  wrote:
>
> I would like to backport SOLR-13285
>
> On Fri, Mar 8, 2019 at 3:53 AM jim ferenczi  wrote:
> >
> > Please vote for release candidate 3 for Lucene/Solr 8.0.0
> >
> > The artifacts can be downloaded from 
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> > You can run the smoke tester directly with this command:
> > python3 -u dev-tools/scripts/smokeTestRelease.py 
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> >
> > Here’s my +1
> > SUCCESS! [1:14:08.843490]
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


--
Adrien

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

[jira] [Resolved] (SOLR-13261) Make SortableTextField work with export/streaming

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-13261.
---
Resolution: Fixed

Latest patch addresses Hoss' concerns, so closing.

> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13261-UseDocValuesAsStored.patch, SOLR-13261.patch, 
> SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



--
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-13261) Make SortableTextField work with export/streaming

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13261:


Commit fc76b70bda9391e4a048de89db49a5921643 in lucene-solr's branch 
refs/heads/branch_8x from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fc76b70 ]

SOLR-13261: Make SortableTextField work with export/streaming, now requires 
useDocValuesAsStored='true'

(cherry picked from commit 1e09268e781039b62e856cc696aba0e519079bbc)


> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13261-UseDocValuesAsStored.patch, SOLR-13261.patch, 
> SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



--
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-13297) StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13297:
-

Found one reproducing seed for StressHdfsTest so far:

ant test  -Dtestcase=StressHdfsTest -Dtests.method=test 
-Dtests.seed=7CEDDB984CC02F13 -Dtests.multiplier=2 -Dtests.nightly=true 
-Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-TW 
-Dtests.timezone=Africa/Libreville -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

> StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3
> -
>
> Key: SOLR-13297
> URL: https://issues.apache.org/jira/browse/SOLR-13297
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: builds.a.o_solr_badapple_nightly_8x_7.txt.gz, 
> builds.a.o_solr_badapple_nightly_master_51.txt.gz, 
> builds.a.o_solr_nightly_8x_36.txt.gz, builds.a.o_solr_repro_2965.txt.gz
>
>
> As reported by [~hossman] on SOLR-9515, StressHdfsTest and 
> HdfsUnloadDistributedZkTest are failing more regularly. Should figure out 
> what is going on here.



--
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] [Comment Edited] (SOLR-13297) StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3

[Kevin Risden (JIRA)]

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

Kevin Risden edited comment on SOLR-13297 at 3/7/19 7:01 PM:
-

Found one reproducing seed for HdfsUnloadDistributedZkTest so far:

ant test  -Dtestcase=HdfsUnloadDistributedZkTest -Dtests.method=test 
-Dtests.seed=B3481DA6733BF9BC -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=de-LU -Dtests.timezone=Europe/Bratislava 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8


was (Author: risdenk):
Found one reproducing seed so far:

ant test  -Dtestcase=HdfsUnloadDistributedZkTest -Dtests.method=test 
-Dtests.seed=B3481DA6733BF9BC -Dtests.nightly=true -Dtests.slow=true 
-Dtests.badapples=true -Dtests.locale=de-LU -Dtests.timezone=Europe/Bratislava 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8

> StressHdfsTest and HdfsUnloadDistributedZkTest fail more often after Hadoop 3
> -
>
> Key: SOLR-13297
> URL: https://issues.apache.org/jira/browse/SOLR-13297
> Project: Solr
>  Issue Type: Test
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: builds.a.o_solr_badapple_nightly_8x_7.txt.gz, 
> builds.a.o_solr_badapple_nightly_master_51.txt.gz, 
> builds.a.o_solr_nightly_8x_36.txt.gz, builds.a.o_solr_repro_2965.txt.gz
>
>
> As reported by [~hossman] on SOLR-9515, StressHdfsTest and 
> HdfsUnloadDistributedZkTest are failing more regularly. Should figure out 
> what is going on here.



--
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-13261) Make SortableTextField work with export/streaming

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13261:


Commit 1e09268e781039b62e856cc696aba0e519079bbc in lucene-solr's branch 
refs/heads/master from Erick Erickson
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1e09268 ]

SOLR-13261: Make SortableTextField work with export/streaming, now requires 
useDocValuesAsStored='true'


> Make SortableTextField work with export/streaming
> -
>
> Key: SOLR-13261
> URL: https://issues.apache.org/jira/browse/SOLR-13261
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.7, 8.0, master (9.0)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13261-UseDocValuesAsStored.patch, SOLR-13261.patch, 
> SOLR-13261.patch
>
>
> ExportWriter (and perhaps other places) explicitly tests for certain field 
> types and error out with "Export fields must either be one of the following 
> types: int,float,long,double,string,date,boolean"
> It seems perfectly legal to export SortableTextField as well as it's a DV 
> field. How desirable that would be is an open question.



--
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-13248) Autoscaling based replica placement is broken out of the box

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-13248:
---

Can this be closed now? It's kinda scary to see it "unresolved"

> Autoscaling based replica placement is broken out of the box
> 
>
> Key: SOLR-13248
> URL: https://issues.apache.org/jira/browse/SOLR-13248
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.6, 7.7
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13248-branch7x-backport.patch, 
> SOLR-13248-withDefaultCollectionProp.patch, SOLR-13248.patch, 
> SOLR-13248.patch, SOLR-13248.patch
>
>
> SOLR-12739 made autoscaling as the default replica placement strategy. 
> However in the absence of SOLR-12845, replicas can be placed without any 
> regards for maxShardsPerNode causing multiple replicas of the same shard to 
> be placed on the same node together. Also it was reported in SOLR-13247 that 
> createNodeSet is not being respected as well.
> SOLR-13159 was an early signal of the problem but it was not reproducible and 
> there was a DNS problem in the cluster too so the root cause was not clear 
> then.
> I am creating this blocker issue because as it stands today, we cannot 
> guarantee the layout of new collections. At a minimum, we should revert to 
> using the legacy replica assignment policy or add default policies with 
> SOLR-12845 and have createNodeSet work. Related but not mandatory would be to 
> fix SOLR-12847 as well.



--
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-13248) Autoscaling based replica placement is broken out of the box

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-13248:
-

Sure, done. Thanks.

> Autoscaling based replica placement is broken out of the box
> 
>
> Key: SOLR-13248
> URL: https://issues.apache.org/jira/browse/SOLR-13248
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.6, 7.7
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: 8.0, master (9.0), 7.7.1
>
> Attachments: SOLR-13248-branch7x-backport.patch, 
> SOLR-13248-withDefaultCollectionProp.patch, SOLR-13248.patch, 
> SOLR-13248.patch, SOLR-13248.patch
>
>
> SOLR-12739 made autoscaling as the default replica placement strategy. 
> However in the absence of SOLR-12845, replicas can be placed without any 
> regards for maxShardsPerNode causing multiple replicas of the same shard to 
> be placed on the same node together. Also it was reported in SOLR-13247 that 
> createNodeSet is not being respected as well.
> SOLR-13159 was an early signal of the problem but it was not reproducible and 
> there was a DNS problem in the cluster too so the root cause was not clear 
> then.
> I am creating this blocker issue because as it stands today, we cannot 
> guarantee the layout of new collections. At a minimum, we should revert to 
> using the legacy replica assignment policy or add default policies with 
> SOLR-12845 and have createNodeSet work. Related but not mandatory would be to 
> fix SOLR-12847 as well.



--
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] [Resolved] (SOLR-13248) Autoscaling based replica placement is broken out of the box

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya resolved SOLR-13248.
-
   Resolution: Fixed
Fix Version/s: 7.7.1

> Autoscaling based replica placement is broken out of the box
> 
>
> Key: SOLR-13248
> URL: https://issues.apache.org/jira/browse/SOLR-13248
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Affects Versions: 7.6, 7.7
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Blocker
> Fix For: 8.0, master (9.0), 7.7.1
>
> Attachments: SOLR-13248-branch7x-backport.patch, 
> SOLR-13248-withDefaultCollectionProp.patch, SOLR-13248.patch, 
> SOLR-13248.patch, SOLR-13248.patch
>
>
> SOLR-12739 made autoscaling as the default replica placement strategy. 
> However in the absence of SOLR-12845, replicas can be placed without any 
> regards for maxShardsPerNode causing multiple replicas of the same shard to 
> be placed on the same node together. Also it was reported in SOLR-13247 that 
> createNodeSet is not being respected as well.
> SOLR-13159 was an early signal of the problem but it was not reproducible and 
> there was a DNS problem in the cluster too so the root cause was not clear 
> then.
> I am creating this blocker issue because as it stands today, we cannot 
> guarantee the layout of new collections. At a minimum, we should revert to 
> using the legacy replica assignment policy or add default policies with 
> SOLR-12845 and have createNodeSet work. Related but not mandatory would be to 
> fix SOLR-12847 as well.



--
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: [VOTE] Release Lucene/Solr 8.0.0 RC3

[Noble Paul]

I would like to backport SOLR-13285

On Fri, Mar 8, 2019 at 3:53 AM jim ferenczi  wrote:
>
> Please vote for release candidate 3 for Lucene/Solr 8.0.0
>
> The artifacts can be downloaded from 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
> You can run the smoke tester directly with this command:
> python3 -u dev-tools/scripts/smokeTestRelease.py 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
>
> Here’s my +1
> SUCCESS! [1:14:08.843490]



-- 
-
Noble Paul

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

[jira] [Resolved] (SOLR-13301) [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-13301.
--
Resolution: Information Provided

> [CVE-2019-0192] Deserialization of untrusted data via jmx.serviceUrl
> 
>
> Key: SOLR-13301
> URL: https://issues.apache.org/jira/browse/SOLR-13301
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: config-api
>Affects Versions: 5.0, 5.1, 5.2, 5.2.1, 5.3, 5.3.1, 5.3.2, 5.4, 5.4.1, 
> 5.5, 5.5.1, 5.5.2, 5.5.3, 5.5.4, 5.5.5, 6.0, 6.0.1, 6.1, 6.1.1, 6.2, 6.2.1, 
> 6.3, 6.4, 6.4.1, 6.4.2, 6.5, 6.5.1, 6.6, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5
>Reporter: Tomás Fernández Löbbe
>Priority: Critical
> Fix For: 7.0
>
> Attachments: SOLR-13301.patch
>
>
> From the vulnerability reporter:
> {quote}ConfigAPI allows to set a jmx.serviceUrl that will create a new 
> [JMXConnectorServerFactory|https://docs.oracle.com/javase/7/docs/api/javax/management/remote/JMXConnectorServerFactory.html]
>  and trigger a call with 'bind' operation to a target RMI/LDAP server. A 
> malicious RMI server could respond with arbitrary object that will be 
> deserialized on the Solr side using java's ObjectInputStream, which is 
> considered unsafe. This type of vulnerabilities can be exploited with 
> ysoserial tool. Depending on the target classpath, an attacker can use one of 
> the "gadget chains" to trigger Remote Code Execution on the Solr side.
> {quote}
> Mitigation:
>  Any of the following are enough to prevent this vulnerability:
>  * Upgrade to Apache Solr 7.0 or later.
>  * Disable the ConfigAPI if not in use, by running Solr with the system 
> property {{disable.configEdit=true}}
>  * If upgrading or disabling the Config API are not viable options, apply 
> [^SOLR-13301.patch] and re-compile Solr.
>  * Ensure your network settings are configured so that only trusted traffic 
> is allowed to ingress/egress your hosts running Solr.
> Since Solr 7.0, JMX server is no longer configurable via API



--
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: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Noble Paul]

I would like to back port SOLR-13285 also . It seems to affect a few people

On Fri, Mar 8, 2019 at 5:36 AM Uwe Schindler  wrote:
>
> Hi
>
>
>
> Thanks for the clarification, that’s exactly how I understood that. The 
> “solr.http1” flag is just there to make new nodes use HTTP/1.1 to talk to 
> others temporarily, as this is the common protocol all nodes understand 
> during a rolling upgrade. The new nodes understand HTTP/2 always, regarless 
> of this flag.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Đạt Cao Mạnh 
> Sent: Thursday, March 7, 2019 6:47 PM
> To: Solr/Lucene Dev 
> Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> For clarification:
>
> But this does not disable the HTTP/2 listener, it just makes SolrJ no longer 
> use the Http2SolrClient and fall back to the old one.
>
> This is true and it is not a bug. The reason here is for rolling updates, 
> since -Dsolr.http1=true nodes can send and accept requests to/from Solr 7.x 
> and Solr 8 without that flag. As I mentioned in CHANGES.txt for rolling 
> updates
>
> Step 1. Some nodes wil be upgraded to Solr 8 with -Dsolr.http1=true, the rest 
> will still remain on Solr 7.x. They can communicate to each others since only 
> HTTP/1 is used
>
> Step 2. All nodes get upgraded to Solr 8 with -Dsolr.http1=true.
>
> Step 3. Some nodes with -Dsolr.http1=true (A) and the rest (B) without that 
> flag. A will talk with B using HTTP/1 (possible) and B will talk with A using 
> HTTP/2 (since HTTP/2 listener is enabled in -Dsolr.http1=true nodes)
>
> Step 4: All nodes get upgraded to Solr 8 without solr.http1 flag. They will 
> talk with each other using HTTP/2 now.
>
>
>
> On Thu, Mar 7, 2019 at 4:32 PM Uwe Schindler  wrote:
>
> Thanks for the reminder,
>
>
>
> I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the 
> startup script. But this does not disable the HTTP/2 listener, it just makes 
> SolrJ no longer use the Http2SolrClient and fall back to the old one. But 
> that only affects the “new” solr servers as a “client” to old servers during 
> rolling upgrade.
>
>
>
> I did a quick check, if the parameter makes its way to solr: yes, after 
> starting solr with “-Dsolr.http1=true”:
>
> C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true
>
> … it showed the parameter in admin UI under system properties.
>
>
>
> But I did not test a full cluster in the short time. The HTTP/2 endpoint of 
> the started server was still available, but outgoing solr requests should 
> only go with HTTP1 then. I am sure somebody tested this in Linux, Windows is 
> same as the system property reached the JVM, so startup scripts handle it 
> right.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Alan Woodward 
> Sent: Thursday, March 7, 2019 9:17 AM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> Is there a way of passing Jetty parameters from the command line?  IOW, can 
> Windows users do a rolling upgrade if they run ./solr restart 
> -Djetty.module=http or whatever?
>
>
>
> On 6 Mar 2019, at 21:57, Uwe Schindler  wrote:
>
>
>
> I opened a blocker issue:
>
> https://issues.apache.org/jira/browse/SOLR-13299
>
>
>
> The fix is easy, will commit it soon to all 3 branches.
>
>
>
> IMHO, we should respin as non-working startup script on Windows for users of 
> secured Solr servers is a blocker.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: Uwe Schindler 
> Sent: Wednesday, March 6, 2019 8:52 PM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> It looks like on Linux the Solr start script correctly sets module in jetty, 
> so it disables http2 on Java 8. I have not tested this but it looks like on 
> Windows the if statement is missing.
>
> If we cannot fix this soon we may release a Bugfix Version later, but this 
> would prevent Windows users from upgrading.
>
> So I switch to +/-0 to release. What do others think?
>
> I will try to fix startup script later, maybe it's easy.
>
> Uwe
>
> Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler :
>
> Hi,
>
>
>
> I also checked the RC2. First automated smoke testing with Policeman Jenkins 
> resulted in a +1 from Policeman Jenkins:
>
>
>
> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console
>
> SUCCESS! [2:42:28.295475]
>
>
>
> The testing was done with Java 8 and Java 9 (this is why it took longer).
>
>
>
> I also checked Changes.txt, looks fine (there is only a few typos in the 
> changes about the switch of Solr to HTTP/2, but that’s not horrible, but we 
> should improve it, as its one significant change): latter -> later
>
>
>
> I also checked the ZIP files of Lucene and Solr. Lucene looks as 

RE: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Uwe Schindler]

Hi

 

Thanks for the clarification, that’s exactly how I understood that. The 
“solr.http1” flag is just there to make new nodes use HTTP/1.1 to talk to 
others temporarily, as this is the common protocol all nodes understand during 
a rolling upgrade. The new nodes understand HTTP/2 always, regarless of this 
flag.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Đạt Cao Mạnh  
Sent: Thursday, March 7, 2019 6:47 PM
To: Solr/Lucene Dev 
Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

For clarification: 

But this does not disable the HTTP/2 listener, it just makes SolrJ no longer 
use the Http2SolrClient and fall back to the old one.

This is true and it is not a bug. The reason here is for rolling updates, since 
-Dsolr.http1=true nodes can send and accept requests to/from Solr 7.x and Solr 
8 without that flag. As I mentioned in CHANGES.txt for rolling updates

Step 1. Some nodes wil be upgraded to Solr 8 with -Dsolr.http1=true, the rest 
will still remain on Solr 7.x. They can communicate to each others since only 
HTTP/1 is used

Step 2. All nodes get upgraded to Solr 8 with -Dsolr.http1=true.

Step 3. Some nodes with -Dsolr.http1=true (A) and the rest (B) without that 
flag. A will talk with B using HTTP/1 (possible) and B will talk with A using 
HTTP/2 (since HTTP/2 listener is enabled in -Dsolr.http1=true nodes)

Step 4: All nodes get upgraded to Solr 8 without solr.http1 flag. They will 
talk with each other using HTTP/2 now.

 

On Thu, Mar 7, 2019 at 4:32 PM Uwe Schindler mailto:u...@thetaphi.de> > wrote:

Thanks for the reminder,

 

I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the 
startup script. But this does not disable the HTTP/2 listener, it just makes 
SolrJ no longer use the Http2SolrClient and fall back to the old one. But that 
only affects the “new” solr servers as a “client” to old servers during rolling 
upgrade.

 

I did a quick check, if the parameter makes its way to solr: yes, after 
starting solr with “-Dsolr.http1=true”:

C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true

… it showed the parameter in admin UI under system properties.

 

But I did not test a full cluster in the short time. The HTTP/2 endpoint of the 
started server was still available, but outgoing solr requests should only go 
with HTTP1 then. I am sure somebody tested this in Linux, Windows is same as 
the system property reached the JVM, so startup scripts handle it right.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Alan Woodward mailto:romseyg...@gmail.com> > 
Sent: Thursday, March 7, 2019 9:17 AM
To: dev@lucene.apache.org  
Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

Is there a way of passing Jetty parameters from the command line?  IOW, can 
Windows users do a rolling upgrade if they run ./solr restart 
-Djetty.module=http or whatever?

 

On 6 Mar 2019, at 21:57, Uwe Schindler <  
u...@thetaphi.de> wrote:

 

I opened a blocker issue:

  
https://issues.apache.org/jira/browse/SOLR-13299

 

The fix is easy, will commit it soon to all 3 branches.

 

IMHO, we should respin as non-working startup script on Windows for users of 
secured Solr servers is a blocker.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  http://www.thetaphi.de

eMail:   u...@thetaphi.de

 

From: Uwe Schindler <  u...@thetaphi.de> 
Sent: Wednesday, March 6, 2019 8:52 PM
To:   dev@lucene.apache.org
Subject: RE: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

It looks like on Linux the Solr start script correctly sets module in jetty, so 
it disables http2 on Java 8. I have not tested this but it looks like on 
Windows the if statement is missing.

If we cannot fix this soon we may release a Bugfix Version later, but this 
would prevent Windows users from upgrading.

So I switch to +/-0 to release. What do others think?

I will try to fix startup script later, maybe it's easy.

Uwe

Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler < 
 u...@thetaphi.de>:

Hi,

 

I also checked the RC2. First automated smoke testing with Policeman Jenkins 
resulted in a +1 from Policeman Jenkins:

 

  
https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console

SUCCESS! [2:42:28.295475]

 

The testing was done with Java 8 and Java 9 (this is why it took longer).

 

I also checked Changes.txt, looks fine (there is only a few typos in the 
changes about the switch of Solr to HTTP/2, but that’s not horrible, but we 
should improve it, as 

[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 40 - Still Unstable

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.OverseerTest.testOverseerFailure

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([95FF74B2CEEB]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([95FF74B2CEEB]:0)




Build Log:
[...truncated 15669 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-BadApples-Tests-8.x/solr/build/solr-core/test/J1/temp/solr.cloud.OverseerTest_95FF74B2CEEB-001/init-core-data-001
   [junit4]   2> 2042663 WARN  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
startTrackingSearchers: numOpens=21 numCloses=21
   [junit4]   2> 2042663 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 2042665 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
Randomized ssl (false) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 2042665 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
SecureRandom sanity checks: test.solr.allowed.securerandom=null & 
java.security.egd=file:/dev/./urandom
   [junit4]   2> 2042665 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.c.ZkTestServer 
STARTING ZK TEST SERVER
   [junit4]   2> 2042672 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 2042672 INFO  (ZkTestServer Run Thread) [] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 2042772 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.c.ZkTestServer 
start zk server on port:36057
   [junit4]   2> 2042772 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.c.ZkTestServer 
parse host and port list: 127.0.0.1:36057
   [junit4]   2> 2042772 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.c.ZkTestServer 
connecting to 127.0.0.1 36057
   [junit4]   2> 2042817 INFO  (zkConnectionManagerCallback-3787-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 2042849 INFO  (zkConnectionManagerCallback-3789-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 2042858 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
initCore
   [junit4]   2> 2042858 INFO  
(SUITE-OverseerTest-seed#[95FF74B2CEEB]-worker) [] o.a.s.SolrTestCaseJ4 
initCore end
   [junit4]   2> 2042891 INFO  
(TEST-OverseerTest.testReplay-seed#[95FF74B2CEEB]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testReplay
   [junit4]   2> 2043032 INFO  (zkConnectionManagerCallback-3793-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 2043071 WARN  
(TEST-OverseerTest.testReplay-seed#[95FF74B2CEEB]) [] 
o.e.j.u.s.S.config No Client EndPointIdentificationAlgorithm configured for 
SslContextFactory@723c5fd[provider=null,keyStore=null,trustStore=null]
   [junit4]   2> 2043100 INFO  (zkConnectionManagerCallback-3800-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 2043162 INFO  (zkConnectionManagerCallback-3805-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 2043165 INFO  
(TEST-OverseerTest.testReplay-seed#[95FF74B2CEEB]) [] 
o.a.s.c.s.i.ZkClientClusterStateProvider Cluster at 127.0.0.1:36057/solr ready
   [junit4]   2> 2043167 INFO  
(TEST-OverseerTest.testReplay-seed#[95FF74B2CEEB]) [] 
o.a.s.c.OverseerElectionContext I am going to be the leader 127.0.0.1:36057_solr
   [junit4]   2> 2043168 INFO  
(TEST-OverseerTest.testReplay-seed#[95FF74B2CEEB]) [] o.a.s.c.Overseer 
Overseer (id=74306098037260290-127.0.0.1:36057_solr-n_00) starting
   [junit4]   2> 2043179 INFO  
(OverseerStateUpdate-74306098037260290-127.0.0.1:36057_solr-n_00) [
] o.a.s.c.Overseer Starting to work on the main queue : 127.0.0.1:36057_solr
   [junit4]   2> 2043437 INFO  (closeThreadPool-3807-thread-1) [] 
o.a.s.c.Overseer Overseer 
(id=74306098037260290-127.0.0.1:36057_solr-n_00) closing
   [junit4]   2> 2043438 INFO  
(OverseerStateUpdate-74306098037260290-127.0.0.1:36057_solr-n_00) [
] o.a.s.c.Overseer Overseer Loop exiting : 127.0.0.1:36057_solr
   [junit4]   2> 2043438 INFO  

Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Đạt Cao Mạnh]

For clarification:
>
> But this does not disable the HTTP/2 listener, it just makes SolrJ no
> longer use the Http2SolrClient and fall back to the old one.

This is true and it is not a bug. The reason here is for rolling updates,
since -Dsolr.http1=true nodes can *send* and *accept *requests *to/from*
Solr 7.x and Solr 8 without that flag. As I mentioned in CHANGES.txt for
rolling updates
Step 1. Some nodes wil be upgraded to Solr 8 with -Dsolr.http1=true, the
rest will still remain on Solr 7.x. They can communicate to each others
since only HTTP/1 is used
Step 2. All nodes get upgraded to Solr 8 with -Dsolr.http1=true.
Step 3. Some nodes with -Dsolr.http1=true (A) and the rest (B) without that
flag. A will talk with B using HTTP/1 (possible) and B will talk with A
using HTTP/2 (since HTTP/2 listener is enabled in -Dsolr.http1=true nodes)
Step 4: All nodes get upgraded to Solr 8 without solr.http1 flag. They will
talk with each other using HTTP/2 now.

On Thu, Mar 7, 2019 at 4:32 PM Uwe Schindler  wrote:

> Thanks for the reminder,
>
>
>
> I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the
> startup script. But this does not disable the HTTP/2 listener, it just
> makes SolrJ no longer use the Http2SolrClient and fall back to the old one.
> But that only affects the “new” solr servers as a “client” to old servers
> during rolling upgrade.
>
>
>
> I did a quick check, if the parameter makes its way to solr: yes, after
> starting solr with “-Dsolr.http1=true”:
>
> C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true
>
> … it showed the parameter in admin UI under system properties.
>
>
>
> But I did not test a full cluster in the short time. The HTTP/2 endpoint
> of the started server was still available, but outgoing solr requests
> should only go with HTTP1 then. I am sure somebody tested this in Linux,
> Windows is same as the system property reached the JVM, so startup scripts
> handle it right.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Alan Woodward 
> *Sent:* Thursday, March 7, 2019 9:17 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> Is there a way of passing Jetty parameters from the command line?  IOW,
> can Windows users do a rolling upgrade if they run ./solr restart
> -Djetty.module=http or whatever?
>
>
>
> On 6 Mar 2019, at 21:57, Uwe Schindler  wrote:
>
>
>
> I opened a blocker issue:
>
> https://issues.apache.org/jira/browse/SOLR-13299
>
>
>
> The fix is easy, will commit it soon to all 3 branches.
>
>
>
> IMHO, we should respin as non-working startup script on Windows for users
> of secured Solr servers is a blocker.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler 
> *Sent:* Wednesday, March 6, 2019 8:52 PM
> *To:* dev@lucene.apache.org
> *Subject:* RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
>
>
>
> It looks like on Linux the Solr start script correctly sets module in
> jetty, so it disables http2 on Java 8. I have not tested this but it looks
> like on Windows the if statement is missing.
>
> If we cannot fix this soon we may release a Bugfix Version later, but this
> would prevent Windows users from upgrading.
>
> So I switch to +/-0 to release. What do others think?
>
> I will try to fix startup script later, maybe it's easy.
>
> Uwe
>
> Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler :
>
> Hi,
>
>
>
> I also checked the RC2. First automated smoke testing with Policeman
> Jenkins resulted in a +1 from Policeman Jenkins:
>
>
>
> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console
>
> SUCCESS! [2:42:28.295475]
>
>
>
> The testing was done with Java 8 and Java 9 (this is why it took longer).
>
>
>
> I also checked Changes.txt, looks fine (there is only a few typos in the
> changes about the switch of Solr to HTTP/2, but that’s not horrible, but we
> should improve it, as its one significant change): latter -> later
>
>
>
> I also checked the ZIP files of Lucene and Solr. Lucene looks as usual,
> MIGRATE.txt is also fine – thanks for adding recent information! JAR files
> also look fine, compiled with correct version of Java and patches
> multi-release class files are there.
>
>
>
> Apache Solr was unzipped and quickly tested on Windows: Startup with Java
> 8 and Java 11 worked without any problems from a directory with whitespace
> in path. I was able to do a HTTP/2 request with CURL (non-TLS) on both O/S:
>
>
>
> *Uwe Schindler@VEGA:*~ > curl -I --http2 localhost:8983/solr/
>
> HTTP/1.1 101 Switching Protocols
>
>
>
> HTTP/2 200
>
> x-frame-options: DENY
>
> content-type: text/html;charset=utf-8
>
> content-length: 14662
>
>
>
> So, it worked. In the webbrowser it did not use HTTP/2, as browsers
> require SSL for that (by default).
>
>
>
> Next I enabled TLS support by 

[jira] [Commented] (SOLR-13284) NPE on passing Invalid response writer as request parameter

[Munendra S N (JIRA)]

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

Munendra S N commented on SOLR-13284:
-

{quote}Can you tell why it null checks for core but not to wt param not the 
first writer returned{quote}
There is no null check for first writer returned since it would never be null. 
This method returns default response writer when wt is null or invalid
{code:java}
https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/SolrCore.java#L2753
{code}

{quote}Can core ever be null?{quote}
I'm actually not sure about this. I have kept the null check as it was already 
present

> NPE on passing Invalid response writer as request parameter
> ---
>
> Key: SOLR-13284
> URL: https://issues.apache.org/jira/browse/SOLR-13284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-13284.patch, SOLR-13284.patch
>
>
> V1 API or the old API uses default response writer when non-existent response 
> writer is specified in the request whereas V2 API fails with NPE with below 
> stack trace
> {noformat}
> {trace=java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:776)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at org.eclipse.jetty.server.Server.handle(Server.java:502)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>   at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>   at 
> 

[jira] [Comment Edited] (SOLR-13284) NPE on passing Invalid response writer as request parameter

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-13284 at 3/7/19 5:08 PM:
-

I have to say that the complexity exceeded my ability. Can you tell why it null 
checks for core but not to wt param not the first writer returned? Can core 
ever be null?


was (Author: mkhludnev):
I have to say that the complexity exceeded my ability. Can you tell why it null 
checks for core but not to wt param not the first writer returned? 

> NPE on passing Invalid response writer as request parameter
> ---
>
> Key: SOLR-13284
> URL: https://issues.apache.org/jira/browse/SOLR-13284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-13284.patch, SOLR-13284.patch
>
>
> V1 API or the old API uses default response writer when non-existent response 
> writer is specified in the request whereas V2 API fails with NPE with below 
> stack trace
> {noformat}
> {trace=java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:776)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at org.eclipse.jetty.server.Server.handle(Server.java:502)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>   at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
>   at java.lang.Thread.run(Thread.java:745)
> ,code=500}
> {noformat}
> h5. Possible 

[jira] [Commented] (SOLR-13284) NPE on passing Invalid response writer as request parameter

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-13284:
-

I have to say that the complexity exceeded my ability. Can you tell why it null 
checks for core but not to wt param not the first writer returned? 

> NPE on passing Invalid response writer as request parameter
> ---
>
> Key: SOLR-13284
> URL: https://issues.apache.org/jira/browse/SOLR-13284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: v2 API
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-13284.patch, SOLR-13284.patch
>
>
> V1 API or the old API uses default response writer when non-existent response 
> writer is specified in the request whereas V2 API fails with NPE with below 
> stack trace
> {noformat}
> {trace=java.lang.NullPointerException
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:776)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:525)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:394)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:340)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1588)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at 
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
>   at org.eclipse.jetty.server.Server.handle(Server.java:502)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
>   at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
>   at 
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126)
>   at 
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
>   at java.lang.Thread.run(Thread.java:745)
> ,code=500}
> {noformat}
> h5. Possible Solutions :
>  * V2 API should fall back to default response writer like V1 API
>  * V2 API should fail with proper error message and error code



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

[VOTE] Release Lucene/Solr 8.0.0 RC3

[jim ferenczi]

Please vote for release candidate 3 for Lucene/Solr 8.0.0

The artifacts can be downloaded from
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
You can run the smoke tester directly with this command:
python3 -u dev-tools/scripts/smokeTestRelease.py
*https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e
*

Here’s my +1
SUCCESS! [1:14:08.843490]

RE: [VOTE] Release Lucene/Solr 8.0.0 RC2

[Uwe Schindler]

Thanks for the reminder,

 

I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the 
startup script. But this does not disable the HTTP/2 listener, it just makes 
SolrJ no longer use the Http2SolrClient and fall back to the old one. But that 
only affects the “new” solr servers as a “client” to old servers during rolling 
upgrade.

 

I did a quick check, if the parameter makes its way to solr: yes, after 
starting solr with “-Dsolr.http1=true”:

C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true

… it showed the parameter in admin UI under system properties.

 

But I did not test a full cluster in the short time. The HTTP/2 endpoint of the 
started server was still available, but outgoing solr requests should only go 
with HTTP1 then. I am sure somebody tested this in Linux, Windows is same as 
the system property reached the JVM, so startup scripts handle it right.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Alan Woodward  
Sent: Thursday, March 7, 2019 9:17 AM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

Is there a way of passing Jetty parameters from the command line?  IOW, can 
Windows users do a rolling upgrade if they run ./solr restart 
-Djetty.module=http or whatever?





On 6 Mar 2019, at 21:57, Uwe Schindler <  
u...@thetaphi.de> wrote:

 

I opened a blocker issue:

  
https://issues.apache.org/jira/browse/SOLR-13299

 

The fix is easy, will commit it soon to all 3 branches.

 

IMHO, we should respin as non-working startup script on Windows for users of 
secured Solr servers is a blocker.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  http://www.thetaphi.de

eMail:   u...@thetaphi.de

 

From: Uwe Schindler <  u...@thetaphi.de> 
Sent: Wednesday, March 6, 2019 8:52 PM
To:   dev@lucene.apache.org
Subject: RE: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

It looks like on Linux the Solr start script correctly sets module in jetty, so 
it disables http2 on Java 8. I have not tested this but it looks like on 
Windows the if statement is missing.

If we cannot fix this soon we may release a Bugfix Version later, but this 
would prevent Windows users from upgrading.

So I switch to +/-0 to release. What do others think?

I will try to fix startup script later, maybe it's easy.

Uwe

Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler < 
 u...@thetaphi.de>:

Hi,

 

I also checked the RC2. First automated smoke testing with Policeman Jenkins 
resulted in a +1 from Policeman Jenkins:

 

  
https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console

SUCCESS! [2:42:28.295475]

 

The testing was done with Java 8 and Java 9 (this is why it took longer).

 

I also checked Changes.txt, looks fine (there is only a few typos in the 
changes about the switch of Solr to HTTP/2, but that’s not horrible, but we 
should improve it, as its one significant change): latter -> later

 

I also checked the ZIP files of Lucene and Solr. Lucene looks as usual, 
MIGRATE.txt is also fine – thanks for adding recent information! JAR files also 
look fine, compiled with correct version of Java and patches multi-release 
class files are there.

 

Apache Solr was unzipped and quickly tested on Windows: Startup with Java 8 and 
Java 11 worked without any problems from a directory with whitespace in path. I 
was able to do a HTTP/2 request with CURL (non-TLS) on both O/S:

 

Uwe Schindler@VEGA:~ > curl -I --http2 localhost:8983/solr/

HTTP/1.1 101 Switching Protocols

 

HTTP/2 200

x-frame-options: DENY

content-type: text/html;charset=utf-8

content-length: 14662

 

So, it worked. In the webbrowser it did not use HTTP/2, as browsers require SSL 
for that (by default).

 

Next I enabled TLS support by creating a keystore. Unfortunately Solr did not 
start with Java 8. According to the documentation it should still start, but 
disable HTTP/2 by default. But it complained about no ALPN processors: 

 

Waiting up to 30 to see Solr running on port 8983

java.lang.reflect.InvocationTargetException

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 org.eclipse.jetty.start.Main.invokeMain(Main.java:220)

at org.eclipse.jetty.start.Main.start(Main.java:490)

at org.eclipse.jetty.start.Main.main(Main.java:77)

Caused by: java.security.PrivilegedActionException: 

[jira] [Commented] (SOLR-13299) Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-13299:
--

Oh it was committed already by [~jim.ferenczi]. Thanks!

> Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8
> ---
>
> Key: SOLR-13299
> URL: https://issues.apache.org/jira/browse/SOLR-13299
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 8.0
> Environment: Windows 10
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java8
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13299.patch
>
>
> When trying to start the Solr 8 release candidate with Java 8 having SSL/TLS 
> enabled, the Windows solr.cmd startup script fails with ALPN not found while 
> complainig about the ALPN JAR file which only works with Java 9+:
> {noformat}
> Waiting up to 30 to see Solr running on port 8983
> java.lang.reflect.InvocationTargetException
> 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 org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:490)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by: java.security.PrivilegedActionException: 
> java.lang.reflect.InvocationTargetException
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> ... 7 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:663)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:858)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newArray(XmlConfiguration.java:936)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1313)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:842)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.access$500(XmlConfiguration.java:326)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1442)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1417)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:780)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:472)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:413)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:311)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1558)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
> ... 9 more
> Caused by: java.lang.IllegalStateException: No Server ALPNProcessors!
> at 
> org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.(ALPNServerConnectionFactory.java:53)
>... 32 more
> Suppressed: java.lang.UnsupportedClassVersionError: 
> org/eclipse/jetty/alpn/java/server/JDK9ServerALPNProcessor has 

[jira] [Commented] (SOLR-13299) Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-13299:
--

Thanks [~caomanhdat] and the others, I will commit this NOW to all three 
branches.

> Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8
> ---
>
> Key: SOLR-13299
> URL: https://issues.apache.org/jira/browse/SOLR-13299
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 8.0
> Environment: Windows 10
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java8
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13299.patch
>
>
> When trying to start the Solr 8 release candidate with Java 8 having SSL/TLS 
> enabled, the Windows solr.cmd startup script fails with ALPN not found while 
> complainig about the ALPN JAR file which only works with Java 9+:
> {noformat}
> Waiting up to 30 to see Solr running on port 8983
> java.lang.reflect.InvocationTargetException
> 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 org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:490)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by: java.security.PrivilegedActionException: 
> java.lang.reflect.InvocationTargetException
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> ... 7 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:663)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:858)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newArray(XmlConfiguration.java:936)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1313)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:842)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.access$500(XmlConfiguration.java:326)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1442)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1417)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:780)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:472)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:413)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:311)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1558)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
> ... 9 more
> Caused by: java.lang.IllegalStateException: No Server ALPNProcessors!
> at 
> org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.(ALPNServerConnectionFactory.java:53)
>... 32 more
> Suppressed: java.lang.UnsupportedClassVersionError: 
> 

[jira] [Resolved] (SOLR-13155) CLI tool for testing autoscaling suggestions against a live cluster

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-13155.
--
Resolution: Fixed

> CLI tool for testing autoscaling suggestions against a live cluster
> ---
>
> Key: SOLR-13155
> URL: https://issues.apache.org/jira/browse/SOLR-13155
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13155.patch, SOLR-13155.patch, SOLR-13155.patch
>
>
> Solr already provides /autoscaling/diagnostics and /autoscaling/suggestions 
> endpoints. In some situations it would be very helpful to be able to run 
> "what if" scenarios using data about nodes and replicas taken from a 
> production cluster but with a different autoscaling policy than the one that 
> is deployed, without also worrying that the calculations would negatively 
> impact a production cluster's Overseer leader.
> All necessary classes (including the Policy engine) are self-contained in the 
> SolrJ component, so it's just a matter of packaging and writing a CLI tool + 
> a wrapper script.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-12-ea+shipilev-fastdebug) - Build # 3613 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/3613/
Java: 64bit/jdk-12-ea+shipilev-fastdebug -XX:-UseCompressedOops 
-XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate

Error Message:
The trigger did not fire at all

Stack Trace:
java.lang.AssertionError: The trigger did not fire at all
at 
__randomizedtesting.SeedInfo.seed([C463AAFD071DC47D:992BB474C8DB6232]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at 
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testSearchRate(TestSimLargeCluster.java:682)
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 
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 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)




Build Log:
[...truncated 1941 lines...]
   [junit4] JVM J1: stderr was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-7.x-Linux/lucene/build/core/test/temp/junit4-J1-20190307_132703_9325926170831903280146.syserr
   [junit4] >>> JVM J1 emitted unexpected output 

[jira] [Commented] (SOLR-13304) PreanalyzedField#createField swallows Exception

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13304:
-

good idea :)

> PreanalyzedField#createField swallows Exception
> ---
>
> Key: SOLR-13304
> URL: https://issues.apache.org/jira/browse/SOLR-13304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 7.7.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13304.patch
>
>
> The following code allows one to believe that an ill formatted pre-analyzed 
> field has successfully been written unless one is actively monitoring the 
> logs: 
> {code}@Override
> public IndexableField createField(SchemaField field, Object value) {
>   IndexableField f = null;
>   try {
> f = fromString(field, String.valueOf(value));
>   } catch (Exception e) {
> log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", e);
> return null;
>   }
>   return f;
> }{code}
> I believe this should throw an error just like a poorly formatted date or 
> other invalid value.



--
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-13304) PreanalyzedField#createField swallows Exception

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13304:
--

+1. I would also add the field name in the exception's message to help with 
troubleshooting.

> PreanalyzedField#createField swallows Exception
> ---
>
> Key: SOLR-13304
> URL: https://issues.apache.org/jira/browse/SOLR-13304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 7.7.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13304.patch
>
>
> The following code allows one to believe that an ill formatted pre-analyzed 
> field has successfully been written unless one is actively monitoring the 
> logs: 
> {code}@Override
> public IndexableField createField(SchemaField field, Object value) {
>   IndexableField f = null;
>   try {
> f = fromString(field, String.valueOf(value));
>   } catch (Exception e) {
> log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", e);
> return null;
>   }
>   return f;
> }{code}
> I believe this should throw an error just like a poorly formatted date or 
> other invalid value.



--
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] [Comment Edited] (SOLR-9882) exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be cast to SolrDocumentList

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-9882 at 3/7/19 3:23 PM:


I'm keeping it open for a while. 
* two known regressions have been fixed. Thanks to [~erickerickson]
* I highly appreciate users for checking the snapshot with the fix
* looking forward for more query cases to include into creep test, eg now 
group and mlt aren't covered, but it makes sense.
* I'm open for suggestion of capturing jetty 500 errors with less footprint for 
test codebase. 
* Shouldn't we add partial result flag into request log line? It might be as 
well important as hits and status. 
Thanks everyone!


was (Author: mkhludnev):
I'm keeping it open for a while. 
* two known regressions have been fixed. Thanks to [~erickerickson]
* I highly appreciate users for checking the snapshot with the fix
* looking forward for more query cases to include into creep test, eg now 
group and mlt aren't covered, but it makes sense.
* I'm open for suggestion of capturing 500 errors with less footprint for 
codebase. 
Thanks everyone!

> exceeding timeAllowed causes ClassCastException: BasicResultContext cannot be 
> cast to SolrDocumentList
> --
>
> Key: SOLR-9882
> URL: https://issues.apache.org/jira/browse/SOLR-9882
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Yago Riveiro
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-9882-7987.patch, SOLR-9882-solr-7.6.0-backport.txt, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, SOLR-9882.patch, 
> SOLR-9882.patch, SOLR-9882.patch
>
>
> After talk with [~yo...@apache.org] in the mailing list I open this Jira 
> ticket
> I'm hitting this bug in Solr 6.3.0.
> null:java.lang.ClassCastException:
> org.apache.solr.response.BasicResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:315)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at
> org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:169)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
> at
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
> at
> 

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11) - Build # 7756 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7756/
Java: 64bit/jdk-11 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.CloudSolrClientTest

Error Message:
ObjectTracker found 6 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, InternalHttpClient, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper] 
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.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:509)  
at org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:351) 
 at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:422) 
 at 
org.apache.solr.handler.ReplicationHandler.lambda$setupPolling$13(ReplicationHandler.java:1191)
  at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
  at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) 
 at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:834)  
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.core.SolrCore  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.core.SolrCore.(SolrCore.java:1063)  at 
org.apache.solr.core.SolrCore.(SolrCore.java:883)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1192)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1102)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
  at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
  at java.base/java.lang.Thread.run(Thread.java:834)  
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:230)  
at org.apache.solr.handler.IndexFetcher.(IndexFetcher.java:272)  at 
org.apache.solr.handler.ReplicationHandler.inform(ReplicationHandler.java:1222) 
 at 
org.apache.solr.cloud.ReplicateFromLeader.startReplication(ReplicateFromLeader.java:109)
  at 
org.apache.solr.cloud.ZkController.startReplicationFromLeader(ZkController.java:1293)
  at org.apache.solr.cloud.ZkController.register(ZkController.java:1249)  at 
org.apache.solr.cloud.ZkController.register(ZkController.java:1134)  at 
org.apache.solr.core.ZkContainer.lambda$registerInZk$0(ZkContainer.java:190)  
at org.apache.solr.core.ZkContainer.registerInZk(ZkContainer.java:222)  at 
org.apache.solr.core.CoreContainer.registerCore(CoreContainer.java:1040)  at 
org.apache.solr.core.CoreContainer.createFromDescriptor(CoreContainer.java:1202)
  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1102)  at 
org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$0(CoreAdminOperation.java:92)
  at 
org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:360)
  at 
org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:396)
  at 
org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:188)
  at 
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
  at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
  at 

[jira] [Updated] (SOLR-13292) Provide extended per-segment status of a collection

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13292:
-
Attachment: adminSegments.json

> Provide extended per-segment status of a collection
> ---
>
> Key: SOLR-13292
> URL: https://issues.apache.org/jira/browse/SOLR-13292
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8x
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13292.patch, SOLR-13292.patch, adminSegments.json, 
> adminSegments.json, colstatus.json, colstatus.json
>
>
> When changing a collection configuration or schema there may be non-obvious 
> conflicts between existing data and the new configuration or the newly 
> declared schema. A similar situation arises when upgrading Solr to a new 
> version while keeping the existing data.
> Currently the {{SegmentsInfoRequestHandler}} provides insufficient 
> information to detect such conflicts. Also, there's no collection-wide 
> command to gather such status from all shard leaders.
> This issue proposes extending the {{/admin/segments}} handler to provide more 
> low-level Lucene details about the segments, including potential conflicts 
> between existing segments' data and the current declared schema. It also adds 
> a new COLSTATUS collection command to report an aggregated status from all 
> shards, and optionally for all collections.



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

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

[jira] [Updated] (SOLR-13292) Provide extended per-segment status of a collection

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-13292:
-
Attachment: colstatus.json

> Provide extended per-segment status of a collection
> ---
>
> Key: SOLR-13292
> URL: https://issues.apache.org/jira/browse/SOLR-13292
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8x
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13292.patch, SOLR-13292.patch, adminSegments.json, 
> adminSegments.json, colstatus.json, colstatus.json
>
>
> When changing a collection configuration or schema there may be non-obvious 
> conflicts between existing data and the new configuration or the newly 
> declared schema. A similar situation arises when upgrading Solr to a new 
> version while keeping the existing data.
> Currently the {{SegmentsInfoRequestHandler}} provides insufficient 
> information to detect such conflicts. Also, there's no collection-wide 
> command to gather such status from all shard leaders.
> This issue proposes extending the {{/admin/segments}} handler to provide more 
> low-level Lucene details about the segments, including potential conflicts 
> between existing segments' data and the current declared schema. It also adds 
> a new COLSTATUS collection command to report an aggregated status from all 
> shards, and optionally for all collections.



--
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] [Comment Edited] (SOLR-13292) Provide extended per-segment status of a collection

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  edited comment on SOLR-13292 at 3/7/19 1:54 PM:
--

This patch adds a new COLSTATUS command and an extended support in 
{{SegmentsInfoRequestHandler}} for reporting low-level details of Lucene 
segments and their compliance with the current schema.

Example requests:
{code:java}
http://localhost:8983/solr/gettingstarted/admin/segments?coreInfo=true=true=true

http://localhost:8983/solr/admin/collections?action=COLSTATUS=true=true=true{code}
Responses are attached.


was (Author: ab):
This patch adds a new COLSTATUS command and an extended support in 
{{SegmentsInfoRequestHandler}} for reporting low-level details of Lucene 
segments and their compliance with the current schema.

Example requests:
{code:java}
http://localhost:8983/solr/gettingstarted/admin/segments?coreInfo=true=true

http://localhost:8983/solr/admin/collections?action=COLSTATUS=true=true{code}
Responses are attached.

> Provide extended per-segment status of a collection
> ---
>
> Key: SOLR-13292
> URL: https://issues.apache.org/jira/browse/SOLR-13292
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8x
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13292.patch, SOLR-13292.patch, adminSegments.json, 
> colstatus.json
>
>
> When changing a collection configuration or schema there may be non-obvious 
> conflicts between existing data and the new configuration or the newly 
> declared schema. A similar situation arises when upgrading Solr to a new 
> version while keeping the existing data.
> Currently the {{SegmentsInfoRequestHandler}} provides insufficient 
> information to detect such conflicts. Also, there's no collection-wide 
> command to gather such status from all shard leaders.
> This issue proposes extending the {{/admin/segments}} handler to provide more 
> low-level Lucene details about the segments, including potential conflicts 
> between existing segments' data and the current declared schema. It also adds 
> a new COLSTATUS collection command to report an aggregated status from all 
> shards, and optionally for all collections.



--
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-13296) Example of Preanalyzed JSON in ref guide invalid

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-13296:
--

Since the 8.0 Ref Guide isn't out yet, IMO this should be backported into 
branch_8_0. I'll do that once the new 8.0 RC is out so I don't screw that 
process up (probably wouldn't, but just to be safest), but there's no reason to 
knowingly release with bad info.

> Example of Preanalyzed JSON in ref guide invalid
> 
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I 
> decided to first check that the config could successfully accept a chunk of 
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception 
> writing document id 1 to the index; possible analysis error: startOffset must 
> be non-negative, and endOffset must be >= startOffset, and offsets must not 
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field 
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a 
> patch to make the (mostly nonsensical) example at least technically valid



--
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-13292) Provide extended per-segment status of a collection

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  commented on SOLR-13292:
--

This patch adds more details:
* optional RAM usage of segment readers and top 5 largest segment files
* basic term stats for indexed fields

If there are no objections I'd like to commit this shortly.

> Provide extended per-segment status of a collection
> ---
>
> Key: SOLR-13292
> URL: https://issues.apache.org/jira/browse/SOLR-13292
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8x
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13292.patch, SOLR-13292.patch, adminSegments.json, 
> colstatus.json
>
>
> When changing a collection configuration or schema there may be non-obvious 
> conflicts between existing data and the new configuration or the newly 
> declared schema. A similar situation arises when upgrading Solr to a new 
> version while keeping the existing data.
> Currently the {{SegmentsInfoRequestHandler}} provides insufficient 
> information to detect such conflicts. Also, there's no collection-wide 
> command to gather such status from all shard leaders.
> This issue proposes extending the {{/admin/segments}} handler to provide more 
> low-level Lucene details about the segments, including potential conflicts 
> between existing segments' data and the current declared schema. It also adds 
> a new COLSTATUS collection command to report an aggregated status from all 
> shards, and optionally for all collections.



--
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] [Resolved] (SOLR-13299) Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi resolved SOLR-13299.
-
   Resolution: Fixed
Fix Version/s: master (9.0)

Thanks [~thetaphi]!

> Solr 8 RC2 does not start on Windows with SSL/TLS enabled on Java 8
> ---
>
> Key: SOLR-13299
> URL: https://issues.apache.org/jira/browse/SOLR-13299
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Server
>Affects Versions: 8.0
> Environment: Windows 10
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java8
> Fix For: 8.0, master (9.0)
>
> Attachments: SOLR-13299.patch
>
>
> When trying to start the Solr 8 release candidate with Java 8 having SSL/TLS 
> enabled, the Windows solr.cmd startup script fails with ALPN not found while 
> complainig about the ALPN JAR file which only works with Java 9+:
> {noformat}
> Waiting up to 30 to see Solr running on port 8983
> java.lang.reflect.InvocationTargetException
> 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 org.eclipse.jetty.start.Main.invokeMain(Main.java:220)
> at org.eclipse.jetty.start.Main.start(Main.java:490)
> at org.eclipse.jetty.start.Main.main(Main.java:77)
> Caused by: java.security.PrivilegedActionException: 
> java.lang.reflect.InvocationTargetException
> at java.security.AccessController.doPrivileged(Native Method)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511)
> ... 7 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:663)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:858)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newArray(XmlConfiguration.java:936)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1313)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:842)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.access$500(XmlConfiguration.java:326)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1442)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1417)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:780)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:472)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:413)
> at 
> org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:311)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1558)
> at 
> org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512)
> ... 9 more
> Caused by: java.lang.IllegalStateException: No Server ALPNProcessors!
> at 
> org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.(ALPNServerConnectionFactory.java:53)
>... 32 more
> Suppressed: java.lang.UnsupportedClassVersionError: 
> org/eclipse/jetty/alpn/java/server/JDK9ServerALPNProcessor has been compiled 
> 

[jira] [Updated] (SOLR-13292) Provide extended per-segment status of a collection

[Andrzej Bialecki (JIRA)]

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

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

> Provide extended per-segment status of a collection
> ---
>
> Key: SOLR-13292
> URL: https://issues.apache.org/jira/browse/SOLR-13292
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: master (9.0), 8x
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: SOLR-13292.patch, SOLR-13292.patch, adminSegments.json, 
> colstatus.json
>
>
> When changing a collection configuration or schema there may be non-obvious 
> conflicts between existing data and the new configuration or the newly 
> declared schema. A similar situation arises when upgrading Solr to a new 
> version while keeping the existing data.
> Currently the {{SegmentsInfoRequestHandler}} provides insufficient 
> information to detect such conflicts. Also, there's no collection-wide 
> command to gather such status from all shard leaders.
> This issue proposes extending the {{/admin/segments}} handler to provide more 
> low-level Lucene details about the segments, including potential conflicts 
> between existing segments' data and the current declared schema. It also adds 
> a new COLSTATUS collection command to report an aggregated status from all 
> shards, and optionally for all collections.



--
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-13286) Move Metrics handler and any other noisy admin logging to debug

[Gus Heck (JIRA)]

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

Gus Heck commented on SOLR-13286:
-

[~erickerickson] Any thoughts on my updated patch?

> Move Metrics handler and any other noisy admin logging to debug
> ---
>
> Key: SOLR-13286
> URL: https://issues.apache.org/jira/browse/SOLR-13286
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: logging
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
> Attachments: SOLR-13286.patch, SOLR-13286.patch
>
>
> Lately when looking at log files I always find myself straining and squinting 
> to see things among a vast sea of metrics related logging. The problem 
> appears to be that the metrics system regularly issues /admin/ commands that 
> get logged at info by HttpSolrCall, so turning this down also means you can't 
> see any other admin commands, which is often what you're looking for in the 
> first place (ok what I'm often looking for at least :) ). I also recall 
> seeing a complaint about this on one of the lists at some point. 
> Attaching patch to log at an alternate level these based on the value of the 
> handler field in HttpSolrCall. Patch is untested and meant as fodder for 
> commentary and for suggestions of other handlers that might want to go on the 
> "noisy" list.



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

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

[jira] [Assigned] (SOLR-13296) Example of Preanalyzed JSON in ref guide invalid

[Gus Heck (JIRA)]

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

Gus Heck reassigned SOLR-13296:
---

Assignee: Gus Heck

> Example of Preanalyzed JSON in ref guide invalid
> 
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I 
> decided to first check that the config could successfully accept a chunk of 
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception 
> writing document id 1 to the index; possible analysis error: startOffset must 
> be non-negative, and endOffset must be >= startOffset, and offsets must not 
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field 
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a 
> patch to make the (mostly nonsensical) example at least technically valid



--
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-NightlyTests-8.x - Build # 38 - Still Unstable

[Apache Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple

Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for 
collection=testSimple2 
:DocCollection(testSimple2//collections/testSimple2/state.json/21)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"http://127.0.0.1:36592/solr;,   
"node_name":"127.0.0.1:36592_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"http://127.0.0.1:37449/solr;,   
"node_name":"127.0.0.1:37449_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"http://127.0.0.1:36592/solr;,   
"node_name":"127.0.0.1:36592_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"http://127.0.0.1:37449/solr;,   
"node_name":"127.0.0.1:37449_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node8/data/tlog",
   "core":"testSimple2_shard2_replica_n6",   
"shared_storage":"true",   "state":"down",   
"router":{"name":"compositeId"},   "maxShardsPerNode":"2",   
"autoAddReplicas":"true",   "nrtReplicas":"2",   "tlogReplicas":"0"} Live 
Nodes: [127.0.0.1:36592_solr, 127.0.0.1:46745_solr] Last available state: 
DocCollection(testSimple2//collections/testSimple2/state.json/21)={   
"pullReplicas":"0",   "replicationFactor":"2",   "shards":{ "shard1":{  
 "range":"8000-",   "state":"active",   "replicas":{
 "core_node3":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node3/data/", 
  "base_url":"http://127.0.0.1:36592/solr;,   
"node_name":"127.0.0.1:36592_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node3/data/tlog",
   "core":"testSimple2_shard1_replica_n1",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node5":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node5/data/", 
  "base_url":"http://127.0.0.1:37449/solr;,   
"node_name":"127.0.0.1:37449_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node5/data/tlog",
   "core":"testSimple2_shard1_replica_n2",   
"shared_storage":"true",   "state":"down"}}}, "shard2":{   
"range":"0-7fff",   "state":"active",   "replicas":{ 
"core_node7":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node7/data/", 
  "base_url":"http://127.0.0.1:36592/solr;,   
"node_name":"127.0.0.1:36592_solr",   "type":"NRT",   
"force_set_state":"false",   
"ulogDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node7/data/tlog",
   "core":"testSimple2_shard2_replica_n4",   
"shared_storage":"true",   "state":"active",   
"leader":"true"}, "core_node8":{   
"dataDir":"hdfs://localhost:44798/solr_hdfs_home/testSimple2/core_node8/data/", 
  "base_url":"http://127.0.0.1:37449/solr;,   
"node_name":"127.0.0.1:37449_solr",   "type":"NRT",   
"force_set_state":"false",   

[jira] [Commented] (SOLR-13285) ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during replication

[JIRA]

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

Thomas Wöckinger commented on SOLR-13285:
-

Does also happen when using solrj with standalone server.

Using a EnumFiledValue and a coresponding enumConfig

{{NATIONALINTERNATIONAL}}

> ByteArrayUtf8CharSequence cannot be cast to java.lang.String exception during 
> replication
> -
>
> Key: SOLR-13285
> URL: https://issues.apache.org/jira/browse/SOLR-13285
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: replication (java), SolrCloud, SolrJ
>Affects Versions: 7.7, 7.7.1, 8.1
> Environment: centos 7
> solrcloud 7.7.1, 8.1.0
>Reporter: Karl Stoney
>Assignee: Noble Paul
>Priority: Major
>  Labels: newbie, replication
> Attachments: SOLR-13285.patch, SOLR-13285.patch
>
>
> Since upgrading to 7.7 (also tried 7.7.1, and 8.1.0) from 6.6.4, we're seeing 
> the following errors in the SolrCloud elected master for a given collection 
> when updates are written.  This was after a full reindex of data (fresh 
> build).
> {code:java}
> request: 
> http://solr-1.search-solr.preprod.k8.atcloud.io:80/solr/at-uk_shard1_replica_n2/update?update.distrib=FROMLEADER=http%3A%2F%2Fsolr-2.search-solr.preprod.k8.atcloud.io%3A80%2Fsolr%2Fat-uk_shard1_replica_n1%2F=javabin=2
> Remote error message: org.apache.solr.common.util.ByteArrayUtf8CharSequence 
> cannot be cast to java.lang.String
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:385)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:183)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
>  ~[metrics-core-3.2.6.jar:3.2.6]
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
>  ~[solr-solrj-7.7.1.jar:7.7.1 5bf96d32f88eb8a2f5e775339885cd6ba84a3b58 - 
> ishan - 2019-02-23 02:39:09]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  ~[?:1.8.0_191]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  ~[?:1.8.0_191]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
> {code}
> Following this through to the replica, you'll see:
> {code:java}
> 08:35:22.060 [qtp1540374340-20] ERROR org.apache.solr.servlet.HttpSolrCall - 
> null:java.lang.ClassCastException: 
> org.apache.solr.common.util.ByteArrayUtf8CharSequence cannot be cast to 
> java.lang.String
> at 
> org.apache.solr.common.util.JavaBinCodec.readEnumFieldValue(JavaBinCodec.java:813)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:339)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readSolrInputDocument(JavaBinCodec.java:640)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:337)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.readMapEntry(JavaBinCodec.java:819)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:341)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:295)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:333)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
> at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
> at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:278)
> at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:191)
> at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
> at 
> 

[jira] [Updated] (SOLR-13304) PreanalyzedField#createField swallows Exception

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13304:

Attachment: SOLR-13304.patch

> PreanalyzedField#createField swallows Exception
> ---
>
> Key: SOLR-13304
> URL: https://issues.apache.org/jira/browse/SOLR-13304
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 7.7.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13304.patch
>
>
> The following code allows one to believe that an ill formatted pre-analyzed 
> field has successfully been written unless one is actively monitoring the 
> logs: 
> {code}@Override
> public IndexableField createField(SchemaField field, Object value) {
>   IndexableField f = null;
>   try {
> f = fromString(field, String.valueOf(value));
>   } catch (Exception e) {
> log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", e);
> return null;
>   }
>   return f;
> }{code}
> I believe this should throw an error just like a poorly formatted date or 
> other invalid value.



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

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

[jira] [Updated] (SOLR-13304) PreanalyzedField#createField swallows Exception

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13304:

Issue Type: Bug  (was: Improvement)

> PreanalyzedField#createField swallows Exception
> ---
>
> Key: SOLR-13304
> URL: https://issues.apache.org/jira/browse/SOLR-13304
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 8.0, 7.7.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13304.patch
>
>
> The following code allows one to believe that an ill formatted pre-analyzed 
> field has successfully been written unless one is actively monitoring the 
> logs: 
> {code}@Override
> public IndexableField createField(SchemaField field, Object value) {
>   IndexableField f = null;
>   try {
> f = fromString(field, String.valueOf(value));
>   } catch (Exception e) {
> log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", e);
> return null;
>   }
>   return f;
> }{code}
> I believe this should throw an error just like a poorly formatted date or 
> other invalid value.



--
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: PreanalyzeField.createField()

[Gus Heck]

https://issues.apache.org/jira/browse/SOLR-13304

I'll commit in a day or so if nobody chimes in.

On Wed, Mar 6, 2019 at 10:10 PM David Smiley 
wrote:

> That’s nasty; please fix it :-)
>
> On Wed, Mar 6, 2019 at 5:38 PM Gus Heck  wrote:
>
>> I'm wondering what the logic behind eating this exception might be? Is
>> there a good reason for it? (I'm having trouble thinking of one)
>>
>> @Override
>> public IndexableField createField(SchemaField field, Object value) {
>>   IndexableField f = null;
>>   try {
>> f = fromString(field, String.valueOf(value));
>>   } catch (Exception e) {
>> log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", 
>> e);
>> return null;
>>   }
>>   return f;
>> }
>>
>> It seems to me I'd want to know if the contents of a preanalyzed field
>> were unparsable every bit as much as I'd want to know about a badly
>> formatted date? Just came to the realization that a unit test for some code
>> I'm working was giving false positives...
>>
>> -Gus
>>
>>
>> --
> Sent from Gmail Mobile
>


-- 
http://www.the111shift.com

[jira] [Commented] (SOLR-13296) Example of Preanalyzed JSON in ref guide invalid

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13296:


Commit f772e4143eba65d0b92dc2f79abe80da5cbf52d8 in lucene-solr's branch 
refs/heads/branch_8x from Gus Heck
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f772e41 ]

SOLR-13296 fix doc example so that it can be accepted by Solr


> Example of Preanalyzed JSON in ref guide invalid
> 
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I 
> decided to first check that the config could successfully accept a chunk of 
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception 
> writing document id 1 to the index; possible analysis error: startOffset must 
> be non-negative, and endOffset must be >= startOffset, and offsets must not 
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field 
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a 
> patch to make the (mostly nonsensical) example at least technically valid



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

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_172) - Build # 23753 - Failure!

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 59668 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1024625876
 [ecj-lint] Compiling 1246 source files to /tmp/ecj1024625876
 [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: 
/home/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: 
/home/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 
/home/jenkins/workspace/Lucene-Solr-master-Linux/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 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java
 (at line 264)
 [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. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/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] 4. WARNING in 
/home/jenkins/workspace/Lucene-Solr-master-Linux/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] }.unmarshal(in);
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] 

[jira] [Created] (SOLR-13304) PreanalyzedField#createField swallows Exception

[Gus Heck (JIRA)]

Gus Heck created SOLR-13304:
---

 Summary: PreanalyzedField#createField swallows Exception
 Key: SOLR-13304
 URL: https://issues.apache.org/jira/browse/SOLR-13304
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.7.1, 8.0
Reporter: Gus Heck
Assignee: Gus Heck


The following code allows one to believe that an ill formatted pre-analyzed 
field has successfully been written unless one is actively monitoring the logs: 
{code}@Override
public IndexableField createField(SchemaField field, Object value) {
  IndexableField f = null;
  try {
f = fromString(field, String.valueOf(value));
  } catch (Exception e) {
log.warn("Error parsing pre-analyzed field '" + field.getName() + "'", e);
return null;
  }
  return f;
}{code}
I believe this should throw an error just like a poorly formatted date or other 
invalid value.



--
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] [Resolved] (SOLR-13296) Example of Preanalyzed JSON in ref guide invalid

[Gus Heck (JIRA)]

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

Gus Heck resolved SOLR-13296.
-
   Resolution: Fixed
Fix Version/s: 8.1
   master (9.0)

Committed after fixing the misplaced comma that i almost missed due to the next 
bug I'm going to file.

> Example of Preanalyzed JSON in ref guide invalid
> 
>
> Key: SOLR-13296
> URL: https://issues.apache.org/jira/browse/SOLR-13296
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 7.6
>Reporter: Gus Heck
>Priority: Trivial
> Fix For: master (9.0), 8.1
>
> Attachments: SOLR-13296.patch
>
>
> Writing a test for a use case that was pre-analyzing a field for a customer I 
> decided to first check that the config could successfully accept a chunk of 
> preanalyzed json. Thus I grabbed the example in the docs and BOOM
> {code}
> org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
> server at http://127.0.0.1:63302/solr/testCol_shard1_replica_n1: Exception 
> writing document id 1 to the index; possible analysis error: startOffset must 
> be non-negative, and endOffset must be >= startOffset, and offsets must not 
> go backwards startOffset=5,endOffset=8,lastStartOffset=123 for field 
> 'preanalyzed'
> {code}
> Turns out the example has token offsets that go backwards... attaching a 
> patch to make the (mostly nonsensical) example at least technically valid



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