[jira] [Commented] (SOLR-13490) waitForState/registerCollectionStateWatcher can see stale liveNodes data due to (Zk) Watcher race condition

[Lucene/Solr QA (JIRA)]

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

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

| (/) *{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 5 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  2m  6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 53s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 49m  
0s{color} | {color:green} core in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  6m 
44s{color} | {color:green} solrj in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
32s{color} | {color:green} test-framework in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 64m 31s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13490 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12971853/SOLR-13490.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| 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 / abb5ea0 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/436/testReport/ |
| modules | C: solr/core solr/solrj solr/test-framework U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/436/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> waitForState/registerCollectionStateWatcher can see stale liveNodes data due 
> to (Zk) Watcher race condition
> ---
>
> Key: SOLR-13490
> URL: https://issues.apache.org/jira/browse/SOLR-13490
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13490.patch, SOLR-13490.patch, SOLR-13490.patch, 
> SOLR-13490.patch
>
>
> I was investigating some failures in 
> {{TestCloudSearcherWarming.testRepFactor1LeaderStartup}} which lead me to the 
> hunch that {{waitForState}} wasn't ensuring that the predicates registered 
> would always be called if/when a node was shutdown.
> Digging into it a bit more, I found that the root cause seems to be the way 
> the {{CollectionStateWatcher}} / {{CollectionStatePredicate}} APIs pass in 
> *both* the {{DocCollection}}, and the "current" {{liveNodes}} - but are only 
> _triggered_ by the {{StateWatcher}} on the {{state.json}} (which is used to 
> rebuild the {{DocCollection}}) - when the {{CollectionStateWatcher}} / 
> {{CollectionStatePredicate}} are called, they get the "fresh" 
> {{DocCollection}} but they get the _cached_ {{ZkStateReader.liveNodes}}
> Meanwhile, the {{LiveNodeWatcher}} only calls {{refreshLiveNodes()}} only 
> updates {{ZkStateReader.liveNodes}} and triggers any {{LiveNodesListener}} - 
> it does *NOT* invoke any {{CollectionStateWatcher}} that may have replicas 
> hosted on any of changed nodes.
> Since there is no garunteed order that Watchers will be triggered, this means 
> there is a race condition where the following can happen...
>  * client1 has a ZkStateReader with cached {{liveNodes=[N1, N2, N3]}}
>  * client1 registers a 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.2) - Build # 24231 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24231/
Java: 64bit/jdk-11.0.2 -XX:+UseCompressedOops -XX:+UseSerialGC

32 tests failed.
FAILED:  org.apache.solr.DistributedIntervalFacetingTest.test

Error Message:
Error from server at http://127.0.0.1:46589/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46589/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::114]:2/select
at 
__randomizedtesting.SeedInfo.seed([D27048123485A7E6:5A2477C89A79CA1E]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:643)
at 
org.apache.solr.DistributedIntervalFacetingTest.doTestQuery(DistributedIntervalFacetingTest.java:192)
at 
org.apache.solr.DistributedIntervalFacetingTest.testRandom(DistributedIntervalFacetingTest.java:161)
at 
org.apache.solr.DistributedIntervalFacetingTest.test(DistributedIntervalFacetingTest.java:47)
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:566)
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$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1108)
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 

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 79297b9e680a8502d99eaf1c4c600e1c4d2a6b8e in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=79297b9 ]

SOLR-13105: Changes to TOC


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 9b9daab9234e8681c9de23541ed636e33b1e0c97 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b9daab ]

SOLR-13105: Changes to TOC


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 71b153806b5a516bc1b6b77df2677af4eae1001f in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=71b1538 ]

SOLR-13105: Changes to TOC


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 1ac1075f726b281dadd3eb99499d792fc017334c in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1ac1075 ]

SOLR-13105: Changes to TOC


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
Error from server at http://127.0.0.1:43823/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:48293/collection1/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:43823/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:48293/collection1/select
at 
__randomizedtesting.SeedInfo.seed([79CDB87A0EC2866A:F19987A0A03EEB92]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:656)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:635)
at 
org.apache.solr.handler.component.DistributedMLTComponentTest.test(DistributedMLTComponentTest.java:120)
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 

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

[Apache Jenkins Server]

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

All tests passed

Build Log:
[...truncated 64426 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj1915327507
 [ecj-lint] Compiling 1279 source files to /tmp/ecj1915327507
 [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/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
 (at line 219)
 [ecj-lint] return (NamedList) new 
JavaBinCodec(resolver).unmarshal(in);
 [ecj-lint]^^
 [ecj-lint] Resource leak: '' is never closed
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 2. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 788)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] 3. WARNING in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
 (at line 794)
 [ecj-lint] throw new UnsupportedOperationException("must add at least 1 
node first");
 [ecj-lint] 
^^
 [ecj-lint] Resource leak: 'queryRequest' is not closed at this location
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 19)
 [ecj-lint] import javax.naming.Context;
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 20)
 [ecj-lint] import javax.naming.InitialContext;
 [ecj-lint]^^^
 [ecj-lint] The type javax.naming.InitialContext is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 21)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 22)
 [ecj-lint] import javax.naming.NoInitialContextException;
 [ecj-lint]^^
 [ecj-lint] The type javax.naming.NoInitialContextException is not accessible
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^^
 [ecj-lint] Context cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 776)
 [ecj-lint] Context c = new InitialContext();
 [ecj-lint] ^^
 [ecj-lint] InitialContext cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 10. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 779)
 [ecj-lint] } catch (NoInitialContextException e) {
 [ecj-lint]  ^
 [ecj-lint] NoInitialContextException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 11. ERROR in 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
 (at line 781)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] --
 [ecj-lint] 12. WARNING in 

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 8f5bec6322e4b1533fab5f74d15ac7e18860b43d in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f5bec6 ]

SOLR-13105: Regression visualization WIP


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13347) Error writing Transaction log for UUIDField

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-13347:
---

Can't say that it is a bug because we never claimed to support UUID. So, I just 
added to "other changes"

> Error writing Transaction log for UUIDField
> ---
>
> Key: SOLR-13347
> URL: https://issues.apache.org/jira/browse/SOLR-13347
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 7.7, 7.7.1, 8.0
>Reporter: Thomas Wöckinger
>Assignee: Noble Paul
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13347.patch
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> When using Atomic Update, adding a value leads to following Exception
> org.apache.solr.common.SolrException: TransactionLog doesn't know how to 
> serialize class java.util.UUID; try implementing ObjectResolver?
>     at 
> org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252)
>     at 
> org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160)
>     at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
>     at 
> org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657)
>     at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236)
>     at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
>     at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700)
>     at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
>     at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)
>     at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
>     at 
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
>     at 
> 

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/126/

No tests ran.

Build Log:
[...truncated 33811 lines...]
  [mvn] [INFO] -
  [mvn] [INFO] -
  [mvn] [ERROR] COMPILATION ERROR : 
  [mvn] [INFO] -

[...truncated 877 lines...]
BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:680: The 
following error occurred while executing this line:
: Java returned: 1

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

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

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

[Apache Jenkins Server]

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

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

[jira] [Resolved] (SOLR-13550) Allow zplot to automatically create the x axis

[Joel Bernstein (JIRA)]

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

Joel Bernstein resolved SOLR-13550.
---
Resolution: Resolved

> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13550:


Commit 3bc719cfecfd6ac9429aab9bdd1e57a38ba831f9 in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3bc719c ]

SOLR-13550: Update CHANGES.txt


> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13550:


Commit abb5ea0a06ef648da05ba98457b52fc73828e759 in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=abb5ea0 ]

SOLR-13550: Update CHANGES.txt


> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if only the y axis is provided.



--
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-8347) BlendedInfixSuggester to handle multi term matches better

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8347:


| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  6s{color} 
| {color:red} LUCENE-8347 does not apply to master. Rebase required? Wrong 
Branch? See 
https://wiki.apache.org/lucene-java/HowToContribute#Contributing_your_work for 
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8347 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12926717/LUCENE-8347.patch |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/191/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> BlendedInfixSuggester to handle multi term matches better
> -
>
> Key: LUCENE-8347
> URL: https://issues.apache.org/jira/browse/LUCENE-8347
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: 7.3.1
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: LUCENE-8347.patch, LUCENE-8347.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the blendedInfix suggester considers just the first match position 
> when scoring a suggestion.
> From the lucene-dev mailing list :
> "
> If I write more than one term in the query, let's say 
>  
> "Mini Bar Fridge" 
>  
> I would expect in the results something like (note that allTermsRequired=true 
> and the schema weight field always returns 1000)
>  
> - *Mini Bar Fridge* something
> - *Mini Bar Fridge* something else
> - *Mini Bar* something *Fridge*        
> - *Mini Bar* something else *Fridge*
> - *Mini* something *Bar Fridge*
> ...
>  
> Instead I see this: 
>  
> - *Mini Bar* something *Fridge*        
> - *Mini Bar* something else *Fridge*
> - *Mini Bar Fridge* something
> - *Mini Bar Fridge* something else
> - *Mini* something *Bar Fridge*
> ...
>  
> After having a look at the suggester code 
> (BlendedInfixSuggester.createCoefficient), I see that the component takes in 
> account only one position, which is the lowest position (among the three 
> matching terms) within the term vector ("mini" in the example above) so all 
> the suggestions above have the same weight 
> "
> Scope of this Jira issue is to improve the BlendedInfix to better manage 
> those scenarios.



--
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-8743) lucene/queryparser DOMUtils.getAttributeOrFail(Element,String) never fails

[Lucene/Solr QA (JIRA)]

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

Lucene/Solr QA commented on LUCENE-8743:


| (/) *{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 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
44s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  0m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  0m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  0m 36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
29s{color} | {color:green} queryparser in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}  4m 56s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8743 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12963909/LUCENE-8743.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| 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-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 4ba |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | LTS |
|  Test Results | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/190/testReport/ |
| modules | C: lucene/queryparser U: lucene/queryparser |
| Console output | 
https://builds.apache.org/job/PreCommit-LUCENE-Build/190/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> lucene/queryparser DOMUtils.getAttributeOrFail(Element,String) never fails
> --
>
> Key: LUCENE-8743
> URL: https://issues.apache.org/jira/browse/LUCENE-8743
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: LUCENE-8743.patch
>
>
> https://docs.oracle.com/javase/8/docs/api/org/w3c/dom/Element.html#getAttribute-java.lang.String-
>  describes the {{Element.getAttribute}} return value as "The Attr value as a 
> string, or the empty string if that attribute does not have a specified or 
> default value." but {{DOMUtils.getAttributeOrFail}} only checks for {{null}} 
> and so it never fails.



--
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-13490) waitForState/registerCollectionStateWatcher can see stale liveNodes data due to (Zk) Watcher race condition

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-13490:

Attachment: SOLR-13490.patch
Status: Patch Available  (was: Patch Available)

patch updated to use java.util.function.Predicate ... still beasting...

> waitForState/registerCollectionStateWatcher can see stale liveNodes data due 
> to (Zk) Watcher race condition
> ---
>
> Key: SOLR-13490
> URL: https://issues.apache.org/jira/browse/SOLR-13490
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13490.patch, SOLR-13490.patch, SOLR-13490.patch, 
> SOLR-13490.patch
>
>
> I was investigating some failures in 
> {{TestCloudSearcherWarming.testRepFactor1LeaderStartup}} which lead me to the 
> hunch that {{waitForState}} wasn't ensuring that the predicates registered 
> would always be called if/when a node was shutdown.
> Digging into it a bit more, I found that the root cause seems to be the way 
> the {{CollectionStateWatcher}} / {{CollectionStatePredicate}} APIs pass in 
> *both* the {{DocCollection}}, and the "current" {{liveNodes}} - but are only 
> _triggered_ by the {{StateWatcher}} on the {{state.json}} (which is used to 
> rebuild the {{DocCollection}}) - when the {{CollectionStateWatcher}} / 
> {{CollectionStatePredicate}} are called, they get the "fresh" 
> {{DocCollection}} but they get the _cached_ {{ZkStateReader.liveNodes}}
> Meanwhile, the {{LiveNodeWatcher}} only calls {{refreshLiveNodes()}} only 
> updates {{ZkStateReader.liveNodes}} and triggers any {{LiveNodesListener}} - 
> it does *NOT* invoke any {{CollectionStateWatcher}} that may have replicas 
> hosted on any of changed nodes.
> Since there is no garunteed order that Watchers will be triggered, this means 
> there is a race condition where the following can happen...
>  * client1 has a ZkStateReader with cached {{liveNodes=[N1, N2, N3]}}
>  * client1 registers a {{CollectionStateWatcher}} "watcherZ" that cares if 
> "replicaX" of collectionA is on a "down" node
>  * client2 causes shutdown of node N1 which is hosting replicaX
>  * client1's zkStateReader gets a WatchedEvent for state.json of collectionA
>  ** DocCollection for collectionA is rebuilt
>  ** watcherZ is fired w/cached {{liveNodes=[N1, N2, N3]}} and the new 
> DocCollection
>  *** watcherZ sees that replicaX is on N1, but thinks N1 is live
>  *** watcherZ says "everything ok, not the event i was waiting for" and 
> doesn't take any action
>  * client1's zkStateReader gets a WatchedEvent for LIVE_NODES_ZKNODE
>  ** zkStateReader.liveNodes is rebuilt
> ...at no point in this sequence (or after this) will watcherZ be notified 
> fired with the updated liveNodes (unless/until another {{state.json}} change 
> is made for collectionA.
> 
> While this is definitely be problematic in _tests_ that deal with node 
> lifecyle and use things like {{SolrCloudTestCase.waitForState(..., 
> SolrCloudTestCase.clusterShape(...))}} to check for the expected 
> shards/replicas, a cursory search of how/where 
> {{ZkStateReader.waitForState(...)}} and 
> {{ZkStateReader.registerCollectionStateWatcher(...)}} are used in solr-core 
> suggests that could also lead to bad behavior in situations like reacting to 
> shard leader loss, waiting for all leaders of SYSTEM_COLL to come online for 
> upgrade, running PrepRecoveryOp, etc... (anywhere that liveNodes is used by 
> the watcher/predicate)



--
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-13550) Allow zplot to automatically create the x axis

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13550:
--
Description: This ticket will allow the zplot function to automatically 
generate the x axis if  only the y axis is provided.  (was: This ticket will 
allow the zplot function to automatically generate the x axis if the only the y 
axis is provided.)

> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if  only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13550:
--
Description: This ticket will allow the zplot function to automatically 
generate the x axis if only the y axis is provided.  (was: This ticket will 
allow the zplot function to automatically generate the x axis if  only the y 
axis is provided.)

> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13550:
--
Fix Version/s: 8.2

> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



--
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/jdk-11.0.2) - Build # 24230 - Failure!

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.lucene.luke.models.overview.OverviewImplTest.testIsOptimized

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([A4195ADF126C2DAB:F2D2D812C2C8277C]:0)
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.lucene.luke.models.overview.OverviewImplTest.testIsOptimized(OverviewImplTest.java:78)
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:566)
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.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 
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:834)


FAILED:  org.apache.solr.TestDistributedGrouping.test

Error Message:
Error from server at http://127.0.0.1:35003/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::083]:2/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:35003/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://[ff01::083]:2/select
at 
__randomizedtesting.SeedInfo.seed([4A89AD8F3AFDADDB:C2DD92559401C023]:0)
at 

[jira] [Resolved] (SOLR-13551) Fix directional reference in aliases.adoc

[Gus Heck (JIRA)]

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

Gus Heck resolved SOLR-13551.
-
   Resolution: Fixed
Fix Version/s: 8.2

> Fix directional reference in aliases.adoc
> -
>
> Key: SOLR-13551
> URL: https://issues.apache.org/jira/browse/SOLR-13551
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 8.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
> Fix For: 8.2
>
>
> * an alias must not refer to a [Routed 
> Alias|https://lucene.apache.org/solr/guide/8_1/aliases.html#routed-aliases] 
> (see below)
> occurs below the Routed Alias section. Removing the parenthetical since we 
> have a link already.



--
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-13551) Fix directional reference in aliases.adoc

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13551:


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

SOLR-13551 Minor fix in aliases.adoc

(cherry picked from commit 4ba154fd7394bca3123d19306a5afd132bc8)


> Fix directional reference in aliases.adoc
> -
>
> Key: SOLR-13551
> URL: https://issues.apache.org/jira/browse/SOLR-13551
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 8.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
>
> * an alias must not refer to a [Routed 
> Alias|https://lucene.apache.org/solr/guide/8_1/aliases.html#routed-aliases] 
> (see below)
> occurs below the Routed Alias section. Removing the parenthetical since we 
> have a link already.



--
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-13551) Fix directional reference in aliases.adoc

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13551:


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

SOLR-13551 Minor fix in aliases.adoc


> Fix directional reference in aliases.adoc
> -
>
> Key: SOLR-13551
> URL: https://issues.apache.org/jira/browse/SOLR-13551
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: 8.1
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Trivial
>
> * an alias must not refer to a [Routed 
> Alias|https://lucene.apache.org/solr/guide/8_1/aliases.html#routed-aliases] 
> (see below)
> occurs below the Routed Alias section. Removing the parenthetical since we 
> have a link already.



--
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-13550) Allow zplot to automatically create the x axis

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13550:


Commit 28bfe7903ee544394b46f5dac913f6c518bcb05e in lucene-solr's branch 
refs/heads/branch_8x from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=28bfe79 ]

SOLR-13550: Allow zplot to automatically create the x axis


> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



--
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-13490) waitForState/registerCollectionStateWatcher can see stale liveNodes data due to (Zk) Watcher race condition

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-13490:
-

Gah ... it jus occured to me i shouldn't be adding a {{DocCollectionPredicate}} 
interface -- we should just be using a 
{{java.util.function.Predicate}}.

I'll work on simplify the patch in this way...

> waitForState/registerCollectionStateWatcher can see stale liveNodes data due 
> to (Zk) Watcher race condition
> ---
>
> Key: SOLR-13490
> URL: https://issues.apache.org/jira/browse/SOLR-13490
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13490.patch, SOLR-13490.patch, SOLR-13490.patch
>
>
> I was investigating some failures in 
> {{TestCloudSearcherWarming.testRepFactor1LeaderStartup}} which lead me to the 
> hunch that {{waitForState}} wasn't ensuring that the predicates registered 
> would always be called if/when a node was shutdown.
> Digging into it a bit more, I found that the root cause seems to be the way 
> the {{CollectionStateWatcher}} / {{CollectionStatePredicate}} APIs pass in 
> *both* the {{DocCollection}}, and the "current" {{liveNodes}} - but are only 
> _triggered_ by the {{StateWatcher}} on the {{state.json}} (which is used to 
> rebuild the {{DocCollection}}) - when the {{CollectionStateWatcher}} / 
> {{CollectionStatePredicate}} are called, they get the "fresh" 
> {{DocCollection}} but they get the _cached_ {{ZkStateReader.liveNodes}}
> Meanwhile, the {{LiveNodeWatcher}} only calls {{refreshLiveNodes()}} only 
> updates {{ZkStateReader.liveNodes}} and triggers any {{LiveNodesListener}} - 
> it does *NOT* invoke any {{CollectionStateWatcher}} that may have replicas 
> hosted on any of changed nodes.
> Since there is no garunteed order that Watchers will be triggered, this means 
> there is a race condition where the following can happen...
>  * client1 has a ZkStateReader with cached {{liveNodes=[N1, N2, N3]}}
>  * client1 registers a {{CollectionStateWatcher}} "watcherZ" that cares if 
> "replicaX" of collectionA is on a "down" node
>  * client2 causes shutdown of node N1 which is hosting replicaX
>  * client1's zkStateReader gets a WatchedEvent for state.json of collectionA
>  ** DocCollection for collectionA is rebuilt
>  ** watcherZ is fired w/cached {{liveNodes=[N1, N2, N3]}} and the new 
> DocCollection
>  *** watcherZ sees that replicaX is on N1, but thinks N1 is live
>  *** watcherZ says "everything ok, not the event i was waiting for" and 
> doesn't take any action
>  * client1's zkStateReader gets a WatchedEvent for LIVE_NODES_ZKNODE
>  ** zkStateReader.liveNodes is rebuilt
> ...at no point in this sequence (or after this) will watcherZ be notified 
> fired with the updated liveNodes (unless/until another {{state.json}} change 
> is made for collectionA.
> 
> While this is definitely be problematic in _tests_ that deal with node 
> lifecyle and use things like {{SolrCloudTestCase.waitForState(..., 
> SolrCloudTestCase.clusterShape(...))}} to check for the expected 
> shards/replicas, a cursory search of how/where 
> {{ZkStateReader.waitForState(...)}} and 
> {{ZkStateReader.registerCollectionStateWatcher(...)}} are used in solr-core 
> suggests that could also lead to bad behavior in situations like reacting to 
> shard leader loss, waiting for all leaders of SYSTEM_COLL to come online for 
> upgrade, running PrepRecoveryOp, etc... (anywhere that liveNodes is used by 
> the watcher/predicate)



--
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-13551) Fix directional reference in aliases.adoc

[Gus Heck (JIRA)]

Gus Heck created SOLR-13551:
---

 Summary: Fix directional reference in aliases.adoc
 Key: SOLR-13551
 URL: https://issues.apache.org/jira/browse/SOLR-13551
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: documentation
Affects Versions: 8.1
Reporter: Gus Heck
Assignee: Gus Heck


* an alias must not refer to a [Routed 
Alias|https://lucene.apache.org/solr/guide/8_1/aliases.html#routed-aliases] 
(see below)

occurs below the Routed Alias section. Removing the parenthetical since we have 
a link already.



--
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-13347) Error writing Transaction log for UUIDField

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-13347:
-

This is a bug fix; [~noble.paul] why did you add it to CHANGES.txt under "Other 
Changes" ?  If I'm right... then I also suggest rewording it so that it doesn't 
seam like a feature / optimization :)

Also, thanks for attention to detail in avoiding potential javabin 
compatibility.

> Error writing Transaction log for UUIDField
> ---
>
> Key: SOLR-13347
> URL: https://issues.apache.org/jira/browse/SOLR-13347
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 7.7, 7.7.1, 8.0
>Reporter: Thomas Wöckinger
>Assignee: Noble Paul
>Priority: Major
>  Labels: pull-request-available, ready-to-commit, test
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13347.patch
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> When using Atomic Update, adding a value leads to following Exception
> org.apache.solr.common.SolrException: TransactionLog doesn't know how to 
> serialize class java.util.UUID; try implementing ObjectResolver?
>     at 
> org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252)
>     at 
> org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100)
>     at 
> org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160)
>     at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684)
>     at 
> org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51)
>     at 
> org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657)
>     at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573)
>     at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289)
>     at 
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236)
>     at 
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76)
>     at 
> org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216)
>     at 
> org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700)
>     at 
> org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
>     at 
> org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235)
>     at 
> org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300)
>     at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
>     at 
> org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
>     at 
> org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123)
>     at 
> org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70)
>     at 
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)

[jira] [Commented] (SOLR-13550) Allow zplot to automatically create the x axis

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13550:


Commit 0038e936671fa7798360ff09c02d4d33c6907eb8 in lucene-solr's branch 
refs/heads/master from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0038e93 ]

SOLR-13550: Allow zplot to automatically create the x axis


> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-13550:
--
Summary: Allow zplot to automatically create the x axis  (was: Allow zplot 
to automatically create the x axis.)

> Allow zplot to automatically create the x axis
> --
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



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

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

[GitHub] [lucene-solr] ctargett closed pull request #368: [SOLR-12304] More Like This component interesting term fix +tests

[GitBox]

ctargett closed pull request #368: [SOLR-12304] More Like This component 
interesting term fix +tests
URL: https://github.com/apache/lucene-solr/pull/368
 
 
   


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] ctargett commented on issue #368: [SOLR-12304] More Like This component interesting term fix +tests

[GitBox]

ctargett commented on issue #368: [SOLR-12304] More Like This component 
interesting term fix +tests
URL: https://github.com/apache/lucene-solr/pull/368#issuecomment-502289709
 
 
   It looks like this PR was superseded by a patch in SOLR-12304; that is 
resolved, so closing this.


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


With regards,
Apache Git Services

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

Re: VOTE: Apache Solr Reference Guide for Solr 8.1

[Gus Heck]

Noticed one thing that probably isn't enough to re-spin, but I'll fix for
future:

on Aliases page

   - an alias must not refer to a Routed Alias
    (see
   below)

shows up at the bottom of the page, and should say (see above) or omit the
parentheses entirely.

On Fri, Jun 14, 2019 at 5:32 PM Đạt Cao Mạnh 
wrote:

> +1
>
> On Fri, Jun 14, 2019 at 9:39 PM Jan Høydahl  wrote:
>
>> +1
>>
>> Jan Høydahl
>>
>> 12. jun. 2019 kl. 16:47 skrev Cassandra Targett :
>>
>> Please vote to release the Solr Reference Guide for 8.1
>>
>> The PDF artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.1-RC1/
>>
>> $ cat apache-solr-ref-guide-8.1.pdf.sha512
>> cc76882fb3061fa03d1aa291d9705c1df17f948ff47f3f7d6a18e8ddef907f1c74f078ed482f7f5e04b7c6779a88ad85297cd31ae03570db2acc5930ba2feaf0
>>  apache-solr-ref-guide-8.1.pdf
>>
>> The HTML version is also available:
>> https://lucene.apache.org/solr/guide/8_1
>>
>> Here's my +1.
>>
>> Thanks,
>> Cassandra
>>
>>
>
> --
> *Best regards,*
> *Cao Mạnh Đạt*
> *E-mail: caomanhdat...@gmail.com *
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

[jira] [Assigned] (SOLR-13391) Add variance and standard deviation stream evaluators

[Cassandra Targett (JIRA)]

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

Cassandra Targett reassigned SOLR-13391:


Assignee: Joel Bernstein

> Add variance and standard deviation stream evaluators
> -
>
> Key: SOLR-13391
> URL: https://issues.apache.org/jira/browse/SOLR-13391
> Project: Solr
>  Issue Type: Improvement
>  Components: streaming expressions
>Reporter: Nazerke Seidan
>Assignee: Joel Bernstein
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 8.1
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> It seems variance and standard deviation stream evaluators are not supported 
> by any of the solr version. For example, 
>               let(echo="m,v,sd", arr=array(1,3,3), m=mean(a), v=var(a), 
> sd=stddev(a))
> So far, only the mean function is implemented. I think it is useful to have 
> var and sttdev functions separately as a stream evaluator. 



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

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

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

[Apache Jenkins Server]

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

No tests ran.

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

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

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

[jira] [Updated] (SOLR-13439) Make collection properties easier and safer to use in code

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13439:

Fix Version/s: (was: master (9.0))

> Make collection properties easier and safer to use in code
> --
>
> Key: SOLR-13439
> URL: https://issues.apache.org/jira/browse/SOLR-13439
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13439.patch, SOLR-13439.patch, SOLR-13439.patch
>
>
> (breaking this out from SOLR-13420, please read there for further background)
> Before this patch the api is quite confusing (IMHO):
>  # any code that wanted to know what the properties for a collection are 
> could call zkStateReader.getCollectionProperties(collection) but this was a 
> dangerous and trappy API because that was a query to zookeeper every time. If 
> a naive user auto-completed that in their IDE without investigating, heavy 
> use of zookeeper would ensue.
>  # To "do it right" for any code that might get called on a per-doc or per 
> request basis one had to cause caching by registering a watcher. At which 
> point the getCollectionProperties(collection) magically becomes safe to use, 
> but the watcher pattern probably looks famillar induces a user who hasn't 
> read the solr code closely to create their own cache and update it when their 
> watcher is notified. If the caching side effect of watches isn't understood 
> this will lead to many in-memory copies of collection properties maintained 
> in user code.
>  # This also creates a task to be scheduled on a thread (PropsNotification) 
> and induces an extra thread-scheduling lag before the changes can be observed 
> by user code.
>  # The code that cares about collection properties needs to have a lifecycle 
> tied to either a collection or something other object with an even more 
> ephemeral life cycle such as an URP. The user now also has to remember to 
> ensure the watch is unregistered, or there is a leak.
> After this patch
>  # Calls to getCollectionProperties(collection) are always safe to use in any 
> code anywhere. Caching and cleanup are automatic.
>  # Code that really actually wants to know if a collection property changes 
> so it can wake up and do something (autoscaling?) still has the option of 
> registering a watcher that will asynchronously send them a notification.
>  # Updates can be observed sooner via getCollectionProperties with no need to 
> wait for a thread to run. (vs a cache held in user code)



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

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

[jira] [Updated] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties

[Gus Heck (JIRA)]

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

Gus Heck updated SOLR-13420:

Fix Version/s: (was: master (9.0))

> Allow Routed Aliases to use Collection Properties instead of core properties
> 
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch, 
> SOLR-13420.patch, SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named 
> routedAliasName to detect when the Routed Alias wrapper URP should be applied 
> to Distributed Update Request Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are 
> written to the file system for every core. To support a unit test for 
> SOLR-13419 I need to create some legacy formatted collection names, and 
> arrange them into a TRA, but this is impossible due to the fact that I can't 
> change the core property from the test. There's a TODO dating back to the 
> original TRA implementation in the routed alias code to switch to collection 
> properties instead, so this ticket will address that TODO to support the test 
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be 
> maintained. I also expect that this will facilitate some more nimble handling 
> or routed aliases with future auto-scaling capabilities such as possibly 
> detaching and archiving collections to cheaper, slower machines rather than 
> deleting them. (presently such a collection would still attempt to use the 
> routed alias if it received an update even if it were no longer in the list 
> of collections for the alias)



--
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: Apache Solr Reference Guide for Solr 8.1

[Đạt Cao Mạnh]

+1

On Fri, Jun 14, 2019 at 9:39 PM Jan Høydahl  wrote:

> +1
>
> Jan Høydahl
>
> 12. jun. 2019 kl. 16:47 skrev Cassandra Targett :
>
> Please vote to release the Solr Reference Guide for 8.1
>
> The PDF artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.1-RC1/
>
> $ cat apache-solr-ref-guide-8.1.pdf.sha512
> cc76882fb3061fa03d1aa291d9705c1df17f948ff47f3f7d6a18e8ddef907f1c74f078ed482f7f5e04b7c6779a88ad85297cd31ae03570db2acc5930ba2feaf0
>  apache-solr-ref-guide-8.1.pdf
>
> The HTML version is also available:
> https://lucene.apache.org/solr/guide/8_1
>
> Here's my +1.
>
> Thanks,
> Cassandra
>
>

-- 
*Best regards,*
*Cao Mạnh Đạt*
*E-mail: caomanhdat...@gmail.com *

Re: Use of JIRA fixVersion

[Gus Heck]

FWIW I tend to agree with Erick here on both his points, but the second one
more strongly than the first. The first I can live with either way really
so long as it's clearly documented somewhere (besides this thread).

If we don't update the changes in master for bug fixes when we're
committing, who's going to go collect and add them later? I'm not sure I'm
that big a fan of generating changes... I haven't looked at Yetus
specifically but I suspect that this will just leave us with the title from
the Jira, and often some additional detail for changes is worthwhile beyond
what the title says. So if we create a field in Jira that is the Changes
text, and make it required in the resolution screen fine to generate from
that, but I think there's real value in the current system because you wind
up writing a final short 1-4 line summary focused on "what the user needs
to know"

Also line 3, the feature only in 8x (but not master) is a very odd case in
that table, I'm not sure when that would happen? could happen for a bug
that is fixed by other changes in master, but for a feature?

Also if we aren't marking branches explicitly maybe the 9.0 (master) tag
should say 9.0 (unreleased)? Sure most developers know master is typically
unreleased, but why add that mental leap. It's possible that someone less
technical, or who is a student will stumble in from a link on SO...

-Gus

On Thu, Jun 13, 2019 at 3:23 PM David Smiley 
wrote:

> +1 to your plan Jan.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl  wrote:
>
>> Trying to reach a conclusion (or perhaps a vote) on this.
>>
>> Here is a table that sums up my proposal. Basically it means in most
>> cases stop adding master as fixVersion.
>>
>> Type Committed to fixVersion CHANGES.txt section
>> Feature master master (9.0) 9.0
>> Feature master, branch_8x 8.2 8.2
>> Feature branch_8x 8.2 8.2
>> Bugfix master master (9.0) none (unreleased bug)
>> Bugfix master, branch_8x 8.2 8.2
>> Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2
>> Bugfix branch_8x 8.2 8.2
>> Bugfix branch_8_1 8.1.2 8.1.2
>> Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2
>>
>> In addition to this, we should all wait until commit time with setting
>> fixVersion.
>>
>> To find branches for a JIRA, you just translate fixVersion to branch,
>> e.g. 8.1.2, 8.2 -> branch_8_1, branch_8x.
>> For features, if it is unclear whether master has the commit, check
>> gitbot log or git log
>> For bugfixes, there are cases where the bug does not exist in master at
>> all, and that can be reflected in affectsVersion field.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> 3. jun. 2019 kl. 19:56 skrev David Smiley :
>>
>> Right JIRA fixVersion has its use, and that would satisfy this
>> use-case?  It's what Jan proposes to do this very thing as part of
>> generating release notes in a semi-automated way.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson 
>> wrote:
>>
>>>
>>>
>>> > On Jun 3, 2019, at 6:41 AM, David Smiley 
>>> wrote:
>>> >
>>> > If someone wants to know what branches an issue was committed to, then
>>> review the bot comments to find out.
>>>
>>> What if I want to form a query that shows me all JIRAs fixed in version
>>> X.Y.Z?
>>>
>>> A bot comments with “branch_5x” doesn’t tell me which minor version it’s
>>> in, 5.1? 5.5?
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

[jira] [Commented] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-7530:


[~munendrasn], you are welcome! SOLR-1 is done.

> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
>  Issue Type: Bug
>  Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON 
> response if parameter distrib is true or false. If distrib=true JSON is not 
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{ 
>   "status":0, 
>   "QTime":3
> }, 
> "terms":{ 
> "FileType":
> [ 
>   "EMAIL",20060, 
>   "PDF",7051, 
>   "IMAGE",5108, 
>   "OFFICE",4912, 
>   "TXT",4405, 
>   "OFFICE_EXCEL",4122, 
>   "OFFICE_WORD",2468
>   ]
> } } 
> JSON Response when distrib=true. Incorrect response:
> { 
> "responseHeader":{
>   "status":0, 
>   "QTime":94
> }, 
> "terms":{ 
> "FileType":{ 
>   "EMAIL":31923, 
>   "PDF":11545, 
>   "IMAGE":9807, 
>   "OFFICE_EXCEL":8195, 
>   "OFFICE":5147, 
>   "OFFICE_WORD":4820, 
>   "TIFF":1156, 
>   "XML":851, 
>   "HTML":821, 
>   "RTF":303
>   } 
> } } 



--
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-13333) terms.ttf=true doesn't work when distrib=false and terms.list is not specified

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-1:

   Resolution: Fixed
Fix Version/s: 8.2
   Status: Resolved  (was: Patch Available)

> terms.ttf=true doesn't work when distrib=false and terms.list is not specified
> --
>
> Key: SOLR-1
> URL: https://issues.apache.org/jira/browse/SOLR-1
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-1.patch, SOLR-1.patch
>
>
> In SOLR-10349, support to return total term frequency was added. This works 
> fine in distributed mode or when terms.list is specified but doesn't work 
> with non-distributed mode.



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

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

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

[Apache Jenkins Server]

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

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([4F0A3CA46E6BCCE7]: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([4F0A3CA46E6BCCE7]:0)




Build Log:
[...truncated 15971 lines...]
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-8.x/solr/build/solr-core/test/J2/temp/solr.cloud.OverseerTest_4F0A3CA46E6BCCE7-001/init-core-data-001
   [junit4]   2> 768481 WARN  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=3 numCloses=3
   [junit4]   2> 768482 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 768488 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 768488 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> 768490 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 768491 INFO  (ZkTestServer Run Thread) [ ] 
o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 768491 INFO  (ZkTestServer Run Thread) [ ] 
o.a.s.c.ZkTestServer Starting server
   [junit4]   2> 768591 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.ZkTestServer start zk server on port:45531
   [junit4]   2> 768591 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:45531
   [junit4]   2> 768591 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.ZkTestServer connecting to 127.0.0.1 45531
   [junit4]   2> 768608 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 768639 INFO  (zkConnectionManagerCallback-2083-thread-1) [ 
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 768639 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 768699 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 768727 INFO  (zkConnectionManagerCallback-2085-thread-1) [ 
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 768727 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 768727 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 initCore
   [junit4]   2> 768727 INFO  
(SUITE-OverseerTest-seed#[4F0A3CA46E6BCCE7]-worker) [ ] 
o.a.s.SolrTestCaseJ4 initCore end
   [junit4]   2> 768739 INFO  
(TEST-OverseerTest.testLatchWatcher-seed#[4F0A3CA46E6BCCE7]) [ ] 
o.a.s.SolrTestCaseJ4 ###Starting testLatchWatcher
   [junit4]   2> 768853 INFO  
(TEST-OverseerTest.testLatchWatcher-seed#[4F0A3CA46E6BCCE7]) [ ] 
o.a.s.SolrTestCaseJ4 ###Ending testLatchWatcher
   [junit4]   2> 768859 INFO  
(TEST-OverseerTest.testExceptionWhenFlushClusterState-seed#[4F0A3CA46E6BCCE7]) 
[ ] o.a.s.SolrTestCaseJ4 ###Starting testExceptionWhenFlushClusterState
   [junit4]   2> 768959 INFO  
(TEST-OverseerTest.testExceptionWhenFlushClusterState-seed#[4F0A3CA46E6BCCE7]) 
[ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 768967 INFO  (zkConnectionManagerCallback-2091-thread-1) [ 
] o.a.s.c.c.ConnectionManager zkClient has connected
   [junit4]   2> 768967 INFO  
(TEST-OverseerTest.testExceptionWhenFlushClusterState-seed#[4F0A3CA46E6BCCE7]) 
[ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 768987 WARN  
(TEST-OverseerTest.testExceptionWhenFlushClusterState-seed#[4F0A3CA46E6BCCE7]) 
[ ] o.a.s.c.s.i.Http2SolrClient Create Http2SolrClient with HTTP/1.1 
transport since Java 8 or lower versions does not support SSL + HTTP/2
   [junit4]   2> 768988 WARN  

[GitHub] [lucene-solr] ctargett commented on issue #432: LUCENE-8438: RAMDirectory speed improvements and cleanup

[GitBox]

ctargett commented on issue #432: LUCENE-8438: RAMDirectory speed improvements 
and cleanup
URL: https://github.com/apache/lucene-solr/pull/432#issuecomment-502257142
 
 
   I think this can be closed since from the commits here the branch was merged 
with master back in Aug 2018, and the corresponding Jira issue is resolved.


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] ctargett closed pull request #432: LUCENE-8438: RAMDirectory speed improvements and cleanup

[GitBox]

ctargett closed pull request #432: LUCENE-8438: RAMDirectory speed improvements 
and cleanup
URL: https://github.com/apache/lucene-solr/pull/432
 
 
   


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] ctargett commented on issue #582: Change heap array init index to 1

[GitBox]

ctargett commented on issue #582: Change heap array init index to 1
URL: https://github.com/apache/lucene-solr/pull/582#issuecomment-502256518
 
 
   Removed Jira link to LUCENE-582 in the title, as that issue was resolved in 
2008. Since this PR is #582, I suspect the PR and issue ID were confused.
   
   I cannot find a corresponding Jira issue for this in our system, I'd 
recommend to @hanbj to create one at 
https://issues.apache.org/jira/projects/LUCENE.


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


With regards,
Apache Git Services

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

Re: Github PRs without attached JIRA issue

[Jan Høydahl]

Thanks for mentioning. I’m adding a README.md to the scripts folder soon. It 
will mention this prerequisite:

pip3 install -r requirements.txt

In the requirements file we’ll also gather dependencies for other scripts in 
the folder.

Jan Høydahl

> 14. jun. 2019 kl. 22:26 skrev Cassandra Targett :
> 
> Nice script Jan, thanks.
> 
> Just a note for others who may have a less than complete python setup 
> already, I needed to install pygithub and jira modules to get it to run:
> 
> pip install pygithub
> pip install jira
> 
> Cassandra
>> On Jun 14, 2019, 7:11 AM -0500, Jan Høydahl , wrote:
>> I closed PR #165, #146, #444, #711 and #651
>> 
>> I checked in the python script so you may try to run it for yourself
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 14. jun. 2019 kl. 13:20 skrev Jan Høydahl :
>>> 
>>> I wrote a script to find PRs without JIRA in title and to find PRs where 
>>> corresponding JIRA is closed. The output is below.
>>> I could also extend the tool with options to also add a comment to the PRs 
>>> lacking issue in title, and to close the PRs where JIRA is resolved :)
>>> 
>>> 
>>> usage: githubPRs.py [-h] [--json] [--token TOKEN]
>>> 
>>> Find open Pull Requests that need attention
>>> 
>>> optional arguments:
>>>   -h, --help show this help message and exit
>>>   --json Output as json
>>>   --token TOKEN  Github access token in case you query too often anonymously
>>> 
>>> 
>>> 
>>> Lucene/Solr Github PR report
>>> 
>>> Number of open Pull Requests: 203
>>> Processing...
>>> 
>>> PRs lacking JIRA reference in title
>>>   #717: Code cleanup - Avoid using stream filter count where possible
>>>   #711: Solr 12013
>>>   #673: Replace instances of Math.random with Random.nextDouble
>>>   #669: Facet2d
>>>   #639: Solve the problem of highlighting Chinese inaccurately.
>>>   #622: Update Tessellator logic to label if triangle edges belongs to the 
>>> original polygon.
>>>   #615: Intervals Query Parser
>>>   #602: docu change: use class TopDocs instead of Hits
>>>   #601: Adding reader settings for moving fst offheap
>>>   #596: Under this branch, the dataDimensionCount is definitely not zero.
>>>   #595: Load freqs lazily in Postings
>>>   #564: prorated early termination
>>>   #542: LuceneLevenshteinDistance computes distance values outside of 
>>> interval [0, 1]
>>>   #508: Simplified JAVA_VER_NUM to utilize single expr execution
>>>   #507: Update jira/gradle to the latest master
>>>   #492: Answer to TODO: Replace Manual Encoding with JSON Module
>>>   #491: Update for multiple term's suggestion scoring
>>>   #484: solr 7.5 suggest The recommended result is empty
>>>   #478: Query Source Tracker custom component
>>>   #450: Add rule exception for "imento" and "mento" suffix
>>>   #442: Fixing an edge case bug when overriding a default 
>>> PostingsSolrHighligher
>>>   #415: Solr 12458
>>>   #405: don't die when java prints tool options
>>>   #404: Comment to explain how to use URLClassifyProcessorFactory
>>>   #399: fix explicit type declaration
>>>   #393: Lucene 8347
>>>   #388: Update package-info.java
>>>   #387: Solr-12421
>>>   #383: In ContextQuery, use a more comprehensive check for an empty prefix 
>>> automaton.
>>>   #379: add ë, ö and ï to norm()
>>>   #350: SOLR match mode change for the rouding off instead of taking floor
>>>   #340: Add SolrConfig to SolrRequestParsers constructor in 
>>> EmbeddedSolrServer
>>>   #309: Update ZkConfigManager.java
>>>   #308: Add a suggester that operates on tokenized values from a field
>>>   #293: spellcheck prefix already contains a trailing dot
>>>   #292: Removed extra whitespace
>>>   #272: Correct inconsistency on plugin support
>>>   #242: a little error about TopDocs
>>>   #241: SpanishLightStemmer fix for plural words like casas
>>>   #234: Made minor changes to docstring to fix wording errors
>>>   #231: WordDelimiterGraphFilter: Better support for camel case splitting.
>>>   #219: TieredMergePolicy.findMerges improvements
>>>   #218: feat: Separate SuggestModes for WordBreak and WordJoin
>>>   #217: added initial .travis.yml
>>>   #201: Allocate ArrayList with exact size
>>>   #175: Skipping merger
>>>   #153: Fix issues reported by findbugs
>>>   #152: Added log prior calculations in CachingNaiveBayesClassifier.
>>>   #133: Prevent memory leaks in PerFieldAnalyzerWrapper
>>>   #131: Fix peer sync replcation test check
>>>   #124: fix small issue in solr shell script
>>>   #116: fixed NPEs
>>>   #110: Update SearchFiles.java
>>>   #108: Minor - Fix error message
>>>   #85: Allow updating configs like port # on forced upgrade
>>>   #48: moved common string to constant file
>>>   #22: Update files.js
>>>   #8: Do not log error messages, if client has been interrupted
>>> 
>>> Open PRs with a resolved JIRA
>>> Processing...
>>>   #643: SOLR-13391 status=Resolved, resolution=Resolved, 
>>> resolutiondate=2019-04-12T14:09:27.000+ 

Re: VOTE: Apache Solr Reference Guide for Solr 8.1

[Jan Høydahl]

+1

Jan Høydahl

> 12. jun. 2019 kl. 16:47 skrev Cassandra Targett :
> 
> Please vote to release the Solr Reference Guide for 8.1
> 
> The PDF artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.1-RC1/
> 
> $ cat apache-solr-ref-guide-8.1.pdf.sha512 
> cc76882fb3061fa03d1aa291d9705c1df17f948ff47f3f7d6a18e8ddef907f1c74f078ed482f7f5e04b7c6779a88ad85297cd31ae03570db2acc5930ba2feaf0
>   apache-solr-ref-guide-8.1.pdf
> 
> The HTML version is also available: https://lucene.apache.org/solr/guide/8_1
> 
> Here's my +1.
> 
> Thanks,
> Cassandra

[jira] [Commented] (SOLR-13338) HdfsAutoAddReplicasIntegrationTest failures

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-13338:
-

Now that Jetty was upgraded (SOLR-13413 / SOLR-13541), will check on the test 
failures for this test and see if they start to get better.

> HdfsAutoAddReplicasIntegrationTest failures
> ---
>
> Key: SOLR-13338
> URL: https://issues.apache.org/jira/browse/SOLR-13338
> Project: Solr
>  Issue Type: Test
>  Components: Hadoop Integration, hdfs, Tests
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Minor
>
> HdfsAutoAddReplicasIntegrationTest failures have increased after SOLR-13330 
> (previously failed a different way with SOLR-13060), but they are starting to 
> reproduce and beasting causes failures locally. They fail the same each time. 
> Planning to figure out what is going on.



--
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-13537) Build Status Badge in git README

[JIRA]

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

Jan Høydahl commented on SOLR-13537:


I’m not sure how useful this is? What would it mean to a casual user or sevOps 
if the badge is red? Or green? Since our tests are advanced integration tests, 
they go up and down every second day, and we have a bunch of known flaky tests. 
Lucene devs know this and look at the last N test runs to judge quality of the 
code.

If we had a way to run just plain unit tests and precommit that would be a 
better build state badge candidate.

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple 
> Artifact Build Badge.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



--
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-13550) Allow zplot to automatically create the x axis.

[Joel Bernstein (JIRA)]

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

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

> Allow zplot to automatically create the x axis.
> ---
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-13550.patch
>
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



--
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: Github PRs without attached JIRA issue

[Cassandra Targett]

Nice script Jan, thanks.

Just a note for others who may have a less than complete python setup already, 
I needed to install pygithub and jira modules to get it to run:

pip install pygithub
pip install jira

Cassandra
On Jun 14, 2019, 7:11 AM -0500, Jan Høydahl , wrote:
> I closed PR #165, #146, #444, #711 and #651
>
> I checked in the python script so you may try to run it for yourself
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 14. jun. 2019 kl. 13:20 skrev Jan Høydahl :
> >
> > I wrote a script to find PRs without JIRA in title and to find PRs where 
> > corresponding JIRA is closed. The output is below.
> > I could also extend the tool with options to also add a comment to the PRs 
> > lacking issue in title, and to close the PRs where JIRA is resolved :)
> >
> >
> > usage: githubPRs.py [-h] [--json] [--token TOKEN]
> >
> > Find open Pull Requests that need attention
> >
> > optional arguments:
> >   -h, --help     show this help message and exit
> >   --json         Output as json
> >   --token TOKEN  Github access token in case you query too often anonymously
> >
> >
> >
> > Lucene/Solr Github PR report
> > 
> > Number of open Pull Requests: 203
> > Processing...
> >
> > PRs lacking JIRA reference in title
> >   #717: Code cleanup - Avoid using stream filter count where possible
> >   #711: Solr 12013
> >   #673: Replace instances of Math.random with Random.nextDouble
> >   #669: Facet2d
> >   #639: Solve the problem of highlighting Chinese inaccurately.
> >   #622: Update Tessellator logic to label if triangle edges belongs to the 
> > original polygon.
> >   #615: Intervals Query Parser
> >   #602: docu change: use class TopDocs instead of Hits
> >   #601: Adding reader settings for moving fst offheap
> >   #596: Under this branch, the dataDimensionCount is definitely not zero.
> >   #595: Load freqs lazily in Postings
> >   #564: prorated early termination
> >   #542: LuceneLevenshteinDistance computes distance values outside of 
> > interval [0, 1]
> >   #508: Simplified JAVA_VER_NUM to utilize single expr execution
> >   #507: Update jira/gradle to the latest master
> >   #492: Answer to TODO: Replace Manual Encoding with JSON Module
> >   #491: Update for multiple term's suggestion scoring
> >   #484: solr 7.5 suggest The recommended result is empty
> >   #478: Query Source Tracker custom component
> >   #450: Add rule exception for "imento" and "mento" suffix
> >   #442: Fixing an edge case bug when overriding a default 
> > PostingsSolrHighligher
> >   #415: Solr 12458
> >   #405: don't die when java prints tool options
> >   #404: Comment to explain how to use URLClassifyProcessorFactory
> >   #399: fix explicit type declaration
> >   #393: Lucene 8347
> >   #388: Update package-info.java
> >   #387: Solr-12421
> >   #383: In ContextQuery, use a more comprehensive check for an empty prefix 
> > automaton.
> >   #379: add ë, ö and ï to norm()
> >   #350: SOLR match mode change for the rouding off instead of taking floor
> >   #340: Add SolrConfig to SolrRequestParsers constructor in 
> > EmbeddedSolrServer
> >   #309: Update ZkConfigManager.java
> >   #308: Add a suggester that operates on tokenized values from a field
> >   #293: spellcheck prefix already contains a trailing dot
> >   #292: Removed extra whitespace
> >   #272: Correct inconsistency on plugin support
> >   #242: a little error about TopDocs
> >   #241: SpanishLightStemmer fix for plural words like casas
> >   #234: Made minor changes to docstring to fix wording errors
> >   #231: WordDelimiterGraphFilter: Better support for camel case splitting.
> >   #219: TieredMergePolicy.findMerges improvements
> >   #218: feat: Separate SuggestModes for WordBreak and WordJoin
> >   #217: added initial .travis.yml
> >   #201: Allocate ArrayList with exact size
> >   #175: Skipping merger
> >   #153: Fix issues reported by findbugs
> >   #152: Added log prior calculations in CachingNaiveBayesClassifier.
> >   #133: Prevent memory leaks in PerFieldAnalyzerWrapper
> >   #131: Fix peer sync replcation test check
> >   #124: fix small issue in solr shell script
> >   #116: fixed NPEs
> >   #110: Update SearchFiles.java
> >   #108: Minor - Fix error message
> >   #85: Allow updating configs like port # on forced upgrade
> >   #48: moved common string to constant file
> >   #22: Update files.js
> >   #8: Do not log error messages, if client has been interrupted
> >
> > Open PRs with a resolved JIRA
> > Processing...
> >   #643: SOLR-13391 status=Resolved, resolution=Resolved, 
> > resolutiondate=2019-04-12T14:09:27.000+ (SOLR-13391: Add variance and 
> > standard deviation stream evaluators)
> >   #444: SOLR-12708 status=Closed, resolution=Fixed, 
> > resolutiondate=2019-03-19T03:46:31.000+ (SOLR-12708: Aggregate failures 
> > from downstream async jobs; add error …)
> >   #368: SOLR-12304 status=Resolved, resolution=Fixed, 
> > 

[JENKINS] Lucene-Solr-8.x-Linux (32bit/jdk1.8.0_201) - Build # 707 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/707/
Java: 32bit/jdk1.8.0_201 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.facet.SpatialHeatmapFacetsTest.testJsonFacets

Error Message:
Error from server at https://127.0.0.1:44807/ln/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://[ff01::083]:2/ln/select

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:44807/ln/collection1: 
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://[ff01::083]:2/ln/select
at 
__randomizedtesting.SeedInfo.seed([8708DBF7ADB3E72:2C20925AFF9D48A1]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:656)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
at 
org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:626)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:678)
at 
org.apache.solr.BaseDistributedSearchTestCase.query(BaseDistributedSearchTestCase.java:643)
at 
org.apache.solr.search.facet.SpatialHeatmapFacetsTest.testJsonFacets(SpatialHeatmapFacetsTest.java:223)
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$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1108)
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 

[jira] [Assigned] (SOLR-13550) Allow zplot to automatically create the x axis.

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-13550:
-

Assignee: Joel Bernstein

> Allow zplot to automatically create the x axis.
> ---
>
> Key: SOLR-13550
> URL: https://issues.apache.org/jira/browse/SOLR-13550
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
>
> This ticket will allow the zplot function to automatically generate the x 
> axis if the only the y axis is provided.



--
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-13550) Allow zplot to automatically create the x axis.

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-13550:
-

 Summary: Allow zplot to automatically create the x axis.
 Key: SOLR-13550
 URL: https://issues.apache.org/jira/browse/SOLR-13550
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Reporter: Joel Bernstein


This ticket will allow the zplot function to automatically generate the x axis 
if the only the y axis is provided.



--
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-13439) Make collection properties easier and safer to use in code

[Gus Heck (JIRA)]

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

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

> Make collection properties easier and safer to use in code
> --
>
> Key: SOLR-13439
> URL: https://issues.apache.org/jira/browse/SOLR-13439
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13439.patch, SOLR-13439.patch, SOLR-13439.patch
>
>
> (breaking this out from SOLR-13420, please read there for further background)
> Before this patch the api is quite confusing (IMHO):
>  # any code that wanted to know what the properties for a collection are 
> could call zkStateReader.getCollectionProperties(collection) but this was a 
> dangerous and trappy API because that was a query to zookeeper every time. If 
> a naive user auto-completed that in their IDE without investigating, heavy 
> use of zookeeper would ensue.
>  # To "do it right" for any code that might get called on a per-doc or per 
> request basis one had to cause caching by registering a watcher. At which 
> point the getCollectionProperties(collection) magically becomes safe to use, 
> but the watcher pattern probably looks famillar induces a user who hasn't 
> read the solr code closely to create their own cache and update it when their 
> watcher is notified. If the caching side effect of watches isn't understood 
> this will lead to many in-memory copies of collection properties maintained 
> in user code.
>  # This also creates a task to be scheduled on a thread (PropsNotification) 
> and induces an extra thread-scheduling lag before the changes can be observed 
> by user code.
>  # The code that cares about collection properties needs to have a lifecycle 
> tied to either a collection or something other object with an even more 
> ephemeral life cycle such as an URP. The user now also has to remember to 
> ensure the watch is unregistered, or there is a leak.
> After this patch
>  # Calls to getCollectionProperties(collection) are always safe to use in any 
> code anywhere. Caching and cleanup are automatic.
>  # Code that really actually wants to know if a collection property changes 
> so it can wake up and do something (autoscaling?) still has the option of 
> registering a watcher that will asynchronously send them a notification.
>  # Updates can be observed sooner via getCollectionProperties with no need to 
> wait for a thread to run. (vs a cache held in user 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] [Resolved] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties

[Gus Heck (JIRA)]

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

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

> Allow Routed Aliases to use Collection Properties instead of core properties
> 
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch, 
> SOLR-13420.patch, SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named 
> routedAliasName to detect when the Routed Alias wrapper URP should be applied 
> to Distributed Update Request Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are 
> written to the file system for every core. To support a unit test for 
> SOLR-13419 I need to create some legacy formatted collection names, and 
> arrange them into a TRA, but this is impossible due to the fact that I can't 
> change the core property from the test. There's a TODO dating back to the 
> original TRA implementation in the routed alias code to switch to collection 
> properties instead, so this ticket will address that TODO to support the test 
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be 
> maintained. I also expect that this will facilitate some more nimble handling 
> or routed aliases with future auto-scaling capabilities such as possibly 
> detaching and archiving collections to cheaper, slower machines rather than 
> deleting them. (presently such a collection would still attempt to use the 
> routed alias if it received an update even if it were no longer in the list 
> of collections for the alias)



--
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-13420) Allow Routed Aliases to use Collection Properties instead of core properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13420:


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

SOLR-13420 Routed Aliases now use collection properties instead of core 
properties


> Allow Routed Aliases to use Collection Properties instead of core properties
> 
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch, 
> SOLR-13420.patch, SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named 
> routedAliasName to detect when the Routed Alias wrapper URP should be applied 
> to Distributed Update Request Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are 
> written to the file system for every core. To support a unit test for 
> SOLR-13419 I need to create some legacy formatted collection names, and 
> arrange them into a TRA, but this is impossible due to the fact that I can't 
> change the core property from the test. There's a TODO dating back to the 
> original TRA implementation in the routed alias code to switch to collection 
> properties instead, so this ticket will address that TODO to support the test 
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be 
> maintained. I also expect that this will facilitate some more nimble handling 
> or routed aliases with future auto-scaling capabilities such as possibly 
> detaching and archiving collections to cheaper, slower machines rather than 
> deleting them. (presently such a collection would still attempt to use the 
> routed alias if it received an update even if it were no longer in the list 
> of collections for the alias)



--
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-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 5fd9d35ee54b7617e72a64300fd474a1eec5d638 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5fd9d35 ]

SOLR-13105: Add variables visualizations


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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/jdk-11.0.2) - Build # 24229 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24229/
Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseG1GC

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

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

Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([76FE105051B1A35F:69298C7C22BA5A14]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at 
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:303)
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:566)
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:834)




Build Log:
[...truncated 14507 lines...]
   [junit4] Suite: org.apache.solr.cloud.AliasIntegrationTest
   [junit4]   2> 1177950 INFO  
(SUITE-AliasIntegrationTest-seed#[76FE105051B1A35F]-worker) [ ] 
o.a.s.SolrTestCaseJ4 SecureRandom 

[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second 
grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r293916042
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/search/grouping/distributed/shardresultserializer/SearchGroupsResultTransformer.java
 ##
 @@ -80,50 +106,120 @@ public NamedList transform(List data) throws 
IOException {
   final NamedList> rawSearchGroups = 
(NamedList>) topGroupsAndGroupCount.get(TOP_GROUPS);
   if (rawSearchGroups != null) {
 for (Map.Entry> rawSearchGroup : 
rawSearchGroups){
-  SearchGroup searchGroup = new SearchGroup<>();
-  SchemaField groupField = rawSearchGroup.getKey() != null? 
searcher.getSchema().getFieldOrNull(command.getKey()) : null;
-  searchGroup.groupValue = null;
-  if (rawSearchGroup.getKey() != null) {
-if (groupField != null) {
-  BytesRefBuilder builder = new BytesRefBuilder();
-  groupField.getType().readableToIndexed(rawSearchGroup.getKey(), 
builder);
-  searchGroup.groupValue = builder.get();
-} else {
-  searchGroup.groupValue = new BytesRef(rawSearchGroup.getKey());
-}
-  }
-  searchGroup.sortValues = rawSearchGroup.getValue().toArray(new 
Comparable[rawSearchGroup.getValue().size()]);
-  for (int i = 0; i < searchGroup.sortValues.length; i++) {
-SchemaField field = groupSort.getSort()[i].getField() != null ? 
searcher.getSchema().getFieldOrNull(groupSort.getSort()[i].getField()) : null;
-searchGroup.sortValues[i] = 
ShardResultTransformerUtils.unmarshalSortValue(searchGroup.sortValues[i], 
field);
-  }
-  searchGroups.add(searchGroup);
+  searchGroups.add(deserializeOneSearchGroup(command.getKey(), 
groupSort, rawSearchGroup.getKey(), rawSearchGroup.getValue()));
 }
   }
-
   final Integer groupCount = (Integer) 
topGroupsAndGroupCount.get(GROUP_COUNT);
   result.put(command.getKey(), new 
SearchGroupsFieldCommandResult(groupCount, searchGroups));
 }
 return result;
   }
 
-  private NamedList serializeSearchGroup(Collection> 
data, SearchGroupsFieldCommand command) {
-final NamedList result = new NamedList<>(data.size());
+  public static class DefaultSearchResultResultTransformer extends 
SearchGroupsResultTransformer {
 
-for (SearchGroup searchGroup : data) {
+public DefaultSearchResultResultTransformer(SolrIndexSearcher searcher) {
+  super(searcher);
+}
+
+// given a raw search group will return its array sort values.
+protected Object[] getSortValues(Object groupDocs){
+  List docs = (List)groupDocs;
+  return docs.toArray(new Comparable[docs.size()]);
+}
+
+@Override
+protected SearchGroup deserializeOneSearchGroup(String 
groupField, Sort groupSort, String groupKey, Object rawSearchGroup){
+  SearchGroup searchGroup = new SearchGroup<>();
+  SchemaField schemaGroupField = groupKey != null? 
searcher.getSchema().getFieldOrNull(groupField) : null;
+  searchGroup.groupValue = null;
+  if (groupKey != null) {
+if (schemaGroupField != null) {
+  BytesRefBuilder builder = new BytesRefBuilder();
+  schemaGroupField.getType().readableToIndexed(groupKey, builder);
+  searchGroup.groupValue = builder.get();
+} else {
+  searchGroup.groupValue = new BytesRef(groupKey);
+}
+  }
+  searchGroup.sortValues = getSortValues(rawSearchGroup);
+  for (int i = 0; i < searchGroup.sortValues.length; i++) {
+final String sortField = groupSort.getSort()[i].getField();
+SchemaField field = sortField != null ? 
searcher.getSchema().getFieldOrNull(sortField) : null;
+searchGroup.sortValues[i] = 
ShardResultTransformerUtils.unmarshalSortValue(searchGroup.sortValues[i], 
field);
+  }
+  return searchGroup;
+}
+
+@Override
+protected Object serializeOneSearchGroup(SearchGroup 
searchGroup, SearchGroupsFieldCommand command) {
   Object[] convertedSortValues = new Object[searchGroup.sortValues.length];
   for (int i = 0; i < searchGroup.sortValues.length; i++) {
 Object sortValue = searchGroup.sortValues[i];
 SchemaField field = command.getGroupSort().getSort()[i].getField() != 
null ?
 
searcher.getSchema().getFieldOrNull(command.getGroupSort().getSort()[i].getField())
 : null;
 convertedSortValues[i] = 
ShardResultTransformerUtils.marshalSortValue(sortValue, field);
   }
-  SchemaField field = 
searcher.getSchema().getFieldOrNull(command.getKey());
-  String groupValue = searchGroup.groupValue != null ? 
field.getType().indexedToReadable(searchGroup.groupValue, new 
CharsRefBuilder()).toString() : null;
-  result.add(groupValue, convertedSortValues);
+  return convertedSortValues;
 

[jira] [Commented] (SOLR-13420) Allow Routed Aliases to use Collection Properties instead of core properties

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13420:


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

SOLR-13420 Routed Aliases now use collection properties instead of core 
properties


> Allow Routed Aliases to use Collection Properties instead of core properties
> 
>
> Key: SOLR-13420
> URL: https://issues.apache.org/jira/browse/SOLR-13420
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Major
> Attachments: SOLR-13420.patch, SOLR-13420.patch, SOLR-13420.patch, 
> SOLR-13420.patch, SOLR-13420.patch
>
>
> The current routed alias code is relying on a core property named 
> routedAliasName to detect when the Routed Alias wrapper URP should be applied 
> to Distributed Update Request Processor. 
> {code:java}
> #Written by CorePropertiesLocator
> #Sun Mar 03 06:21:14 UTC 2019
> routedAliasName=testalias21
> numShards=2
> collection.configName=_default
> ... etc...
> {code}
> Core properties are not changeable after the core is created, and they are 
> written to the file system for every core. To support a unit test for 
> SOLR-13419 I need to create some legacy formatted collection names, and 
> arrange them into a TRA, but this is impossible due to the fact that I can't 
> change the core property from the test. There's a TODO dating back to the 
> original TRA implementation in the routed alias code to switch to collection 
> properties instead, so this ticket will address that TODO to support the test 
> required for SOLR-13419.
> Back compatibility with legacy core based TRA's and CRA's will of course be 
> maintained. I also expect that this will facilitate some more nimble handling 
> or routed aliases with future auto-scaling capabilities such as possibly 
> detaching and archiving collections to cheaper, slower machines rather than 
> deleting them. (presently such a collection would still attempt to use the 
> routed alias if it received an update even if it were no longer in the list 
> of collections for the alias)



--
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: Apache Solr Reference Guide for Solr 8.1

[Chris Hostetter]

+1

: Date: Wed, 12 Jun 2019 09:47:39 -0500
: From: Cassandra Targett 
: Reply-To: dev@lucene.apache.org
: To: lucene dev 
: Subject: VOTE: Apache Solr Reference Guide for Solr 8.1
: 
: Please vote to release the Solr Reference Guide for 8.1
: 
: The PDF artifacts can be downloaded from:
: 
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-8.1-RC1/
: 
: $ cat apache-solr-ref-guide-8.1.pdf.sha512
: 
cc76882fb3061fa03d1aa291d9705c1df17f948ff47f3f7d6a18e8ddef907f1c74f078ed482f7f5e04b7c6779a88ad85297cd31ae03570db2acc5930ba2feaf0
:  apache-solr-ref-guide-8.1.pdf
: 
: The HTML version is also available: https://lucene.apache.org/solr/guide/8_1
: 
: Here's my +1.
: 
: Thanks,
: Cassandra
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Updated] (SOLR-13413) jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on intranode requests

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-13413:

Description: 
There is evidence in some recent jenkins failures that we may have some manor 
of bug in our http2 client/server code that can cause intra-node query requests 
to stall / timeout non-reproducibly.

In at least one known case, forcing the jetty & SolrClients used in the test to 
use http1.1, seems to prevent these test failures.


  was:

There is evidence in some recent jenkins failures that we may have some manor 
of bug in our http2 client/server code that can cause intra-node query requests 
to stall / timeout non-reproducibly.

In at least one known case, forcing the jetty & SolrClients used in the test to 
use http1.1, seems to prevent these test failures.


Summary: jetty IdleTimeout bugs with Http2SolrClient, cause sprious 
timeouts on intranode requests  (was: IdleTimeout with Http2SolrClient)

> jetty IdleTimeout bugs with Http2SolrClient, cause sprious timeouts on 
> intranode requests
> -
>
> Key: SOLR-13413
> URL: https://issues.apache.org/jira/browse/SOLR-13413
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 8.0
>Reporter: Hoss Man
>Assignee: Cao Manh Dat
>Priority: Major
> Attachments: SOLR-13413.patch, 
> nocommit_TestDistributedStatsComponentCardinality_trivial-no-http2.patch
>
>
> There is evidence in some recent jenkins failures that we may have some manor 
> of bug in our http2 client/server code that can cause intra-node query 
> requests to stall / timeout non-reproducibly.
> In at least one known case, forcing the jetty & SolrClients used in the test 
> to use http1.1, seems to prevent these test failures.



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

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

[GitHub] [lucene-solr] diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

diegoceccarelli commented on a change in pull request #300: SOLR-11831: Skip 
second grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r293902076
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -232,6 +233,47 @@ public void prepare(ResponseBuilder rb) throws IOException
 }
   }
 
+  // check if prefix is a prefix of the array
+  private static boolean isPrefix(SortField[] prefix, SortField[] array){
 
 Review comment:
   Ah! I think so, let me try!


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-13549:
---

See also 
https://issues.apache.org/jira/browse/SOLR-13434?focusedCommentId=16861794=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16861794

> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



--
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-13549) Maven build fails to build Solr core tests due to missing dependency

[Daniel Collins (JIRA)]

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

Daniel Collins updated SOLR-13549:
--
Description: 
If I run

ant get-maven-poms 
 mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

[https://github.com/apache/lucene-solr/pull/720] for the fix

 

  was:
If I run

ant get-maven-poms 
mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

Will create a simple PR to add that dependency.

 


> Maven build fails to build Solr core tests due to missing dependency
> 
>
> Key: SOLR-13549
> URL: https://issues.apache.org/jira/browse/SOLR-13549
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: master (9.0), 8.2
>Reporter: Daniel Collins
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If I run
> ant get-maven-poms 
>  mvn -f maven-build/pom.xml install -DskipTests
> On master or branch_8x, it fails to build the Solr tests due to a dependency 
> on opentracing-mock.  Eclipse builds fine (because it uses a single classpath 
> with everything in it), and not entirely sure how ant builds...
> But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock 
> (though it has all the other opentracing modules)
> [https://github.com/apache/lucene-solr/pull/720] for the fix
>  



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

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

[GitHub] [lucene-solr] dcollins53 opened a new pull request #720: SOLR-13549: Fix opentracing mock dependency for Solr core tests

[GitBox]

dcollins53 opened a new pull request #720: SOLR-13549: Fix opentracing mock 
dependency for Solr core tests
URL: https://github.com/apache/lucene-solr/pull/720
 
 
   
   
   
   # Description
   
   Adds a dependency on opentracing-mock for the Solr core tests
   
   # Solution
   
   This is just a build fix.
   
   # Tests
   
   Solr builds using maven now.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I am authorized to contribute this code to the ASF and have removed 
any code I do not have a license to distribute.
   - [x] I have developed this patch against the `master` branch.
   - [x] I have run `ant precommit` and the appropriate test suite.
   - [n/a] I have added tests for my changes.
   - [n/a] I have added documentation for the Ref Guide (for Solr changes only).
   


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


With regards,
Apache Git Services

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

[jira] [Created] (SOLR-13549) Maven build fails to build Solr core tests due to missing dependency

[Daniel Collins (JIRA)]

Daniel Collins created SOLR-13549:
-

 Summary: Maven build fails to build Solr core tests due to missing 
dependency
 Key: SOLR-13549
 URL: https://issues.apache.org/jira/browse/SOLR-13549
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Build
Affects Versions: master (9.0), 8.2
Reporter: Daniel Collins


If I run

ant get-maven-poms 
mvn -f maven-build/pom.xml install -DskipTests

On master or branch_8x, it fails to build the Solr tests due to a dependency on 
opentracing-mock.  Eclipse builds fine (because it uses a single classpath with 
everything in it), and not entirely sure how ant builds...

But the solr/core/ivy.xml doesn't have a dependency on opentracing-mock (though 
it has all the other opentracing modules)

Will create a simple PR to add that dependency.

 



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

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

[GitHub] [lucene-solr] jtibshirani edited a comment on issue #715: LUCENE-7714 Add a range query that takes advantage of index sorting.

[GitBox]

jtibshirani edited a comment on issue #715: LUCENE-7714 Add a range query that 
takes advantage of index sorting.
URL: https://github.com/apache/lucene-solr/pull/715#issuecomment-502169956
 
 
   Thanks @jimczi, I pushed another commit to ensure we use the two-phase 
iterator for explain and match.


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] jtibshirani edited a comment on issue #715: LUCENE-7714 Add a range query that takes advantage of index sorting.

[GitBox]

jtibshirani edited a comment on issue #715: LUCENE-7714 Add a range query that 
takes advantage of index sorting.
URL: https://github.com/apache/lucene-solr/pull/715#issuecomment-502169956
 
 
   Thanks @jimczi, I pushed another commit that switches to the two-phase 
iterator for explain and match.


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


With regards,
Apache Git Services

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

[jira] [Commented] (LUCENE-8829) TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8829:
-

[~jpountz] [~simonw] I have updated LUCENE-8857 to remove _setShardIndex_.

 

Please let me know if that approach works, or should we restrict the usage to 
ScoreDocs. Happy to iterate in either direction.

 

 

> TopDocs#Merge is Tightly Coupled To Number Of Collectors Involved
> -
>
> Key: LUCENE-8829
> URL: https://issues.apache.org/jira/browse/LUCENE-8829
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8829.patch, LUCENE-8829.patch, LUCENE-8829.patch, 
> LUCENE-8829.patch
>
>
> While investigating LUCENE-8819, I understood that TopDocs#merge's order of 
> results are indirectly dependent on the number of collectors involved in the 
> merge. This is troubling because 1) The number of collectors involved in a 
> merge are cost based and directly dependent on the number of slices created 
> for the parallel searcher case. 2) TopN hits code path will invoke merge with 
> a single Collector, so essentially, doing the same TopN query with single 
> threaded and parallel threaded searcher will invoke different order of 
> results, which is a bad invariant that breaks.
>  
> The reason why this happens is because of the subtle way TopDocs#merge sets 
> shardIndex in the ScoreDoc population during populating the priority queue 
> used for merging. ShardIndex is essentially set to the ordinal of the 
> collector which generates the hit. This means that the shardIndex is 
> dependent on the number of collectors, even for the same set of hits.
>  
> In case of no sort order specified, shardIndex is used for tie breaking when 
> scores are equal. This translates to different orders for same hits with 
> different shardIndices.
>  
> I propose that we remove shardIndex from the default tie breaking mechanism 
> and replace it with docID. DocID order is the de facto that is expected 
> during collection, so it might make sense to use the same factor during tie 
> breaking when scores are the same.
>  
> CC: [~ivera]



--
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-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

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

Atri Sharma commented on LUCENE-8857:
-

Removed setShardIndex and the ability to set shard index in TopDocs#merge.

 

[^LUCENE-8857.patch]

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch
>
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



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

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

[jira] [Updated] (LUCENE-8857) Refactor TopDocs#Merge To Take In Custom Tie Breakers

[Atri Sharma (JIRA)]

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

Atri Sharma updated LUCENE-8857:

Attachment: LUCENE-8857.patch

> Refactor TopDocs#Merge To Take In Custom Tie Breakers
> -
>
> Key: LUCENE-8857
> URL: https://issues.apache.org/jira/browse/LUCENE-8857
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Atri Sharma
>Priority: Major
> Attachments: LUCENE-8857.patch, LUCENE-8857.patch
>
>
> In LUCENE-8829, the idea of having lambdas passed in to the API to allow 
> finer control over the process was discussed.
> This JIRA tracks adding a parameter to the API which allows passing in 
> lambdas to define custom tie breakers, thus allowing users to do custom 
> algorithms when required.
> CC: [~jpountz]  [~simonw] 



--
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-8855) Add Accountable to Query implementations

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-8855:
--

I had the temptation to make Query implement Accountable a couple times over 
the past years but I never liked it as it felt like something that is only 
really useful in esoteric cases when memory usage of the cache keys - queries - 
is not negligible compared to what is being cached. I'd rather not implement 
Accountable.

My preference would be to either rely on the existing Weight#isCacheable logic, 
which disables caching on large queries (see e.g. 
https://github.com/apache/lucene-solr/blob/fbd05167f455e3ce2b2ead50336e2b9c2521cd6c/lucene/core/src/java/org/apache/lucene/search/TermInSetQuery.java#L337-L342)
 so that queries that are used as cache keys are always small. Or alternatively 
compute a rough estimate of the memory usage of queries on top of the Query API 
by using the query visitor API and some heuristics.

> Add Accountable to Query implementations
> 
>
> Key: LUCENE-8855
> URL: https://issues.apache.org/jira/browse/LUCENE-8855
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
>Priority: Major
> Attachments: LUCENE-8855.patch, LUCENE-8855.patch
>
>
> Query implementations should also support {{Accountable}} API in order to 
> monitor the memory consumption e.g. in caches where either keys or values are 
> {{Query}} instances.



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

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

[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second 
grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r293880060
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -232,6 +233,47 @@ public void prepare(ResponseBuilder rb) throws IOException
 }
   }
 
+  // check if prefix is a prefix of the array
+  private static boolean isPrefix(SortField[] prefix, SortField[] array){
 
 Review comment:
   Not sure. Yes, it's private and static but it seems a relatively long amount 
of what seems quite generic code and when another class needs something like it 
then it would be tricky to discover that the method already exists here and is 
available for relocation?
   
   Having looked around a little, it looks like there's a 
[Collections.indexOfSubList](https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#indexOfSubList-java.util.List-java.util.List-)
 method in Java and if perhaps array-to-list conversion was acceptable then 
something like
   ```
   0 == Collections.indexOfSubList(Arrays.asList(array), Arrays.asList(prefix))
   ```
   might be another alternative?


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


With regards,
Apache Git Services

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

[GitHub] [lucene-solr] cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second grouping step if group.limit is 1 (aka Las Vegas Patch)

[GitBox]

cpoerschke commented on a change in pull request #300: SOLR-11831: Skip second 
grouping step if group.limit is 1 (aka Las Vegas Patch)
URL: https://github.com/apache/lucene-solr/pull/300#discussion_r293878293
 
 

 ##
 File path: 
solr/core/src/java/org/apache/solr/handler/component/QueryComponent.java
 ##
 @@ -288,6 +328,13 @@ protected void prepareGrouping(ResponseBuilder rb) throws 
IOException {
 groupingSpec.setMain(params.getBool(GroupParams.GROUP_MAIN, false));
 groupingSpec.setNeedScore((rb.getFieldFlags() & 
SolrIndexSearcher.GET_SCORES) != 0);
 groupingSpec.setTruncateGroups(params.getBool(GroupParams.GROUP_TRUNCATE, 
false));
+
+
groupingSpec.setSkipSecondGroupingStep(params.getBool(GroupParams.GROUP_SKIP_DISTRIBUTED_SECOND,
 false));
+boolean isReranking = (rb.getRankQuery() != null);
+if (groupingSpec.isSkipSecondGroupingStep() & 
!allowSkipSecondGroupingStep(groupingSpec.getWithinGroupSortSpec(), 
groupingSpec.getGroupSortSpec(), isReranking)){
 
 Review comment:
   Sure, `void` and throwing would work too, good idea, as you say more details 
can be returned that way.


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 990cc1f03663534454aaecf455376aad984e9d09 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=990cc1f ]

SOLR-13105: Fix copy


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



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

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

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

[Policeman Jenkins Server]

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

All tests passed

Build Log:
[...truncated 65016 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir: C:\Users\jenkins\AppData\Local\Temp\ecj1177822560
 [ecj-lint] Compiling 48 source files to 
C:\Users\jenkins\AppData\Local\Temp\ecj1177822560
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\lib\org.restlet-2.3.0.jar
 [ecj-lint] invalid Class-Path header in manifest of jar file: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\lib\org.restlet.ext.servlet-2.3.0.jar
 [ecj-lint] --
 [ecj-lint] 1. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 23)
 [ecj-lint] import javax.naming.NamingException;
 [ecj-lint]
 [ecj-lint] The type javax.naming.NamingException is not accessible
 [ecj-lint] --
 [ecj-lint] 2. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 28)
 [ecj-lint] public class MockInitialContextFactory implements 
InitialContextFactory {
 [ecj-lint]  ^
 [ecj-lint] The type MockInitialContextFactory must implement the inherited 
abstract method InitialContextFactory.getInitialContext(Hashtable)
 [ecj-lint] --
 [ecj-lint] 3. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 30)
 [ecj-lint] private final javax.naming.Context context;
 [ecj-lint]   
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 4. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint] ^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 5. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 33)
 [ecj-lint] context = mock(javax.naming.Context.class);
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 6. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 36)
 [ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation -> 
objects.get(invocation.getArgument(0)));
 [ecj-lint]  ^^^
 [ecj-lint] context cannot be resolved
 [ecj-lint] --
 [ecj-lint] 7. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 38)
 [ecj-lint] } catch (NamingException e) {
 [ecj-lint]  ^^^
 [ecj-lint] NamingException cannot be resolved to a type
 [ecj-lint] --
 [ecj-lint] 8. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 45)
 [ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
 [ecj-lint]
 [ecj-lint] The type javax.naming.Context is not accessible
 [ecj-lint] --
 [ecj-lint] 9. ERROR in 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\contrib\dataimporthandler\src\test\org\apache\solr\handler\dataimport\MockInitialContextFactory.java
 (at line 46)
 [ecj-lint] return context;
 [ecj-lint]^^^
 [ecj-lint] context cannot be resolved to a variable
 [ecj-lint] --
 [ecj-lint] 9 problems (9 errors)

BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:634: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\build.xml:101: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build.xml:651: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\common-build.xml:479:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\common-build.xml:2015:
 The following error occurred while 

[GitHub] [lucene-solr] jtibshirani commented on issue #715: LUCENE-7714 Add a range query that takes advantage of index sorting.

[GitBox]

jtibshirani commented on issue #715: LUCENE-7714 Add a range query that takes 
advantage of index sorting.
URL: https://github.com/apache/lucene-solr/pull/715#issuecomment-502169956
 
 
   Thanks @jimczi, I pushed another commit that makes sure to use the two-phase 
iterator for explain and match.


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


With regards,
Apache Git Services

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

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 64da34207983f67826c0f476cc47a53029bb3474 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64da342 ]

SOLR-13105: Add vector visualization examples


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-SmokeRelease-8.x - Build # 120 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/120/

No tests ran.

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

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

package:

-unpack-solr-tgz:

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

generate-maven-artifacts:

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

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

resolve:

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

-ivy-fail-disallowed-ivy-version:

ivy-fail:

ivy-configure:

[jira] [Commented] (SOLR-13219) LTR FieldLengthFeature causes NullPointerException with documents that do not have the requested field

[Nick Veenhof (JIRA)]

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

Nick Veenhof commented on SOLR-13219:
-

You can totally pick that one. Go all crazy :)

> LTR FieldLengthFeature causes NullPointerException with documents that do not 
> have the requested field
> --
>
> Key: SOLR-13219
> URL: https://issues.apache.org/jira/browse/SOLR-13219
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LTR
>Affects Versions: 7.6
> Environment: OSX - Mojave
>  
>Reporter: Nick Veenhof
>Priority: Major
>  Labels: ltr, nullpointerexception
>
> 1) Create an index with a dynamic field, eg tm_my_fulltext_field based on 
> tm_* dynamic field
> 2) Index your documents and make sure not all of the documents have the 
> tm_my_fulltext_field field.
> 3) Set up a feature store as follows
> {code:java}
> {
> "initArgs": {},
> "initializedOn": "2019-01-21T21:09:59.011Z",
> "updatedSinceInit": "2019-01-21T22:01:14.113Z",
> "managedList": [
> {
> "name": "descriptionLength",
> "class": "org.apache.solr.ltr.feature.FieldLengthFeature",
> "params": {
> "field": "tm_my_fulltext_field"
> },
> "store": "_DEFAULT_"
> }
> ]
> }
> {code}
> Try to fetch the feature in a query
>  
> {code:java}
> http://localhost:8983/solr/dropsolid8/select?q=europe=flat=true=ss_search_api_id,ss_search_api_language,hash,[features]=0=10=json={!ltr
>  efi.query=europe model=originalScoreModel}}=tm_X3b_nl_rendered_item
> {code}
> You'll see
>  
> {code:java}
> 2019-02-05 13:45:36.087 ERROR (qtp690521419-21) [ x:dropsolid8] 
> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: 
> java.lang.NullPointerException
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:140)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1607)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1421)
> at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:568)
> at 
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1435)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:375)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2541)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:709)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:515)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
> 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:1595)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
> 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:531)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)
> at 

[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13105:


Commit 6691360b7f9bbe31a390c5646a150528e1b12444 in lucene-solr's branch 
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6691360 ]

SOLR-13105: Add scalar math visualization


> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot 
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png, 
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47 
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and 
> Math Expressions. This ticket will create a visual guide to Solr Math 
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin* 
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize* 
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable 
> functions. These functions provide a system for searching, transforming, 
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the 
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and 
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>  
> A few sample visualizations are attached to the ticket.



--
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-13537) Build Status Badge in git README

[Marcus Eagan (JIRA)]

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

Marcus Eagan edited comment on SOLR-13537 at 6/14/19 3:25 PM:
--

I added a new screenshot to reflect how it would look in the future. I changed 
the build badge based on comments from some committers. 


was (Author: marcussorealheis):
I added a new screenshot to reflect how it would look in the future. I changed 
the build badge based on comments from some members of the Solr team.

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple 
> Artifact Build Badge.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



--
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-13537) Build Status Badge in git README

[Marcus Eagan (JIRA)]

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

Marcus Eagan commented on SOLR-13537:
-

I added a new screenshot to reflect how it would look in the future. I changed 
the build badge based on comments from some members of the Solr team.

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple 
> Artifact Build Badge.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



--
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-13537) Build Status Badge in git README

[Marcus Eagan (JIRA)]

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

Marcus Eagan updated SOLR-13537:

Attachment: Simple Artifact Build Badge.png

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png, Simple 
> Artifact Build Badge.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



--
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-13537) Build Status Badge in git README

[Marcus Eagan (JIRA)]

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

Marcus Eagan updated SOLR-13537:

Summary: Build Status Badge in git README  (was: Multiple Build Status 
Badges, Re-Ordered git README)

> Build Status Badge in git README
> 
>
> Key: SOLR-13537
> URL: https://issues.apache.org/jira/browse/SOLR-13537
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build, documentation
>Affects Versions: master (9.0), 8.2
>Reporter: Marcus Eagan
>Priority: Trivial
> Attachments: Markdown Preview Of Build Status README.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In order to aid developers and DevOps engineers who are working in a 
> git-driven ecosystem, it would be helpful to see the status builds in the 
> README. This is a standard for many open source projects. I think one could 
> debate whether we should have a multi-line build badge visual in the README 
> because people need to know about the builds for various versions and 
> platforms in the case of Lucene/Solr because it is such a large and widely 
> used project, in a variety of environments. The badges not only celebrate 
> that fact, they support its persistence in the future with new developers who 
> look for such information instictively.
> I would recommend the active build pipelines (currently 8.x and 9.x) for each 
> platform, Linux, Windows, MacOSX, and Solaris.



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

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

[GitHub] [lucene-solr] CaoManhDat closed pull request #718: SOLR-13541: Upgrade Jetty to 9.4.19.v20190610

[GitBox]

CaoManhDat closed pull request #718: SOLR-13541: Upgrade Jetty to 
9.4.19.v20190610
URL: https://github.com/apache/lucene-solr/pull/718
 
 
   


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


With regards,
Apache Git Services

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

[jira] [Issue Comment Deleted] (SOLR-13541) Upgrade Jetty to 9.4.19.v20190610

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated SOLR-13541:

Comment: was deleted

(was: [~erickerickson] Basically we disabled it for Java 11 in another issue. 
That why this error only arises in Java 8 (branch_8x))

> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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-13541) Upgrade Jetty to 9.4.19.v20190610

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13541:


Commit 8d48f9252ff3418bb36882efb64d6e00166edd1c in lucene-solr's branch 
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8d48f92 ]

SOLR-13541: Upgrade solr/CHANGES.txt


> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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-13541) Upgrade Jetty to 9.4.19.v20190610

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13541:


Commit 0c24aa6c75a288e8d42c436162ca221518287d46 in lucene-solr's branch 
refs/heads/master from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0c24aa6 ]

SOLR-13541: Upgrade Jetty to 9.4.19.v20190610


> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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-13541) Upgrade Jetty to 9.4.19.v20190610

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-13541:


Commit 22fca67bfe3b35c1c6818ed0fcce08086db987c9 in lucene-solr's branch 
refs/heads/branch_8x from Cao Manh Dat
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=22fca67 ]

SOLR-13541: Upgrade Jetty to 9.4.19.v20190610


> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-13452:
--

[~markrmil...@gmail.com]: I am not even sure if we need the test and the 
VirtualMethod class at all. I think it's dead code. We had it for backwards 
compatibility hack at several places. I don't think its used anymore.

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



--
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-13541) Upgrade Jetty to 9.4.19.v20190610

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on SOLR-13541:
-

[~erickerickson] Basically we disabled it for Java 11 in another issue. That 
why this error only arises in Java 8 (branch_8x)

> Upgrade Jetty to 9.4.19.v20190610
> -
>
> Key: SOLR-13541
> URL: https://issues.apache.org/jira/browse/SOLR-13541
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Attachments: _test.res
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-13452:


[~thetaphi], for some reason TestVirtualMethod does not pass when run under 
gradle. It works when I run it from eclipse, but I don't even think compiles 
with gradle - I tried to poke around a bit but it just failed in other spots. 
Any chance you could take a look?

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



--
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] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-13452:
---
Comment: was deleted

(was: Commit 183267bc70a74a0783cfe583fe8b6f96086481c3 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=183267b ]

SOLR-13452: Make contrib-clustering dependency checker compliant.
)

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



--
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] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-13452:
---
Comment: was deleted

(was: Commit aaec9b2dbfc2a75b84bbcb6efb4307d98b3e2846 in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aaec9b2 ]

SOLR-13452: Add comment on why kerby-pkix is excluded.
)

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



--
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] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-13452:
---
Comment: was deleted

(was: Commit e6837816e05365d0330190d4bdf64ab397980dbc in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e683781 ]

SOLR-13452:  Fix Solr JavaCC task to work with JavaCC 5 and add lucene 
queryparser javacc tasks, also hook them and solr javacc qp task to regenerate 
so they are tested by buildTest.
)

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



--
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] [Issue Comment Deleted] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-13452:
---
Comment: was deleted

(was: Commit 6f884a9fa190bc65f5f52df9e92b000f3f9f6f9b in lucene-solr's branch 
refs/heads/jira/SOLR-13452_gradle_3 from Mark Robert Miller
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6f884a9 ]

SOLR-13452: Re enable Lucene test that was failing early on.
)

> Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
> -
>
> Key: SOLR-13452
> URL: https://issues.apache.org/jira/browse/SOLR-13452
> Project: Solr
>  Issue Type: Improvement
>  Components: Build
>Reporter: Mark Miller
>Assignee: Mark Miller
>Priority: Major
> Fix For: master (9.0)
>
>
> I took some things from the great work that Dat did in 
> [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a 
> little further.
>  
> When working with gradle in sub modules directly, I recommend 
> [https://github.com/dougborg/gdub]
> This gradle branch uses the following plugin for version locking, version 
> configuration and version consistency across modules: 
> [https://github.com/palantir/gradle-consistent-versions]
>  
>  https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3



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