[jira] [Commented] (SOLR-11662) Make overlapping query term scoring configurable per field type

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-11662:
-

Can we have this SynonymQuery vs. dismax vs. BooleanQuery logic in a sub-class 
of QueryBuilder rather than QueryBuilder itself? Reason is that I don't think 
most users would need to customize this behaviour and moving it to a separate 
class would help keep QueryBuilder simple?

> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values for scoreOverlaps are:
> *as_one_term*
> Default, most synonym use cases. Uses SynonymQuery
> Treats all terms as if they're exactly equivalent, with document frequency 
> from underlying terms blended 
> *pick_best*
> For a given document, score using the best scoring synonym (ie dismax over 
> generated terms). 
> Useful when synonyms not exactly equilevant. Instead they are used to model 
> hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
> scores will reflect that quality
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby | text:cat | text:animal)
> *as_distinct_terms*
> (The pre 6.0 behavior.)
> Compromise between pick_best and as_oneSterm
> Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
> scores stack, so documents with more tabby, cat, or animal the better w/ a 
> bias towards the term with highest specificity
> Terms are turned into a boolean OR query, with documen frequencies not blended
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the boolean query (text:tabby  text:cat 
> text:animal)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 876 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/876/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC

7 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.client.solrj.io.sql.JdbcTest

Error Message:
Error from server at http://127.0.0.1:44397/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:44397/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([CBC3FBA582B29126]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.io.sql.JdbcTest.setupCluster(JdbcTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testSplitShard

Error Message:
Error from server at http://127.0.0.1:34359/solr: Could not find collection : 
solrj_test_splitshard

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:34359/solr: Could not find collection : 
solrj_test_splitshard
at 
__randomizedtesting.SeedInfo.seed([7BCB6CC7ABD5DB90:A0C1C1ABB520E72F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+32) - Build # 20969 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20969/
Java: 64bit/jdk-10-ea+32 -XX:-UseCompressedOops -XX:+UseG1GC

3 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest

Error Message:
3 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 1) 
Thread[id=14774, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-SendThread(127.0.0.1:40871),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]  
   at java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)2) 
Thread[id=14773, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest] at 
java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
 at java.base@10-ea/java.lang.Thread.run(Thread.java:844)3) 
Thread[id=14775, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
 at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE 
scope at org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest: 
   1) Thread[id=14774, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-SendThread(127.0.0.1:40871),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
at java.base@10-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1051)
   2) Thread[id=14773, name=Connection evictor, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
at java.base@10-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66)
at java.base@10-ea/java.lang.Thread.run(Thread.java:844)
   3) Thread[id=14775, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-EventThread,
 state=WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501)
at __randomizedtesting.SeedInfo.seed([AC6E4B5CCD8A9F42]:0)


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

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=14774, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-SendThread(127.0.0.1:40871),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]  
   at java.base@10-ea/java.lang.Thread.sleep(Native Method) at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997)
 at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=14774, 
name=TEST-ChaosMonkeyNothingIsSafeWithPullReplicasTest.test-seed#[AC6E4B5CCD8A9F42]-SendThread(127.0.0.1:40871),
 state=TIMED_WAITING, group=TGRP-ChaosMonkeyNothingIsSafeWithPullReplicasTest]
at java.base@10-ea/java.lang.Thread.sleep(Native Method)
at 
app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101)
at 
app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997)
at 
app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060)
at __randomizedtesting.SeedInfo.seed([AC6E4B5CCD8A9F42]:0)


FAILED:  

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20968/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsNNFailoverTest.test

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:32863/_u

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:32863/_u
at 
__randomizedtesting.SeedInfo.seed([7905C9CBB559BB50:F151F6111BA5D6A8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:314)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
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)

[jira] [Updated] (SOLR-11569) Add support for distance matrices to the distance Stream Evaluator

[Joel Bernstein (JIRA)]

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

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

Initial implementation. Tests to follow.

> Add support for distance matrices to the distance Stream Evaluator 
> ---
>
> Key: SOLR-11569
> URL: https://issues.apache.org/jira/browse/SOLR-11569
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: 7.2
>
> Attachments: SOLR-11569.patch
>
>
> This ticket will expand the functionality of the *distance* Stream Evaluator 
> to support distance matrices.
> https://en.wikipedia.org/wiki/Distance_matrix



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-11501:
-

Thanks for including the upgrade notes before committing - that made it easier 
to check/review the intended behavior.
I like the \_query\_ toggle on "uf" as well, I had missed that on my first scan.
+1 overall - it feels pretty unlikely that users will be negatively impacted by 
the change in behavior given that the vast majority of people will be using 
lucene / func for advanced stuff with embedded query types.

> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11501_limit_local_params_parsing.patch, 
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query 
> parser) in certain circumstances.  _Perhaps_ it is when the QParser.getParser 
> is passed "lucene" for the {{defaultParser}}?  This particular approach is 
> just a straw-man; I suspect certain valid embedded queries could no longer 
> work if this is done incorrectly.  Whatever the solution, I don't think we 
> should assume 'q' is special, as it's valid and useful to build up queries 
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax 
> v=$qq\}=user input}}  and we want to protect the user input there 
> similarly from unwelcome query parsing switching.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+32) - Build # 874 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/874/
Java: 64bit/jdk-10-ea+32 -XX:-UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  
org.apache.solr.metrics.reporters.solr.SolrCloudReportersTest.testExplicitConfiguration

Error Message:
Error from server at https://127.0.0.1:41225/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:41225/solr: create the collection time out:180s
at 
__randomizedtesting.SeedInfo.seed([DC1105400E6B722A:98DD25BB6051A440]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.metrics.reporters.solr.SolrCloudReportersTest.testExplicitConfiguration(SolrCloudReportersTest.java:67)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1424 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1424/

10 tests failed.
FAILED:  
org.apache.lucene.search.similarities.TestBasicModelIn.testRandomScoring

Error Message:
score(8.5715059E8)=6.4687744E9 > score(8.5715066E8)=6.4687739E9

Stack Trace:
java.lang.AssertionError: score(8.5715059E8)=6.4687744E9 > 
score(8.5715066E8)=6.4687739E9
at 
__randomizedtesting.SeedInfo.seed([348F19EF98AA25D1:BF10405D82DDC3DB]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.doTestScoring(BaseSimilarityTestCase.java:403)
at 
org.apache.lucene.search.similarities.BaseSimilarityTestCase.testRandomScoring(BaseSimilarityTestCase.java:355)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest: 1) 
Thread[id=25259, name=zkCallback-4768-thread-1, state=TIMED_WAITING, 
group=TGRP-ChaosMonkeySafeLeaderWithPullReplicasTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 

[jira] [Issue Comment Deleted] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop updated SOLR-11600:
-
Comment: was deleted

(was: Thanks Joel.
Its good to know what the roadmap is here. 
Personally though I am a fan of SolrStreaming Java classes approach, it does 
set Solr apart from other data stores.
Although, I can imagine this seeming complicated to many users in java api, I 
guess I have been programming using it a lot recently so I might be a bit 
biased as I feel comfortable so far :) 
But then we are moving in the sql direction or rather a DSL direction 
completely? 
A compile-time correctness-verification feature, then becomes vital for 
programers' confidence.
Maybe when there is enough time and a larger audience (greater than just me :) 
), you can revisit this ;)

Amrit - I am not 100% sure I understand what the next action items are, based 
on your note, but I guess you will keep us posted.)

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop updated SOLR-11600:
-
Comment: was deleted

(was: Thanks a lot [~joel.bernstein] ! I will try and use this as the guide! )

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop updated SOLR-11600:
-
Comment: was deleted

(was: ok Amrit. But I think we really should take a look at providing a 
strongly typed option to make a Select stream with custom evaluators.
It is pretty odd that we can create a complex RollupStream in a strongly typed 
way, but the moment we want to wrap it within a SelectStream, with some 
standard yet custom Evaluators, one needs to go back to constructing a string 
.. I was able to go make it as nice as possible, but this is sub-optimal in my 
opinion :) 

Once I have some time and I get compliance clearance from my organization, I 
will consider contributing to this if possible.

But if possible lets do a thought experiment on this, may be we can discuss 
this offline and propose a solution. I am still not sure why its not easy to 
do. Maybe something is getting lost in translation.)

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop updated SOLR-11600:
-
Comment: was deleted

(was: Hi Amrit 

Can you provide a sample test for this patch ?
I am trying to move forward with this but seems like it might take a while 
before we can get this into a release?)

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Issue Comment Deleted] (SOLR-11598) Export Writer needs to support more than 4 Sort fields - Say 10, ideally it should not be bound at all, but 4 seems to really short sell the StreamRollup ca

[Aroop (JIRA)]

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

Aroop updated SOLR-11598:
-
Comment: was deleted

(was: I see. I am sure that benchmarking must have been done to come up with 
the number 4.
Is it proven that it becomes an order of magnitude worse at 5 or 6 ? 

This limitation of 4 significantly restricts the utility of RollupStreams to 4 
dimensions/buckets as well then right?  

As I mentioned it might be worthwhile to share stats with the user on the 
performance tradeoff when sorts are increased, and then its up to the 
consumer/user (caveat emptor :) ) to try it in staging and consider if it would 
scale for them. Maybe some consumers dont have great scales that cause this 
issue. At least, they would have an option to try. Presently, the cutoff at 4 
eliminates any experimentation for a user like myself.

 )

> Export Writer needs to support more than 4 Sort fields - Say 10, ideally it 
> should not be bound at all, but 4 seems to really short sell the StreamRollup 
> capabilities.
> ---
>
> Key: SOLR-11598
> URL: https://issues.apache.org/jira/browse/SOLR-11598
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 6.6.1, 7.0
>Reporter: Aroop
>  Labels: patch
> Attachments: SOLR-11598-6_6-streamtests, SOLR-11598-6_6.patch, 
> SOLR-11598-master.patch, SOLR-11598.patch
>
>
> I am a user of Streaming and I am currently trying to use rollups on an 10 
> dimensional document.
> I am unable to get correct results on this query as I am bounded by the 
> limitation of the export handler which supports only 4 sort fields.
> I do not see why this needs to be the case, as it could very well be 10 or 20.
> My current needs would be satisfied with 10, but one would want to ask why 
> can't it be any decent integer n, beyond which we know performance degrades, 
> but even then it should be caveat emptor.
> [~varunthacker] 
> Code Link:
> https://github.com/apache/lucene-solr/blob/19db1df81a18e6eb2cce5be973bf2305d606a9f8/solr/core/src/java/org/apache/solr/handler/ExportWriter.java#L455
> Error
> null:java.io.IOException: A max of 4 sorts can be specified
>   at 
> org.apache.solr.handler.ExportWriter.getSortDoc(ExportWriter.java:452)
>   at org.apache.solr.handler.ExportWriter.writeDocs(ExportWriter.java:228)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$null$1(ExportWriter.java:219)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeIterator(JavaBinCodec.java:664)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:333)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
>   at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$null$2(ExportWriter.java:219)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:354)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
>   at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$write$3(ExportWriter.java:217)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
>   at org.apache.solr.handler.ExportWriter.write(ExportWriter.java:215)
>   at org.apache.solr.core.SolrCore$3.write(SolrCore.java:2601)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:49)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
>   at 
> 

[jira] [Issue Comment Deleted] (SOLR-11598) Export Writer needs to support more than 4 Sort fields - Say 10, ideally it should not be bound at all, but 4 seems to really short sell the StreamRollup ca

[Aroop (JIRA)]

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

Aroop updated SOLR-11598:
-
Comment: was deleted

(was: Thanks Amrit! 
So the patch attached here allows 10 now ? and not 8 ? 

Also, if you have determined this to have O(N) performance characteristic, are 
you planning to make it a lot larger and not bounded under 10? 
I will perform tests with the patch and share results if permitted.)

> Export Writer needs to support more than 4 Sort fields - Say 10, ideally it 
> should not be bound at all, but 4 seems to really short sell the StreamRollup 
> capabilities.
> ---
>
> Key: SOLR-11598
> URL: https://issues.apache.org/jira/browse/SOLR-11598
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Affects Versions: 6.6.1, 7.0
>Reporter: Aroop
>  Labels: patch
> Attachments: SOLR-11598-6_6-streamtests, SOLR-11598-6_6.patch, 
> SOLR-11598-master.patch, SOLR-11598.patch
>
>
> I am a user of Streaming and I am currently trying to use rollups on an 10 
> dimensional document.
> I am unable to get correct results on this query as I am bounded by the 
> limitation of the export handler which supports only 4 sort fields.
> I do not see why this needs to be the case, as it could very well be 10 or 20.
> My current needs would be satisfied with 10, but one would want to ask why 
> can't it be any decent integer n, beyond which we know performance degrades, 
> but even then it should be caveat emptor.
> [~varunthacker] 
> Code Link:
> https://github.com/apache/lucene-solr/blob/19db1df81a18e6eb2cce5be973bf2305d606a9f8/solr/core/src/java/org/apache/solr/handler/ExportWriter.java#L455
> Error
> null:java.io.IOException: A max of 4 sorts can be specified
>   at 
> org.apache.solr.handler.ExportWriter.getSortDoc(ExportWriter.java:452)
>   at org.apache.solr.handler.ExportWriter.writeDocs(ExportWriter.java:228)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$null$1(ExportWriter.java:219)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeIterator(JavaBinCodec.java:664)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:333)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
>   at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$null$2(ExportWriter.java:219)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:354)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
>   at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
>   at 
> org.apache.solr.handler.ExportWriter.lambda$write$3(ExportWriter.java:217)
>   at 
> org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
>   at org.apache.solr.handler.ExportWriter.write(ExportWriter.java:215)
>   at org.apache.solr.core.SolrCore$3.write(SolrCore.java:2601)
>   at 
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:49)
>   at 
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> 

[jira] [Updated] (SOLR-11598) Export Writer needs to support more than 4 Sort fields - Say 10, ideally it should not be bound at all, but 4 seems to really short sell the StreamRollup capabilities.

[Aroop (JIRA)]

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

Aroop updated SOLR-11598:
-
Description: 
I am a user of Streaming and I am currently trying to use rollups on an 10 
dimensional document.
I am unable to get correct results on this query as I am bounded by the 
limitation of the export handler which supports only 4 sort fields.
I do not see why this needs to be the case, as it could very well be 10 or 20.
My current needs would be satisfied with 10, but one would want to ask why 
can't it be any decent integer n, beyond which we know performance degrades, 
but even then it should be caveat emptor.


[~varunthacker] 

Code Link:
https://github.com/apache/lucene-solr/blob/19db1df81a18e6eb2cce5be973bf2305d606a9f8/solr/core/src/java/org/apache/solr/handler/ExportWriter.java#L455

Error
null:java.io.IOException: A max of 4 sorts can be specified
at 
org.apache.solr.handler.ExportWriter.getSortDoc(ExportWriter.java:452)
at org.apache.solr.handler.ExportWriter.writeDocs(ExportWriter.java:228)
at 
org.apache.solr.handler.ExportWriter.lambda$null$1(ExportWriter.java:219)
at 
org.apache.solr.common.util.JavaBinCodec.writeIterator(JavaBinCodec.java:664)
at 
org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:333)
at 
org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
at 
org.apache.solr.handler.ExportWriter.lambda$null$2(ExportWriter.java:219)
at 
org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
at 
org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:354)
at 
org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:223)
at org.apache.solr.common.util.JavaBinCodec$1.put(JavaBinCodec.java:394)
at 
org.apache.solr.handler.ExportWriter.lambda$write$3(ExportWriter.java:217)
at 
org.apache.solr.common.util.JavaBinCodec.writeMap(JavaBinCodec.java:437)
at org.apache.solr.handler.ExportWriter.write(ExportWriter.java:215)
at org.apache.solr.core.SolrCore$3.write(SolrCore.java:2601)
at 
org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:49)
at 
org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:809)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:538)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:361)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:305)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1691)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at 
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:534)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at 

[jira] [Commented] (LUCENE-6228) Do not expose full-fledged scorers in LeafCollector.setScorer

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6228:


Thanks [~romseygeek]; that makes sense.

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -
>
> Key: LUCENE-6228
> URL: https://issues.apache.org/jira/browse/LUCENE-6228
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 5.2, 6.0
>
> Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11662) Make overlapping query term scoring configurable per field type

[Doug Turnbull (JIRA)]

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

Doug Turnbull updated SOLR-11662:
-
Description: 
This patch customizes the query-time behavior when query terms overlap 
positions. Right now the only option is SynonymQuery. This is a fantastic 
default & improvement on past versions. However, there are use cases where 
terms overlap positions but don't carry exact synonymy relationships. Often 
synonyms are actually used to model hypernym/hyponym relationships using 
synonyms (or other analyzers). So the individual term scores matter, with terms 
with higher specificity (hyponym) scoring higher than terms with lower 
specificity (hypernym).

This patch adds the fieldType setting scoreOverlaps, as in:


{code:java}
  

{code}


Valid values for scoreOverlaps are:

*as_one_term*
Default, most synonym use cases. Uses SynonymQuery
Treats all terms as if they're exactly equivalent, with document frequency from 
underlying terms blended 

*pick_best*
For a given document, score using the best scoring synonym (ie dismax over 
generated terms). 
Useful when synonyms not exactly equilevant. Instead they are used to model 
hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
scores will reflect that quality
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby | text:cat | text:animal)

*as_distinct_terms*
(The pre 6.0 behavior.)
Compromise between pick_best and as_oneSterm
Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
scores stack, so documents with more tabby, cat, or animal the better w/ a bias 
towards the term with highest specificity
Terms are turned into a boolean OR query, with documen frequencies not blended
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the boolean query (text:tabby  text:cat text:animal)


  was:
This patch customizes the query-time behavior when query terms overlap 
positions. Right now the only option is SynonymQuery. This is a fantastic 
default & improvement on past versions. However, there are use cases where 
terms overlap positions but don't carry exact synonymy relationships. Often 
synonyms are actually used to model hypernym/hyponym relationships using 
synonyms (or other analyzers). So the individual term scores matter, with terms 
with higher specificity (hyponym) scoring higher than terms with lower 
specificity (hypernym).

This patch adds the fieldType setting scoreOverlaps, as in:


{code:java}
  

{code}


Valid values for scoreOverlaps are:

*as_one_term*
Default, most synonym use cases. Uses SynonymQuery
Treats all terms as if they're exactly equivalent, with document frequency from 
underlying terms blended 

*pick_best*
For a given document, score using the best scoring synonym (ie dismax over 
generated terms). 
Useful when synonyms not exactly equilevant. Instead they are used to model 
hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
scores will reflect that quality
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby | text:cat | text:animal)

*as_distinct_terms*
(The pre 6.0 behavior.)
Compromise between pick_best and as_oneSterm
Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
scores stack, so documents with more tabby, cat, or animal the better w/ a bias 
towards the term with highest specificity
Terms are turned into a boolean OR query, with documen frequencies not blended
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby  text:cat text:animal)



> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values 

[jira] [Commented] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop commented on SOLR-11600:
--

Thanks a lot [~joel.bernstein] ! I will try and use this as the guide! 

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11664) range facets with with sub aggregations on string fields give incorrect results

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-11664:
---

 Summary: range facets with with sub aggregations on string fields 
give incorrect results
 Key: SOLR-11664
 URL: https://issues.apache.org/jira/browse/SOLR-11664
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Facet Module
Reporter: Yonik Seeley
Priority: Critical


Reported by Volodymyr Rudniev http://markmail.org/message/3pueopseidgijqs3




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-8054.
-
   Resolution: Fixed
Fix Version/s: 7.2
   master (8.0)
   6.7

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.2
>
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

A fix has been tested and committed.  I couldn't find a way to prevent (worst 
case) O(n^2) behavior on exact circle initialization.  But hopefully the number 
of planes will be reasonable and this will keep computation from exploding.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8054: Use backbounds to stop spuriosly rejecting points that are within 
the exact circle.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8054: Use backbounds to stop spuriosly rejecting points that are within 
the exact circle.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8054: Use backbounds to stop spuriosly rejecting points that are within 
the exact circle.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11663) CLONE - API to create a core is broken

[Jaya Naga Bhavana (JIRA)]

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

Jaya Naga Bhavana commented on SOLR-11663:
--

Ok.
According to the project which I am working on, It requires the user to create 
a core from the UI of the project.
In this case how can I solve this problem?

> CLONE - API to create a core is broken
> --
>
> Key: SOLR-11663
> URL: https://issues.apache.org/jira/browse/SOLR-11663
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 6.6
>Reporter: Jaya Naga Bhavana
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11663) CLONE - API to create a core is broken

[Shawn Heisey (JIRA)]

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

Shawn Heisey edited comment on SOLR-11663 at 11/21/17 10:42 PM:


The CREATE action on the CoreAdmin API has never been able to work when it 
can't find a configuration.  CoreAdmin is *OLD*, and predates all of the slick 
functionality of the recent admin interfaces.  Access to it has been added to 
the UI, but the underlying functionality is still the same as it always was.

This requirement *is* in the documentation and has been for a while.  I'm the 
one who put it there.  Here's the exact text:

{code}
CREATE must be able to find a configuration!

Your CREATE call must be able to find a configuration, or it will not succeed.

When you are running SolrCloud and create a new core for a collection, the 
configuration will be inherited from the collection. Each collection is linked 
to a configName, which is stored in the ZooKeeper database. This satisfies the 
config requirement. There is something to note, though – if you’re running 
SolrCloud, you should NOT be using the CoreAdmin API at all. Use the 
Collections API.

When you are not running SolrCloud, if you have Config Sets defined, you can 
use the configSet parameter as documented below. If there are no config sets, 
then the instanceDir specified in the CREATE call must already exist, and it 
must contain a conf directory which in turn must contain solrconfig.xml, your 
schema, which is usually named either managed-schema or schema.xml, and any 
files referenced by those configs.

The config and schema filenames can be specified with the config and schema 
parameters, but these are expert options. One thing you could do to avoid 
creating the conf directory is use config and schema parameters that point at 
absolute paths, but this can lead to confusing configurations unless you fully 
understand what you are doing.
{code}



was (Author: elyograg):
The CREATE action on the CoreAdmin API has never been able to work when it 
can't find a configuration.  CoreAdmin is *OLD*, and predates all of the slick 
functionality of the recent admin interfaces.  Access to it has been added to 
the UI, but the underlying functionality is still the same as it always was.

This requirement *is* in the documentation and has been for a while.  I'm the 
one who put it there.  Here's the exact text:

{noformat}
CREATE must be able to find a configuration!

Your CREATE call must be able to find a configuration, or it will not succeed.

When you are running SolrCloud and create a new core for a collection, the 
configuration will be inherited from the collection. Each collection is linked 
to a configName, which is stored in the ZooKeeper database. This satisfies the 
config requirement. There is something to note, though – if you’re running 
SolrCloud, you should NOT be using the CoreAdmin API at all. Use the 
Collections API.

When you are not running SolrCloud, if you have Config Sets defined, you can 
use the configSet parameter as documented below. If there are no config sets, 
then the instanceDir specified in the CREATE call must already exist, and it 
must contain a conf directory which in turn must contain solrconfig.xml, your 
schema, which is usually named either managed-schema or schema.xml, and any 
files referenced by those configs.

The config and schema filenames can be specified with the config and schema 
parameters, but these are expert options. One thing you could do to avoid 
creating the conf directory is use config and schema parameters that point at 
absolute paths, but this can lead to confusing configurations unless you fully 
understand what you are doing.
{noformat}


> CLONE - API to create a core is broken
> --
>
> Key: SOLR-11663
> URL: https://issues.apache.org/jira/browse/SOLR-11663
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 6.6
>Reporter: Jaya Naga Bhavana
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, 

[jira] [Commented] (SOLR-11663) CLONE - API to create a core is broken

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-11663:
-

The CREATE action on the CoreAdmin API has never been able to work when it 
can't find a configuration.  CoreAdmin is *OLD*, and predates all of the slick 
functionality of the recent admin interfaces.  Access to it has been added to 
the UI, but the underlying functionality is still the same as it always was.

This requirement *is* in the documentation and has been for a while.  I'm the 
one who put it there.  Here's the exact text:

{noformat}
CREATE must be able to find a configuration!

Your CREATE call must be able to find a configuration, or it will not succeed.

When you are running SolrCloud and create a new core for a collection, the 
configuration will be inherited from the collection. Each collection is linked 
to a configName, which is stored in the ZooKeeper database. This satisfies the 
config requirement. There is something to note, though – if you’re running 
SolrCloud, you should NOT be using the CoreAdmin API at all. Use the 
Collections API.

When you are not running SolrCloud, if you have Config Sets defined, you can 
use the configSet parameter as documented below. If there are no config sets, 
then the instanceDir specified in the CREATE call must already exist, and it 
must contain a conf directory which in turn must contain solrconfig.xml, your 
schema, which is usually named either managed-schema or schema.xml, and any 
files referenced by those configs.

The config and schema filenames can be specified with the config and schema 
parameters, but these are expert options. One thing you could do to avoid 
creating the conf directory is use config and schema parameters that point at 
absolute paths, but this can lead to confusing configurations unless you fully 
understand what you are doing.
{noformat}


> CLONE - API to create a core is broken
> --
>
> Key: SOLR-11663
> URL: https://issues.apache.org/jira/browse/SOLR-11663
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 6.6
>Reporter: Jaya Naga Bhavana
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11501) Depending on the parser, QParser should not parse local-params

[David Smiley (JIRA)]

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

David Smiley updated SOLR-11501:

Attachment: SOLR_11501_limit_local_params_parsing.patch

Here's an updated patch.  Not a lot changed but some.
* toggle new behavior based on luceneMatchVersion
* added CHANGES.txt upgrade notes.
* It turns out {{dismax}} is not affected because various special characters 
are escaped.  The QParser escapes via 
org.apache.solr.util.SolrPluginUtils#partialEscape.  I added a test and poked 
around in the debugger to feel more confident about this.
* Added tests to all parsers that use this parser in some shape or form: 
{{complex}}, {{dismax}}, {{edismax}} to show that by default they don't parse 
subqueries.  edismax can be toggled to and it's tested.  Of course {{lucene}} 
already has tests for this.
* as in the last patch, SolrQueryParserBase has a simple boolean 
allowSubQueryParsing defaulting to false.  It was not trivial to lay the 
groundwork to support a configurable list of parsers, and so I leave that for 
whatever future issue chooses to embark on that.  

I'm shooting for committing this Monday if I don't hear feedback to the 
contrary.

Here's the proposed CHANGES.txt:
{noformat}
Upgrade Notes
--

* SOLR-11501: Starting a query string with local-params {!myparser ...} is used 
to switch the query parser to another,
  and is intended for use by Solr system developers, not end users doing 
searches.  To reduce negative side-effects of
  unintended hack-ability, we've limited the cases that local-params will be 
parsed to only contexts in which the
  default parser is "lucene" or "func".
  So if defType=edismax then q={!myparser ...} won't work.  In that example, 
put the desired query parser into defType.
  Another example is if deftype=edismax then hl.q={!myparser ...} won't work 
for the same reason.  In that example,
  either put the desired query parser into hl.qparser or set hl.qparser=lucene. 
 Most users won't run into these cases
  but some will and must change.
  If you must have full backwards compatibility, use luceneMatchVersion=7.1.0 
or something earlier. (David Smiley)

* SOLR-11501: The edismax parser by default no longer allows subqueries that 
specify a Solr parser using either
  local-params, or the older _query_ magic field trick.  For example
  {!prefix f=myfield v=enterp}  or  _query_:"{!prefix f=myfield v=enterp}"   
are not supported by default anymore.
  If you want to allow power-users to do this, set uf=*,_query_ or some other 
value that includes _query_.
  If you must have full backwards compatibility, use luceneMatchVersion=7.1.0 
or something earlier. (David Smiley)
{noformat}

> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
> Attachments: SOLR_11501_limit_local_params_parsing.patch, 
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query 
> parser) in certain circumstances.  _Perhaps_ it is when the QParser.getParser 
> is passed "lucene" for the {{defaultParser}}?  This particular approach is 
> just a straw-man; I suspect certain valid embedded queries could no longer 
> work if this is done incorrectly.  Whatever the solution, I don't think we 
> should assume 'q' is special, as it's valid and useful to build up queries 
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax 
> v=$qq\}=user input}}  and we want to protect the user input there 
> similarly from unwelcome query parsing switching.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11663) CLONE - API to create a core is broken

[Jaya Naga Bhavana (JIRA)]

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

Jaya Naga Bhavana updated SOLR-11663:
-
Affects Version/s: (was: 5.0)
   6.6

> CLONE - API to create a core is broken
> --
>
> Key: SOLR-11663
> URL: https://issues.apache.org/jira/browse/SOLR-11663
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 6.6
>Reporter: Jaya Naga Bhavana
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11663) CLONE - API to create a core is broken

[Jaya Naga Bhavana (JIRA)]

Jaya Naga Bhavana created SOLR-11663:


 Summary: CLONE - API to create a core is broken
 Key: SOLR-11663
 URL: https://issues.apache.org/jira/browse/SOLR-11663
 Project: Solr
  Issue Type: Bug
  Components: Server
Affects Versions: 5.0
Reporter: Jaya Naga Bhavana


*Steps To Reproduce*

{code}
curl 
'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
{code}

*Expected Result*

Create a core called "new_core".

*Actual Result*

{quote}
Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
by: Can't find resource 'solrconfig.xml' in classpath or 
'/var/solr/data/new_core/conf'
{quote}

Somebody on solr-users tells me:

{quote}
The CoreAdmin API requires that the instanceDir already exist, with a
conf directory inside it that contains solrconfig.xml, schema.xml, and
any other necessary config files.
{quote}

Huh? Where is this magical knowledge mentioned in the [API 
documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?

Another user on the list serve says:

{quote}
In fact, yes. The thing to remember here is that you're using a much
older approach that had its roots in the pre-cloud days.
{quote}

*The whole point of creating APIs is to abstract out details that the caller 
doesn't need to know, and yet this API requires an understanding of Solr's 
internal file structure and history of the project?* I'm speechless.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-7316) API to create a core is broken

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on SOLR-7316 at 11/21/17 10:12 PM:
-

No, nor is there any consensus on what should be done. For SolrCloud, the 
process has been resolved for creating _collections_, but for stand-alone Solr 
you have to put the configurations "in the right place" to create a core with 
the core admin API.

For that matter, the create core API has never been broken, it's worked as 
expected. The question is whether that expectation should be changed.



was (Author: erickerickson):
No, nor is there any consensus on what should be done. For SolrCloud, the 
process has been resolved for creating _collections_, but for stand-alone Solr 
you have to put the configurations "in the right place" to create a core with 
the core admin API.



> API to create a core is broken
> --
>
> Key: SOLR-7316
> URL: https://issues.apache.org/jira/browse/SOLR-7316
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.0
>Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7316) API to create a core is broken

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7316:
--

No, nor is there any consensus on what should be done. For SolrCloud, the 
process has been resolved for creating _collections_, but for stand-alone Solr 
you have to put the configurations "in the right place" to create a core with 
the core admin API.



> API to create a core is broken
> --
>
> Key: SOLR-7316
> URL: https://issues.apache.org/jira/browse/SOLR-7316
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.0
>Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11412) Documentation changes for SOLR-11003: Bi-directional CDCR support

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11412:
--

I'm taking a review of the new docs, and looking at splitting the page up at 
the same time. Splitting CDCR API into its own page is obvious, but thinking 
about how to split the rest, I came up with this possible structure:

* {{cross-data-center-replication.adoc}}: main page with "What is CDCR?" and 
"CDCR Glossary" sections, and links to other pages
** {{cdcr-architecture.adoc}}: new page with the current "CDCR Architecture" 
and "Major Components of CDCR" sections
** {{cdcr-config.adoc}}: new page with current "CDCR Configuration", "Initial 
Startup", and "ZooKeeper Settings" sections
** {{cdcr-operations.adoc}}: new page with current "Monitoring" and "Upgrading 
and Patching Production" sections
** {{cdcr-api.adoc}}: new page with current "CDCR API" section

[~varunthacker], [~sarkaramr...@gmail.com], or [~erickerickson] - any thoughts?

> Documentation changes for SOLR-11003: Bi-directional CDCR support
> -
>
> Key: SOLR-11412
> URL: https://issues.apache.org/jira/browse/SOLR-11412
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, documentation
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: CDCR_bidir.png, SOLR-11412.patch, SOLR-11412.patch, 
> SOLR-11412.patch, SOLR-11412.patch
>
>
> Since SOLR-11003: Bi-directional CDCR scenario support, is reaching its 
> conclusion. The relevant changes in documentation needs to be done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11412) Documentation changes for SOLR-11003: Bi-directional CDCR support

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-11412 at 11/21/17 9:59 PM:


I'm taking a review of the new docs, and looking at splitting the page up at 
the same time. Splitting CDCR API into its own page is obvious, but thinking 
about how to split the rest, I came up with this possible structure:

* {{cross-data-center-replication.adoc}}: parent page with "What is CDCR?" and 
"CDCR Glossary" sections, and links to other pages (would live in same place 
under SolrCloud top-level section)
** {{cdcr-architecture.adoc}}: new page with the current "CDCR Architecture" 
and "Major Components of CDCR" sections
** {{cdcr-config.adoc}}: new page with current "CDCR Configuration", "Initial 
Startup", and "ZooKeeper Settings" sections
** {{cdcr-operations.adoc}}: new page with current "Monitoring" and "Upgrading 
and Patching Production" sections
** {{cdcr-api.adoc}}: new page with current "CDCR API" section

[~varunthacker], [~sarkaramr...@gmail.com], or [~erickerickson] - any thoughts?


was (Author: ctargett):
I'm taking a review of the new docs, and looking at splitting the page up at 
the same time. Splitting CDCR API into its own page is obvious, but thinking 
about how to split the rest, I came up with this possible structure:

* {{cross-data-center-replication.adoc}}: main page with "What is CDCR?" and 
"CDCR Glossary" sections, and links to other pages
** {{cdcr-architecture.adoc}}: new page with the current "CDCR Architecture" 
and "Major Components of CDCR" sections
** {{cdcr-config.adoc}}: new page with current "CDCR Configuration", "Initial 
Startup", and "ZooKeeper Settings" sections
** {{cdcr-operations.adoc}}: new page with current "Monitoring" and "Upgrading 
and Patching Production" sections
** {{cdcr-api.adoc}}: new page with current "CDCR API" section

[~varunthacker], [~sarkaramr...@gmail.com], or [~erickerickson] - any thoughts?

> Documentation changes for SOLR-11003: Bi-directional CDCR support
> -
>
> Key: SOLR-11412
> URL: https://issues.apache.org/jira/browse/SOLR-11412
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR, documentation
>Reporter: Amrit Sarkar
>Assignee: Varun Thacker
> Attachments: CDCR_bidir.png, SOLR-11412.patch, SOLR-11412.patch, 
> SOLR-11412.patch, SOLR-11412.patch
>
>
> Since SOLR-11003: Bi-directional CDCR scenario support, is reaching its 
> conclusion. The relevant changes in documentation needs to be done.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11662) Make overlapping query term scoring configurable per field type

[Doug Turnbull (JIRA)]

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

Doug Turnbull commented on SOLR-11662:
--

Associated pull request https://github.com/apache/lucene-solr/pull/275/files
And Patch 
https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/275.patch

> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values for scoreOverlaps are:
> *as_one_term*
> Default, most synonym use cases. Uses SynonymQuery
> Treats all terms as if they're exactly equivalent, with document frequency 
> from underlying terms blended 
> *pick_best*
> For a given document, score using the best scoring synonym (ie dismax over 
> generated terms). 
> Useful when synonyms not exactly equilevant. Instead they are used to model 
> hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
> scores will reflect that quality
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby | text:cat | text:animal)
> *as_distinct_terms*
> (The pre 6.0 behavior.)
> Compromise between pick_best and as_oneSterm
> Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
> scores stack, so documents with more tabby, cat, or animal the better w/ a 
> bias towards the term with highest specificity
> Terms are turned into a boolean OR query, with documen frequencies not blended
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby  text:cat text:animal)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11662) Make overlapping query term scoring configurable per field type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-11662:
---

GitHub user softwaredoug opened a pull request:

https://github.com/apache/lucene-solr/pull/275

SOLR-11662: Configurable query when terms overlap

Modifies QueryBuilder and Solr Field Type to allow configurable overlap 
scoring asides from SynonymQuery

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/o19s/lucene-solr 
configurable-synonym-query-behavior

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/275.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #275


commit d83b1300a8b469fa19e5fd9ae8264f6fa448bb18
Author: Doug Turnbull 
Date:   2017-11-21T19:02:09Z

Makes QueryBuilder synonym matching configurable

commit f279435b46f81232181a658be5e856bdbca9924f
Author: Doug Turnbull 
Date:   2017-11-21T20:03:54Z

plumb through the field type setting

commit 1e9e41c4cccff10effd4a29da30c378ee21dac3d
Author: Doug Turnbull 
Date:   2017-11-21T20:17:56Z

Fix enum style

commit 8eb875fcccf533d3799b15d266c724c868e13d34
Author: Doug Turnbull 
Date:   2017-11-21T21:47:04Z

Renaming to scoreOverlaps




> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values for scoreOverlaps are:
> *as_one_term*
> Default, most synonym use cases. Uses SynonymQuery
> Treats all terms as if they're exactly equivalent, with document frequency 
> from underlying terms blended 
> *pick_best*
> For a given document, score using the best scoring synonym (ie dismax over 
> generated terms). 
> Useful when synonyms not exactly equilevant. Instead they are used to model 
> hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
> scores will reflect that quality
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby | text:cat | text:animal)
> *as_distinct_terms*
> (The pre 6.0 behavior.)
> Compromise between pick_best and as_oneSterm
> Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
> scores stack, so documents with more tabby, cat, or animal the better w/ a 
> bias towards the term with highest specificity
> Terms are turned into a boolean OR query, with documen frequencies not blended
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby  text:cat text:animal)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #275: SOLR-11662: Configurable query when terms ove...

[softwaredoug]

GitHub user softwaredoug opened a pull request:

https://github.com/apache/lucene-solr/pull/275

SOLR-11662: Configurable query when terms overlap

Modifies QueryBuilder and Solr Field Type to allow configurable overlap 
scoring asides from SynonymQuery

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/o19s/lucene-solr 
configurable-synonym-query-behavior

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/275.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #275


commit d83b1300a8b469fa19e5fd9ae8264f6fa448bb18
Author: Doug Turnbull 
Date:   2017-11-21T19:02:09Z

Makes QueryBuilder synonym matching configurable

commit f279435b46f81232181a658be5e856bdbca9924f
Author: Doug Turnbull 
Date:   2017-11-21T20:03:54Z

plumb through the field type setting

commit 1e9e41c4cccff10effd4a29da30c378ee21dac3d
Author: Doug Turnbull 
Date:   2017-11-21T20:17:56Z

Fix enum style

commit 8eb875fcccf533d3799b15d266c724c868e13d34
Author: Doug Turnbull 
Date:   2017-11-21T21:47:04Z

Renaming to scoreOverlaps




---

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

[jira] [Comment Edited] (SOLR-7316) API to create a core is broken

[Jaya Naga Bhavana (JIRA)]

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

Jaya Naga Bhavana edited comment on SOLR-7316 at 11/21/17 9:49 PM:
---

Hello,

Is this issue resolved?
I am working on a project where the user should be able to create multiple 
core's from the projects UI.
so I came up with an idea of using the above mentioned curl command.
And after a lot of research I am still not able to create the core with curl 
command it always give me an error that :

Error CREATEing SolrCore 'coreX': Unable to create core [coreX] Caused by: 
Can't find resource 'solrconfig.xml' in classpath or 
'C:\solr-6.6.0\server\solr\coreX'




was (Author: bhavana342):
Hello,

Is this issue resolved?

> API to create a core is broken
> --
>
> Key: SOLR-7316
> URL: https://issues.apache.org/jira/browse/SOLR-7316
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.0
>Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-7316) API to create a core is broken

[Jaya Naga Bhavana (JIRA)]

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

Jaya Naga Bhavana commented on SOLR-7316:
-

Hello,

Is this issue resolved?

> API to create a core is broken
> --
>
> Key: SOLR-7316
> URL: https://issues.apache.org/jira/browse/SOLR-7316
> Project: Solr
>  Issue Type: Bug
>  Components: Server
>Affects Versions: 5.0
>Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl 
> 'http://localhost:8983/solr/admin/cores?action=CREATE=new_core=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> Error CREATEing SolrCore 'new_core': Unable to create core [new_core] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or 
> '/var/solr/data/new_core/conf'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API 
> documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> In fact, yes. The thing to remember here is that you're using a much
> older approach that had its roots in the pre-cloud days.
> {quote}
> *The whole point of creating APIs is to abstract out details that the caller 
> doesn't need to know, and yet this API requires an understanding of Solr's 
> internal file structure and history of the project?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11662) Make overlapping query term scoring configurable per field type

[Doug Turnbull (JIRA)]

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

Doug Turnbull updated SOLR-11662:
-
Summary: Make overlapping query term scoring configurable per field type  
(was: More than SynonymQuery: Let overlapping query terms model 
hypernym/hyponym relationships)

> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values for scoreOverlaps are:
> *as_one_term*
> Default, most synonym use cases. Uses SynonymQuery
> Treats all terms as if they're exactly equivalent, with document frequency 
> from underlying terms blended 
> *pick_best*
> For a given document, score using the best scoring synonym (ie dismax over 
> generated terms). 
> Useful when synonyms not exactly equilevant. Instead they are used to model 
> hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
> scores will reflect that quality
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby | text:cat | text:animal)
> *as_distinct_terms
> *(The pre 6.0 behavior.)
> Compromise between pick_best and as_oneSterm
> Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
> scores stack, so documents with more tabby, cat, or animal the better w/ a 
> bias towards the term with highest specificity
> Terms are turned into a boolean OR query, with documen frequencies not blended
> IE this query time expansion
> tabby => tabby, cat, animal
> Searching "text", generates the dismax (text:tabby  text:cat text:animal)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11662) Make overlapping query term scoring configurable per field type

[Doug Turnbull (JIRA)]

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

Doug Turnbull updated SOLR-11662:
-
Description: 
This patch customizes the query-time behavior when query terms overlap 
positions. Right now the only option is SynonymQuery. This is a fantastic 
default & improvement on past versions. However, there are use cases where 
terms overlap positions but don't carry exact synonymy relationships. Often 
synonyms are actually used to model hypernym/hyponym relationships using 
synonyms (or other analyzers). So the individual term scores matter, with terms 
with higher specificity (hyponym) scoring higher than terms with lower 
specificity (hypernym).

This patch adds the fieldType setting scoreOverlaps, as in:


{code:java}
  

{code}


Valid values for scoreOverlaps are:

*as_one_term*
Default, most synonym use cases. Uses SynonymQuery
Treats all terms as if they're exactly equivalent, with document frequency from 
underlying terms blended 

*pick_best*
For a given document, score using the best scoring synonym (ie dismax over 
generated terms). 
Useful when synonyms not exactly equilevant. Instead they are used to model 
hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
scores will reflect that quality
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby | text:cat | text:animal)

*as_distinct_terms*
(The pre 6.0 behavior.)
Compromise between pick_best and as_oneSterm
Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
scores stack, so documents with more tabby, cat, or animal the better w/ a bias 
towards the term with highest specificity
Terms are turned into a boolean OR query, with documen frequencies not blended
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby  text:cat text:animal)


  was:
This patch customizes the query-time behavior when query terms overlap 
positions. Right now the only option is SynonymQuery. This is a fantastic 
default & improvement on past versions. However, there are use cases where 
terms overlap positions but don't carry exact synonymy relationships. Often 
synonyms are actually used to model hypernym/hyponym relationships using 
synonyms (or other analyzers). So the individual term scores matter, with terms 
with higher specificity (hyponym) scoring higher than terms with lower 
specificity (hypernym).

This patch adds the fieldType setting scoreOverlaps, as in:


{code:java}
  

{code}


Valid values for scoreOverlaps are:

*as_one_term*
Default, most synonym use cases. Uses SynonymQuery
Treats all terms as if they're exactly equivalent, with document frequency from 
underlying terms blended 

*pick_best*
For a given document, score using the best scoring synonym (ie dismax over 
generated terms). 
Useful when synonyms not exactly equilevant. Instead they are used to model 
hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
scores will reflect that quality
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby | text:cat | text:animal)

*as_distinct_terms
*(The pre 6.0 behavior.)
Compromise between pick_best and as_oneSterm
Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
scores stack, so documents with more tabby, cat, or animal the better w/ a bias 
towards the term with highest specificity
Terms are turned into a boolean OR query, with documen frequencies not blended
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby  text:cat text:animal)



> Make overlapping query term scoring configurable per field type
> ---
>
> Key: SOLR-11662
> URL: https://issues.apache.org/jira/browse/SOLR-11662
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Doug Turnbull
> Fix For: 7.2, master (8.0)
>
>
> This patch customizes the query-time behavior when query terms overlap 
> positions. Right now the only option is SynonymQuery. This is a fantastic 
> default & improvement on past versions. However, there are use cases where 
> terms overlap positions but don't carry exact synonymy relationships. Often 
> synonyms are actually used to model hypernym/hyponym relationships using 
> synonyms (or other analyzers). So the individual term scores matter, with 
> terms with higher specificity (hyponym) scoring higher than terms with lower 
> specificity (hypernym).
> This patch adds the fieldType setting scoreOverlaps, as in:
> {code:java}
>class="solr.TextField" positionIncrementGap="100" multiValued="true">
> {code}
> Valid values for 

[jira] [Created] (SOLR-11662) More than SynonymQuery: Let overlapping query terms model hypernym/hyponym relationships

[Doug Turnbull (JIRA)]

Doug Turnbull created SOLR-11662:


 Summary: More than SynonymQuery: Let overlapping query terms model 
hypernym/hyponym relationships
 Key: SOLR-11662
 URL: https://issues.apache.org/jira/browse/SOLR-11662
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Doug Turnbull
 Fix For: 7.2, master (8.0)


This patch customizes the query-time behavior when query terms overlap 
positions. Right now the only option is SynonymQuery. This is a fantastic 
default & improvement on past versions. However, there are use cases where 
terms overlap positions but don't carry exact synonymy relationships. Often 
synonyms are actually used to model hypernym/hyponym relationships using 
synonyms (or other analyzers). So the individual term scores matter, with terms 
with higher specificity (hyponym) scoring higher than terms with lower 
specificity (hypernym).

This patch adds the fieldType setting scoreOverlaps, as in:


{code:java}
  

{code}


Valid values for scoreOverlaps are:

*as_one_term*
Default, most synonym use cases. Uses SynonymQuery
Treats all terms as if they're exactly equivalent, with document frequency from 
underlying terms blended 

*pick_best*
For a given document, score using the best scoring synonym (ie dismax over 
generated terms). 
Useful when synonyms not exactly equilevant. Instead they are used to model 
hypernym/hyponym relationships. Such as expanding to synonyms of where terms 
scores will reflect that quality
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby | text:cat | text:animal)

*as_distinct_terms
*(The pre 6.0 behavior.)
Compromise between pick_best and as_oneSterm
Appropriate when synonyms reflect a hypernym/hyponym relationship, but lets 
scores stack, so documents with more tabby, cat, or animal the better w/ a bias 
towards the term with highest specificity
Terms are turned into a boolean OR query, with documen frequencies not blended
IE this query time expansion

tabby => tabby, cat, animal

Searching "text", generates the dismax (text:tabby  text:cat text:animal)




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/873/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.update.processor.TimePartitionedUpdateProcessorTest.test

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([4A0A9E5F421E037:8CF4963F5ADD8DCF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.update.processor.TimePartitionedUpdateProcessorTest.assertInvariants(TimePartitionedUpdateProcessorTest.java:245)
at 
org.apache.solr.update.processor.TimePartitionedUpdateProcessorTest.test(TimePartitionedUpdateProcessorTest.java:123)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8054:
--

Some of the planes are cutting the "planet" too thin and therefore making the 
shape too small, that is how I visualize it.

I place the following statement at the end of the constructor:

{code}
assert isWithin(center);
{code}

it seems to be always true. Maybe we can divide the circle in four sectors 
using planes that goes from the center of the shape to each of the cardinal 
points (north/south/east and west) and the center of the world (I think 
parallel and perpendicular planes would not work). 

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-11600 at 11/21/17 8:32 PM:
-

There is an approach in Java that you can use to build the expressions so you 
don't have to use the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how a TupleStream turns itself into a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string or a 
TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.









was (Author: joel.bernstein):
There is an approach in Java that you can use to build the expressions so you 
don't have to use the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how a TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.








> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-11600 at 11/21/17 8:31 PM:
-

There is an approach in Java that you can use to build the expressions so you 
don't have to use the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how a TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.









was (Author: joel.bernstein):
There is an approach in Java that you can use to build the expressions so you 
don't have to use the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.








> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11600:
---

There is an approach in Java that you can use to build the expressions so you 
don't have to build the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.








> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-11600 at 11/21/17 8:31 PM:
-

There is an approach in Java that you can use to build the expressions so you 
don't have to use the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.









was (Author: joel.bernstein):
There is an approach in Java that you can use to build the expressions so you 
don't have to build the strings directly.

The approach is to use the StreamExpression classes to construct the expression:

StreamExpression
StreamExpressionParameter
StreamExpressionNamedParameter
StreamExpressionValue

If you take a look at the toExpression method of many of the Streams you'll see 
how TupleStream turns itself to a StreamExpression.

You can think of Streaming Expressions as having three representations:

1) String Expression: used as the query language and serialization format.
2) StreamExpression: intermediate format that can become a string a TupleStream
3) TupleStream: these are the compiled stream objects.

At Alfresco we have code that uses the StreamExpression classes to build 
expressions and compile them to TupleStreams. This has worked quite well for us.








> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-8055:


[~dsmiley] Hmmm, somehow I had it in my mind that some of the randomizing would 
use MemoryIndex, but actually, you know, _looking_ at the code it appears not 
to be true, never mind...

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+32) - Build # 20966 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20966/
Java: 64bit/jdk-10-ea+32 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=13307, name=searcherExecutor-6398-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@10-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=13307, name=searcherExecutor-6398-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@10-ea/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([A95A17D6CF761C31]:0)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
There are still zombie threads that couldn't be terminated:1) 
Thread[id=13307, name=searcherExecutor-6398-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at 
java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
 at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
 at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
 at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
 at java.base@10-ea/java.lang.Thread.run(Thread.java:844)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie 
threads that couldn't be terminated:
   1) Thread[id=13307, name=searcherExecutor-6398-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method)
at 
java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
at 
java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074)
at 
java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
at 
java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base@10-ea/java.lang.Thread.run(Thread.java:844)
at __randomizedtesting.SeedInfo.seed([A95A17D6CF761C31]:0)


FAILED:  org.apache.solr.core.TestLazyCores.testNoCommit

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([A95A17D6CF761C31:763AB60704517F94]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:901)
at org.apache.solr.core.TestLazyCores.check10(TestLazyCores.java:855)
at 
org.apache.solr.core.TestLazyCores.testNoCommit(TestLazyCores.java:832)
at 

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-8055:
--

MemoryIndex is mainly used by some of the highlighters, and they don't put 
docValues in it.  So I would be very surprised to learn if some Solr test is 
related to this.  At least I assume [~erickerickson] you are talking about Solr 
test failures.

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-11573.
--
   Resolution: Fixed
 Assignee: Cassandra Targett
Fix Version/s: master (8.0)
   7.2

Patch was good, just changed the order of the front-matter attributes for 
consistency and noticed a couple places where URLs were being rendered as links 
when we probably didn't want them to be.

Thanks [~gerlowskija]!

> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Cassandra Targett
>Priority: Trivial
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11573:


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

SOLR-11573: Add solr-root-paths param to allow pulling in code blocks from 
outside solr-ref-guide tree


> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11573:


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

SOLR-11573: Add solr-root-paths param to allow pulling in code blocks from 
outside solr-ref-guide tree


> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

I know exactly what is happening here.

It's best to visualize this as a delta from a single plane slicing the world.  
When we break up the single plane into multiple pieces, some will angle below 
the level of the original plane, and some will angle above.  The ones that 
angle above will "cut off" some points that ought to be in the shape.

The solution involves limiting the reach of each plane by bounding it with 
another plane that goes through the middle of the world and separates the 
"good" part of the plane from the "bad" part of the plane.  This is easy in 
principle but in practice we will need to determine the right cutoff plane by 
examining all the points we've stitched through around the edge of the circle, 
which is an O(n^2) operation, which scares me.  Let me consider some more 
before implementing anything.

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_144) - Build # 872 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/872/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

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

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at 
__randomizedtesting.SeedInfo.seed([BC13C3A19774A866:3447FC7B3988C59E]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1275)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:448)
at 
org.apache.solr.cloud.CleanupOldIndexTest.test(CleanupOldIndexTest.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


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

Error Message:
Timeout occured while waiting response from server at: http://127.0.0.1:33545

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: 

[jira] [Commented] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Aroop (JIRA)]

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

Aroop commented on SOLR-11600:
--

Thanks Joel.
Its good to know what the roadmap is here. 
Personally though I am a fan of SolrStreaming Java classes approach, it does 
set Solr apart from other data stores.
Although, I can imagine this seeming complicated to many users in java api, I 
guess I have been programming using it a lot recently so I might be a bit 
biased as I feel comfortable so far :) 
But then we are moving in the sql direction or rather a DSL direction 
completely? 
A compile-time correctness-verification feature, then becomes vital for 
programers' confidence.
Maybe when there is enough time and a larger audience (greater than just me :) 
), you can revisit this ;)

Amrit - I am not 100% sure I understand what the next action items are, based 
on your note, but I guess you will keep us posted.

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11426) TestLazyCores fails too often

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11426:


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

SOLR-11426: TestLazyCores fails too often, debugging


> TestLazyCores fails too often
> -
>
> Key: SOLR-11426
> URL: https://issues.apache.org/jira/browse/SOLR-11426
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11426-take-2-debug.patch
>
>
> Rather then re-opening SOLR-10101 I thought I'd start a new issue. I may have 
> to put some code up on Jenkins to test, last time I tried to get this to fail 
> locally I couldn't



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.client.solrj.io.graph.GraphTest

Error Message:
Error from server at http://127.0.0.1:38905/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38905/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([D6036D4EB09781C6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.client.solrj.io.graph.GraphTest.setupCluster(GraphTest.java:62)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 14922 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.io.graph.GraphTest
   [junit4]   2> 10009 INFO  (SUITE-GraphTest-seed#[D6036D4EB09781C6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.io.graph.GraphTest_D6036D4EB09781C6-001/init-core-data-001
   [junit4]   2> 10010 WARN  (SUITE-GraphTest-seed#[D6036D4EB09781C6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=2 numCloses=2
   [junit4]   2> 10011 INFO  (SUITE-GraphTest-seed#[D6036D4EB09781C6]-worker) [ 
   ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 10012 INFO  

[jira] [Updated] (SOLR-11426) TestLazyCores fails too often

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-11426:
--
Attachment: SOLR-11426-take-2-debug.patch

Gathering more information, trunk only

> TestLazyCores fails too often
> -
>
> Key: SOLR-11426
> URL: https://issues.apache.org/jira/browse/SOLR-11426
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-11426-take-2-debug.patch
>
>
> Rather then re-opening SOLR-10101 I thought I'd start a new issue. I may have 
> to put some code up on Jenkins to test, last time I tried to get this to fail 
> locally I couldn't



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

I added code to be sure planetModel.surfacePointOnBearing() was working as 
expected for this test.  It is.

So what we have is a concavity in the shape that we didn't anticipate but 
apparently occurs even with a large arc section - a full 1/4 of the circle.

I'll need to think about this carefully.  Not only is getRelationship() not 
going to work right, but isWithin() will fail too for some points near the edge 
of the circle.  Basically we need to figure out how to get isWithin() to work 
properly.  It may be that we will need to partition the circle into four 
quadrants for the purpose of computing isWithin().

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-8055:


[~simonw] Yes, I'm thinking about ones that have been hanging around for a long 
time but don't reproduce reliably. I keep meaning to look at them "when time 
permits". Siiighh. If I'm _really_ lucky some of them will magically have gone 
away ;).

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 87 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/87/

9 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPIDistributedZkTest.addReplicaTest

Error Message:
Could not load collection from ZK: addReplicaColl

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
addReplicaColl
at 
__randomizedtesting.SeedInfo.seed([EE451EB8CA1A83C8:7DE5499E4412C819]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1122)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:647)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:130)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:110)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:247)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.addReplicaTest(CollectionsAPIDistributedZkTest.java:634)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

I added this test to be sure that the plane construction itself wasn't buggy or 
had roundoff problems.  It doesn't fire:

{code}
  if (plane.isWithin(center) == false || !plane.evaluateIsZero(endPoint1) 
|| !plane.evaluateIsZero(endPoint2) || !plane.evaluateIsZero(middlePoint))
throw new IllegalStateException("SidedPlane constructor built a bad 
plane!!");
{code}

So we seem to be executing exactly what we're supposed to execute, but the 
planes we build essentially are describing a concave shape for at least part of 
the circle.  This is not what I'd have expected so I will need to drill deeper 
to figure out if:
(1) the concavity is the result of the Vincenti formula giving is erroneous 
points, or
(2) there's something about this shape that we've overlooked.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Simon Willnauer (JIRA)]

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

Simon Willnauer commented on LUCENE-8055:
-

[~erickerickson] just to be sure, you are talking about preexisting test issues?

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Erick Erickson (JIRA)]

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

Erick Erickson edited comment on LUCENE-8055 at 11/21/17 4:49 PM:
--

Hmm, I wonder if this is behind some of the test failures? I've never looked at 
whether some of the errors that are finding doc counts off were using 
memoryindex. Just saw a test failure go by for testGroupingDVOnly that might 
possibly be related.

I guess we'll see.


was (Author: erickerickson):
Hmm, I wonder if this is behind some of the test failures? I've never looked at 
whether some of the errors that are finding doc counts off were using 
memoryindex. Just saw a test failure go by for testGroupingDVOnly that might 
possibly be related.

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-8055:


Hmm, I wonder if this is behind some of the test failures? I've never looked at 
whether some of the errors that are finding doc counts off were using 
memoryindex. Just saw a test failure go by for testGroupingDVOnly that might 
possibly be related.

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

This ApproximationSlice, from what looks like bearing PI to bearing 3/2 * PI, 
has a plane that is clearly wrong-sided:

{code}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.4167995457372498, lon=0.7490618837385679([X=0.11208839933663924, 
Y=0.10422491708779671, Z=-0.9860323400481892])] bearing 1 = 3.141592653589793 
end point 2 = [lat=-1.1568143342909227, 
lon=0.2126931363898965([X=0.3925264276620478, Y=0.08476983187716604, 
Z=-0.9139727708426665])] bearing 2 = 4.71238898038469 middle point = 
[lat=-1.312804505159855, lon=0.143141791092118([X=0.2520197932856809, 
Y=0.03632298494493567, Z=-0.9649509184003219])] middle bearing = 
3.9269908169872414}
{code}

Why is it wrong-sided?  That's the question...


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

Here's the output of my instrumentation.

{code}
   [junit4] Suite: org.apache.lucene.spatial3d.geom.GeoCircleTest
   [junit4]   1> Edgepoint = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])]
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.4167995457372498, lon=0.7490618837385679([X=0.11208839933663924, 
Y=0.10422491708779671, Z=-0.9860323400481892])] bearing 1 = 3.141592653589793 
end point 2 = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])] bearing 2 = 6.283185307179586 middle point = 
[lat=-1.1568143342909227, lon=0.2126931363898965([X=0.3925264276620478, 
Y=0.08476983187716604, Z=-0.9139727708426665])] middle bearing = 
4.71238898038469}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.1568143342909227, lon=0.2126931363898965([X=0.3925264276620478, 
Y=0.08476983187716604, Z=-0.9139727708426665])] bearing 1 = 4.71238898038469 
end point 2 = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])] bearing 2 = 6.283185307179586 middle point = 
[lat=-1.043326466955262, lon=0.4560258695181112([X=0.4512829845443862, 
Y=0.22135828041929292, Z=-0.8628818835741965])] middle bearing = 
5.497787143782138}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.043326466955262, lon=0.4560258695181112([X=0.4512829845443862, 
Y=0.22135828041929292, Z=-0.8628818835741965])] bearing 1 = 5.497787143782138 
end point 2 = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])] bearing 2 = 6.283185307179586 middle point = 
[lat=-1.0127673148582417, lon=0.599891511707467([X=0.43649204805694897, 
Y=0.2985507636602103, Z=-0.847197651618412])] middle bearing = 
5.890486225480862}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.0127673148582417, lon=0.599891511707467([X=0.43649204805694897, 
Y=0.2985507636602103, Z=-0.847197651618412])] bearing 1 = 5.890486225480862 end 
point 2 = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])] bearing 2 = 6.283185307179586 middle point = 
[lat=-1.0049893310453464, lon=0.6741556908984467([X=0.4182829096148721, 
Y=0.33422504249975515, Z=-0.8430786899864591])] middle bearing = 
6.086835766330224}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.0049893310453464, lon=0.6741556908984467([X=0.4182829096148721, 
Y=0.33422504249975515, Z=-0.8430786899864591])] bearing 1 = 6.086835766330224 
end point 2 = [lat=-1.0023843124849925, 
lon=0.7490618837385661([X=0.39370800817512397, Y=0.3660877017755803, 
Z=-0.8416877339642606])] bearing 2 = 6.283185307179586 middle point = 
[lat=-1.0030361472745981, lon=0.7115689671538252([X=0.4067373993405717, 
Y=0.3507135750733039, Z=-0.8420363194530506])] middle bearing = 
6.1850105367549055}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.0127673148582417, lon=0.599891511707467([X=0.43649204805694897, 
Y=0.2985507636602103, Z=-0.847197651618412])] bearing 1 = 5.890486225480862 end 
point 2 = [lat=-1.0049893310453464, 
lon=0.6741556908984467([X=0.4182829096148721, Y=0.33422504249975515, 
Z=-0.8430786899864591])] bearing 2 = 6.086835766330224 middle point = 
[lat=-1.0082369093007926, lon=0.6369025037172893([X=0.4282331206621356, 
Y=0.31678129946746897, Z=-0.8448047213712183])] middle bearing = 
5.988660995905542}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.043326466955262, lon=0.4560258695181112([X=0.4512829845443862, 
Y=0.22135828041929292, Z=-0.8628818835741965])] bearing 1 = 5.497787143782138 
end point 2 = [lat=-1.0127673148582417, 
lon=0.599891511707467([X=0.43649204805694897, Y=0.2985507636602103, 
Z=-0.847197651618412])] bearing 2 = 5.890486225480862 middle point = 
[lat=-1.025607482497055, lon=0.5269385452500206([X=0.4476347061399733, 
Y=0.260439205600348, Z=-0.8538850334536305])] middle bearing = 5.6941366846315}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.025607482497055, lon=0.5269385452500206([X=0.4476347061399733, 
Y=0.260439205600348, Z=-0.8538850334536305])] bearing 1 = 5.6941366846315 end 
point 2 = [lat=-1.0127673148582417, 
lon=0.599891511707467([X=0.43649204805694897, Y=0.2985507636602103, 
Z=-0.847197651618412])] bearing 2 = 5.890486225480862 middle point = 
[lat=-1.0185644009167876, lon=0.563207410226136([X=0.442980071667477, 
Y=0.27970943891565886, Z=-0.8502342472141794])] middle bearing = 
5.792311455056181}
   [junit4]   1> Processing next slice... {end point 1 = 
[lat=-1.0185644009167876, 

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

At some point it constructs a plane that the edgepoint is not inside.  When 
that happens, the circle becomes invalid.

I'm going to instrument the plane approximation to make sure they make sense, 
and to see at what point this goes bad.  If it occurs after many iterations, I 
would conclude that numeric imprecision is the problem.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/871/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC

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

Error Message:
Error from server at http://127.0.0.1:33807/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:33807/solr: create the collection time out:180s
at 
__randomizedtesting.SeedInfo.seed([EE5A1432BE68E195:660E2BE810948C6D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at org.apache.solr.cloud.DeleteShardTest.test(DeleteShardTest.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

The circle edges are definitely getting constructed incorrectly.  Adding this 
to the end of the constructor yields "false" for both circles:

{code}
System.out.println("Is edgepoint within? "+isWithin(edgePoint));
{code}




> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8054:
--

I think the way we are creating the planes, it makes somewhat the circle 
smaller. The edge point of a circle seems to be out of the circle itself which 
probably is wrong. And the edge point of the smallest circle is out as well 
because it is close to the edge.

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8054:
--

I think the problem is not there as the shapes do not intersects. The problem 
actually comes when checking the membership of the notable edge points of the 
small circle into the big circle. It should be true but it returns false.



> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

A trace through the getRelationship() method finds that this clause:

{code}
if (intersects(geoShape)){
  System.out.println(" intersects");
  return  GeoArea.OVERLAPS;
}
{code}

... does not fire.  Hard to tell but that may well be OK.  But the edge points 
from each circle are outside the other shape (NONE_INSIDE), which also might be 
in error; I would expect one to be inside at least and that's not the case.  
Looking deeper.

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11573:
--

bq. The thing that's confusing me is why the path doesn't break in the file

Oh...scratch all that, I misread the order of inheritance. Whatever is passed 
to the API or CLI overrides what's in the document.

> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on SOLR-11573 at 11/21/17 3:48 PM:


[~gerlowskija] - I'm looking at the patch, and I'm a little confused so want to 
be sure I understand it for later updating the meta-docs for others to use this 
also:

* The {{build.xml}} and {{_config.yml.template}} files set a {{solr-root-path}} 
parameter that is a path relative to the {{solr/build/solr-ref-guide/content}} 
directory, so the root ends up as {{solr/}}.
* The {{using-solrj.adoc}} file sets a {{solr-root-path}} parameter that is a 
path relative to the {{solr/solr-ref-guide/src}} directory, again so the root 
ends up as {{solr/}}.
* The {{solr-root-path}} param is used in another param {{example-source-dir}} 
with the path to the dir that has the example file.

The thing that's confusing me is why the path doesn't break in the file when 
the conversion is happening. My understanding of the inheritance here is that 
the param on the document overrides the param set in our config files ("passed 
to the API or CLI" as described here: 
http://asciidoctor.org/docs/user-manual/#attribute-assignment-precedence), 
which would mean that the path would be incorrect during build (it would go 
only to {{solr/build}} instead of {{solr}}).

Do you have any insights on this from looking at this closer than I have?


was (Author: ctargett):
[~gerlowskija] - I'm looking at the patch, and I'm a little confused so want to 
be sure I understand it for later updating the meta-docs for others to use this 
also:

* The {{build.xm}}l and {{_config.yml.template}} files set a {{solr-root-path}} 
parameter that is a path relative to the {{solr/build/solr-ref-guide/content}} 
directory, so the root ends up as {{solr/}}.
* The {{using-solrj.adoc}} file sets a {{solr-root-path}} parameter that is a 
path relative to the {{solr/solr-ref-guide/src}} directory, again so the root 
ends up as {{solr/}}.
* The {{solr-root-path}} param is used in another param {{example-source-dir}} 
with the path to the dir that has the example file.

The thing that's confusing me is why the path doesn't break in the file when 
the conversion is happening. My understanding of the inheritance here is that 
the param on the document overrides the param set in our config files ("passed 
to the API or CLI" as described here: 
http://asciidoctor.org/docs/user-manual/#attribute-assignment-precedence), 
which would mean that the path would be incorrect during build (it would go 
only to {{solr/build}} instead of {{solr}}).

Do you have any insights on this from looking at this closer than I have?

> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11573:
--

[~gerlowskija] - I'm looking at the patch, and I'm a little confused so want to 
be sure I understand it for later updating the meta-docs for others to use this 
also:

* The {{build.xm}}l and {{_config.yml.template}} files set a {{solr-root-path}} 
parameter that is a path relative to the {{solr/build/solr-ref-guide/content}} 
directory, so the root ends up as {{solr/}}.
* The {{using-solrj.adoc}} file sets a {{solr-root-path}} parameter that is a 
path relative to the {{solr/solr-ref-guide/src}} directory, again so the root 
ends up as {{solr/}}.
* The {{solr-root-path}} param is used in another param {{example-source-dir}} 
with the path to the dir that has the example file.

The thing that's confusing me is why the path doesn't break in the file when 
the conversion is happening. My understanding of the inheritance here is that 
the param on the document overrides the param set in our config files ("passed 
to the API or CLI" as described here: 
http://asciidoctor.org/docs/user-manual/#attribute-assignment-precedence), 
which would mean that the path would be incorrect during build (it would go 
only to {{solr/build}} instead of {{solr}}).

Do you have any insights on this from looking at this closer than I have?

> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11584) Ref Guide: support Bootstrap components like tabs and pills

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11584:


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

SOLR-11584: CSS changes for HTML tabs: change padding in tab panes; add space 
between tabs


> Ref Guide: support Bootstrap components like tabs and pills
> ---
>
> Key: SOLR-11584
> URL: https://issues.apache.org/jira/browse/SOLR-11584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11584.patch, SOLR-11584_customjs.patch, 
> SOLR-11584_customjs.patch, SOLR-11584_customjs.patch, refguide-tabs.png, 
> tabbed_api_output_example.png
>
>
> The theme I initially copied as the basis for the new Ref Guide included a 
> Bootstrap integration, which has the potential to provide us with a number of 
> options, such as organizing some content on a page into tabs (to present the 
> same information in multiple ways - such as Windows vs Unix commands, or 
> hand-editing schema.xml/managed-schema vs Schema API examples). 
> However, the way AsciiDoctor content is inserted into a Jekyll template made 
> it difficult to know how to use some of Bootstrap's features. Particularly 
> since we have to make sure whatever we put into the content comes out right 
> in the PDF.
> I had a bit of a breakthrough on this, and feel confident we can make 
> straightforward instructions for anyone who might want to add this feature to 
> their content. A patch will follow shortly with more details but the summary 
> is:
> * Add an AsciiDoctor passthrough block that includes the Bootstrap HTML code 
> to create the tabs.
> ** This has an {{ifdef::backend-html5[]}} rule on it, so it will only be used 
> if the output format is HTML. The PDF will ignore this section entirely.
> * Use AsciiDoctor's "role" support to name the proper class names, which 
> AsciiDoctor will convert into the right {{}} elements in the HTML.
> ** These will take multiple class names and a section ID, which is perfect 
> for our needs.
> ** One caveat is the divs need to be properly nested, and must be defined on 
> blocks so all the content is inserted into the tab boxes appropriately. This 
> gets a little complicated because you can't nest blocks of the same type 
> (yet), but I found two block types we aren't using otherwise.
> ** The PDF similarly ignores these classes and IDs because it doesn't know 
> what to do with custom classes (but in the future these may be supported and 
> we could define these in a special way if we want).
> * Modify some of the CSS to display the way we want since AsciiDoctor inserts 
> some of its own classes between the defined classes and the inheritance needs 
> to be set up right. Also the default styling for the blocks needs to be 
> changed so it doesn't look strange.
> I'll include a patch with a sample file that has this working, plus detailed 
> instructions in the metadocs. In the meantime, I've attached a screenshot 
> that shows a small snippet from my testing. 
> While the focus here is using tabs & pills, we will be able to use the same 
> principles to support collapsing sections if that's preferred for 
> presentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11584) Ref Guide: support Bootstrap components like tabs and pills

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11584:


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

SOLR-11584: CSS changes for HTML tabs: change padding in tab panes; add space 
between tabs


> Ref Guide: support Bootstrap components like tabs and pills
> ---
>
> Key: SOLR-11584
> URL: https://issues.apache.org/jira/browse/SOLR-11584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11584.patch, SOLR-11584_customjs.patch, 
> SOLR-11584_customjs.patch, SOLR-11584_customjs.patch, refguide-tabs.png, 
> tabbed_api_output_example.png
>
>
> The theme I initially copied as the basis for the new Ref Guide included a 
> Bootstrap integration, which has the potential to provide us with a number of 
> options, such as organizing some content on a page into tabs (to present the 
> same information in multiple ways - such as Windows vs Unix commands, or 
> hand-editing schema.xml/managed-schema vs Schema API examples). 
> However, the way AsciiDoctor content is inserted into a Jekyll template made 
> it difficult to know how to use some of Bootstrap's features. Particularly 
> since we have to make sure whatever we put into the content comes out right 
> in the PDF.
> I had a bit of a breakthrough on this, and feel confident we can make 
> straightforward instructions for anyone who might want to add this feature to 
> their content. A patch will follow shortly with more details but the summary 
> is:
> * Add an AsciiDoctor passthrough block that includes the Bootstrap HTML code 
> to create the tabs.
> ** This has an {{ifdef::backend-html5[]}} rule on it, so it will only be used 
> if the output format is HTML. The PDF will ignore this section entirely.
> * Use AsciiDoctor's "role" support to name the proper class names, which 
> AsciiDoctor will convert into the right {{}} elements in the HTML.
> ** These will take multiple class names and a section ID, which is perfect 
> for our needs.
> ** One caveat is the divs need to be properly nested, and must be defined on 
> blocks so all the content is inserted into the tab boxes appropriately. This 
> gets a little complicated because you can't nest blocks of the same type 
> (yet), but I found two block types we aren't using otherwise.
> ** The PDF similarly ignores these classes and IDs because it doesn't know 
> what to do with custom classes (but in the future these may be supported and 
> we could define these in a special way if we want).
> * Modify some of the CSS to display the way we want since AsciiDoctor inserts 
> some of its own classes between the defined classes and the inheritance needs 
> to be set up right. Also the default styling for the blocks needs to be 
> changed so it doesn't look strange.
> I'll include a patch with a sample file that has this working, plus detailed 
> instructions in the metadocs. In the meantime, I've attached a screenshot 
> that shows a small snippet from my testing. 
> While the focus here is using tabs & pills, we will be able to use the same 
> principles to support collapsing sections if that's preferred for 
> presentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

Ok, I increased the repetition count and finally got one:

{code}
ant test  -Dtestcase=RandomGeoShapeRelationshipTest 
-Dtests.method=testRandom_LUCENE8054 -Dtests.seed=BBB02643B48B340B 
-Dtests.slow=true -Dtests.locale=es-PE -Dtests.timezone=Antarctica/South_Pole 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
{code}

... where the shapes are:

{code}
   [junit4]> Throwable #1: java.lang.AssertionError: circle1: 
GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
center=[lat=-1.2097332228999564, lon=0.749061883738567([X=0.25823775418663625, 
Y=0.2401212674846636, Z=-0.9338185278804293])], 
 radius=0.20785254459485322(11.909073566339822), accuracy=6.710701666727661E-9}
   [junit4]> circle2: GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
center=[lat=-1.2097332228999564, lon=0.749061883738567([X=0.25823775418663625, 
Y=0.2401212674846636, Z=-0.9338185278804293])], 
radius=0.20701584142315682(11.861134005896407), accuracy=1.0E-5}
{code}

I'll create a small test case that exercises this.


> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-8054:
--

I normally set the number of iterations quite high (let say minimum 1000), and 
I always get a bunch of errors. For example:

java.lang.AssertionError: circle1: GeoExactCircle: 
{planetmodel=PlanetModel.WGS84, center=[lat=-0.965939501615207, 
lon=-0.9321080733646145([X=0.3386013108150836, Y=-0.4560244617682681, 
Z=-0.8216325834900524])], radius=0.14028705605111907(8.037856232044339), 
accuracy=9.681113899315223E-6}
circle2: GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
center=[lat=-0.965939501615207, lon=-0.9321080733646145([X=0.3386013108150836, 
Y=-0.4560244617682681, Z=-0.8216325834900524])], 
radius=0.13986984510546016(8.013951805691422), accuracy=1.0E-5}

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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-9.0.1) - Build # 20964 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20964/
Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.DocValuesNotIndexedTest

Error Message:
Error from server at https://127.0.0.1:44323/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:44323/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([B8BD676FA39B166A]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.createCluster(DocValuesNotIndexedTest.java:85)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


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

Error Message:


Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([B8BD676FA39B166A]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1275)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:448)
at 
org.apache.solr.cloud.TestLeaderElectionWithEmptyReplica.beforeClass(TestLeaderElectionWithEmptyReplica.java:56)
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 

[jira] [Commented] (LUCENE-8054) Test failure, Geo3dRptTest

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-8054:
-

[~ivera], I've run your random test a dozen times with no failure.

Next time you get a failure, can you cut and paste the two circle dumps please? 
 Thanks!!



> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar edited comment on SOLR-11600 at 11/21/17 2:34 PM:
---

Thank you [~joel.bernstein] for the explanation; 

bq. Each expression has it's own set of rules for the parameters that it 
accepts so we can get very specific with how type safety is handled
I completely understand this by the following example
{code}
replace( fieldA, add( fieldB, if( eq(fieldC,0), 0, 1)))
{code}
This nested evaluation and operation is not possible to create with current 
Java constructors available, as the constructors of evaluators and operations 
have most just one type of constructor with {{StreamExpression}} 
(StreamExpressionParameter interface) parameter which the evaluators or 
operators doesn't implement (they implement Expressible interface).
{code}
  public AddEvaluator(StreamExpression expression, StreamFactory factory) 
throws IOException{
super(expression, factory);

if(containedEvaluators.size() < 1){
  throw new IOException(String.format(Locale.ROOT,"Invalid expression %s - 
expecting at least one value but found 
%d",expression,containedEvaluators.size()));
}
  }
{code}

To accomodate the above request, strongly types java objects for all, we need 
to create rule-based constructors for all the evaluators and operators, so that 
those can be used in {{SelectStream}}.


was (Author: sarkaramr...@gmail.com):
Thank you [~joel.bernstein] for the explanation; 

> Each expression has it's own set of rules for the parameters that it accepts 
> so we can get very specific with how type safety is handled
I completely understand this by the following example
{code}
replace( fieldA, add( fieldB, if( eq(fieldC,0), 0, 1)))
{code}
This nested evaluation and operation is not possible to create with current 
Java constructors available, as the constructors of evaluators and operations 
have most just one type of constructor with {{StreamExpression}} 
(StreamExpressionParameter interface) parameter which the evaluators or 
operators doesn't implement (they implement Expressible interface).
{code}
  public AddEvaluator(StreamExpression expression, StreamFactory factory) 
throws IOException{
super(expression, factory);

if(containedEvaluators.size() < 1){
  throw new IOException(String.format(Locale.ROOT,"Invalid expression %s - 
expecting at least one value but found 
%d",expression,containedEvaluators.size()));
}
  }
{code}

To accomodate the above request, strongly types java objects for all, we need 
to create rule-based constructors for all the evaluators and operators, so that 
those can be used in {{SelectStream}}.

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> 

[jira] [Commented] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11600:
-

Thank you [~joel.bernstein] for the explanation; 

> Each expression has it's own set of rules for the parameters that it accepts 
> so we can get very specific with how type safety is handled
I completely understand this by the following example
{code}
replace( fieldA, add( fieldB, if( eq(fieldC,0), 0, 1)))
{code}
This nested evaluation and operation is not possible to create with current 
Java constructors available, as the constructors of evaluators and operations 
have most just one type of constructor with {{StreamExpression}} 
(StreamExpressionParameter interface) parameter which the evaluators or 
operators doesn't implement (they implement Expressible interface).
{code}
  public AddEvaluator(StreamExpression expression, StreamFactory factory) 
throws IOException{
super(expression, factory);

if(containedEvaluators.size() < 1){
  throw new IOException(String.format(Locale.ROOT,"Invalid expression %s - 
expecting at least one value but found 
%d",expression,containedEvaluators.size()));
}
  }
{code}

To accomodate the above request, strongly types java objects for all, we need 
to create rule-based constructors for all the evaluators and operators, so that 
those can be used in {{SelectStream}}.

> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11250) Add new LTR model which loads the model definition from the external resource

[Christine Poerschke (JIRA)]

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

Christine Poerschke updated SOLR-11250:
---
Attachment: SOLR-11250.patch

bq. ... the name of wrapper model can be used as the alias of the wrapped 
model. ... if we fix the name of wrapper model (like "prodModel"), users can 
always use same rerankModel (i.e, "prodModel") even if the version of wrapped 
model was changed (like "20171103" to "20171206"). I think this feature is 
useful because we can avoid the influence of updating models to users (in other 
words, we can develop front-end and back-end separately).

That summarises the wrapper/wrapped model naming choices very nicely, thank you!

(And actually people might even wish to use the wrapper model just in order to 
get the aliasing effect i.e. the wrapped model need not necessarily be a 'too 
large for ZooKeeper' model.)

Attaching slightly revised patch:
* reverted the wrapper/wrapped model name restriction as per above
* Solr Ref Guide entry:
** wrapper/wrapped model feature store restriction mentioned and illustrated
** added class to the models list/table
** no-longer-present "format" param removed from example
* solrconfig-ltr.xml comment updated to match the final DefaultWrapperModel 
class name
* rebased against latest master and added {{assumeWorkingMockito()}} calls as 
per SOLR-11606



{{ant precommit}} and tests pass. Does anyone else have any further comments or 
suggestions here at this point? If not then I think we're good to go here and 
I'll proceed to commit to master branch sometime next week and then cherry-pick 
to branch_7x a couple of days later.

> Add new LTR model which loads the model definition from the external resource
> -
>
> Key: SOLR-11250
> URL: https://issues.apache.org/jira/browse/SOLR-11250
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LTR
>Reporter: Yuki Yano
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-11250.patch, SOLR-11250.patch, SOLR-11250.patch, 
> SOLR-11250.patch, SOLR-11250_master.patch, SOLR-11250_master_v2.patch, 
> SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch
>
>
> We add new model which contains only the location of the external model and 
> loads it during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper 
> can be available.
> The new model works as the wrapper of existing models, and deligates APIs to 
> them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads 
> the external model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk 
> "file:///var/models/myModel.json", the definition of {{URIExternalModel}} 
> will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
> "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of 
> {{myModel.json}} will be used for scoring documents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11600:
---

Some of early Streaming API class have constructors that can be used directly. 
The current direction though is to move away from people using the Streaming 
API java classes directly. This is mainly because it's just too difficult to 
support the java classes directly because it doubles the documentation, tests 
etc...

It's also quite tricky to actually use the Java API directly and Streaming 
Expressions are much easier to work with. 

One of the things to consider is looking at where the Streaming Expressions can 
become more type safe. Each expression has it's own set of rules for the 
parameters that it accepts so we can get very specific with how type safety is 
handled. We could also add a command to the /stream handler to just compile the 
expression and not run, to see what errors occur at compile time.



> Add Constructor to SelectStream which takes StreamEvaluators as argument. 
> Current schema forces one to enter a stream expression string only 
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
>  Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup 
> stream in the following manner, but with instead with Strongly typed objects 
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as 
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s 
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a 
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields) 
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map 
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk-9) - Build # 319 - Still Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
Unexpected number of elements in the group for intGSF: 8

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 8
at 
__randomizedtesting.SeedInfo.seed([72124A8913759191:E9A924D15E2DA3CF]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:377)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 12639 lines...]
   [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest
   [junit4]   2> 1556138 INFO  
(SUITE-DocValuesNotIndexedTest-seed#[72124A8913759191]-worker) [] 
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: 
test.solr.allowed.securerandom=null & 

[jira] [Updated] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-8054:
-
Attachment: (was: LUCENE_8054_randomTest.patch)

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-8054:
-
Attachment: LUCENE_8054_randomTest.patch

> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-8054) Test failure, Geo3dRptTest

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-8054:
-
Attachment: LUCENE_8054_randomTest.patch

Hi [~daddywri],

I tried to reproduce the problem in a more systematic way and I created a test 
that reproduces a similar situation. Bad news is that the problem is still 
there (or maybe it is a different one). if you run the test enough times you 
get an error at some point.

The test creates a random circle and then, it creates another circle with the 
same center and a sliglty shorter radius. Relationship should never be disjoint.



> Test failure, Geo3dRptTest
> --
>
> Key: LUCENE-8054
> URL: https://issues.apache.org/jira/browse/LUCENE-8054
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial3d
>Reporter: David Smiley
>Assignee: Karl Wright
> Attachments: LUCENE-8054.patch, LUCENE_8054_randomTest.patch
>
>
> Geo3dRptTest.testOperations fails with seed 39BCAE475BCFB043 
> {noformat}
> NOTE: reproduce with: ant test  -Dtestcase=Geo3dRptTest 
> -Dtests.method=testOperations -Dtests.seed=39BCAE475BCFB043 
> -Dtests.locale=it-IT -Dtests.timezone=America/Boise -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
> java.lang.AssertionError: [Intersects] qIdx:3 Shouldn't match 
> I#5:Geo3D:GeoExactCircle: {planetmodel=PlanetModel.WGS84, 
> center=[lat=-1.0394053553992673, 
> lon=-1.9037325881389144([X=-0.16538181742539926, Y=-0.4782462267840722, 
> Z=-0.8609141805702146])], radius=1.1546166170607672(66.15465911325472), 
> accuracy=4.231100485201301E-4} Q:Geo3D:GeoExactCircle: 
> {planetmodel=PlanetModel.WGS84, center=[lat=-1.3165961602008989, 
> lon=-1.887137823746273([X=-0.07807211790901268, Y=-0.23850901911945152, 
> Z=-0.9659034153262631])], radius=1.432516663588956(82.07715890580914), 
> accuracy=3.172052880854355E-11}
>   at 
> __randomizedtesting.SeedInfo.seed([39BCAE475BCFB043:40C6F2143E9FE395]:0)
>   at org.junit.Assert.fail(Assert.java:93)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.fail(RandomSpatialOpStrategyTestCase.java:126)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperation(RandomSpatialOpStrategyTestCase.java:115)
>   at 
> org.apache.lucene.spatial.prefix.RandomSpatialOpStrategyTestCase.testOperationRandomShapes(RandomSpatialOpStrategyTestCase.java:55)
>   at 
> org.apache.lucene.spatial.spatial4j.Geo3dRptTest.testOperations(Geo3dRptTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> {noformat}
> CC [~kwri...@metacarta.com] [~ivera]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[Simon Willnauer (JIRA)]

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

Simon Willnauer resolved LUCENE-8055.
-
Resolution: Fixed

fixed

> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8055: MemoryIndex.MemoryDocValuesIterator returns 2 documents instead of 
1

Fixes a bug if there is a DV field in the MemoryIndex the
`MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1.


> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-8055: MemoryIndex.MemoryDocValuesIterator returns 2 documents instead of 
1

Fixes a bug if there is a DV field in the MemoryIndex the
`MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1.


> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-8055) MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1

[ASF subversion and git services (JIRA)]

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

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

Commit a6e968b55bd744171c8e5238438ed351d96634d2 in lucene-solr's branch 
refs/heads/branch_7_1 from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a6e968b ]

LUCENE-8055: MemoryIndex.MemoryDocValuesIterator returns 2 documents instead of 
1

Fixes a bug if there is a DV field in the MemoryIndex the
`MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1.


> MemoryIndex.MemoryDocValuesIterator returns 2 document instead of 1
> ---
>
> Key: LUCENE-8055
> URL: https://issues.apache.org/jira/browse/LUCENE-8055
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/other
>Reporter: Simon Willnauer
>Assignee: Simon Willnauer
> Fix For: master (8.0), 7.2, 7.1.1
>
> Attachments: LUCENE-8055.patch
>
>
> If there is a DV field in the MemoryIndex the 
> `MemoryIndex.MemoryDocValuesIterator` will return 2 documents instead of 1. 
> Simple off by one error and no tests. I have a patch ready for it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+32) - Build # 870 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/870/
Java: 64bit/jdk-10-ea+32 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes

Error Message:
Expected 4 docs are pending in core 
CoreDescriptor[name=tlog_replica_test_kill_tlog_replica_shard1_replica_t1;instanceDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestTlogReplica_27BAEABCB3CEC679-001/tempDir-001/node1/./tlog_replica_test_kill_tlog_replica_shard1_replica_t1]
 expected:<4> but was:<0>

Stack Trace:
java.lang.AssertionError: Expected 4 docs are pending in core 
CoreDescriptor[name=tlog_replica_test_kill_tlog_replica_shard1_replica_t1;instanceDir=/home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.TestTlogReplica_27BAEABCB3CEC679-001/tempDir-001/node1/./tlog_replica_test_kill_tlog_replica_shard1_replica_t1]
 expected:<4> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([27BAEABCB3CEC679:3BBB9731C66BB8EA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.cloud.TestTlogReplica.testOnlyLeaderIndexes(TestTlogReplica.java:467)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Issue Comment Deleted] (SOLR-11648) Create a web UI to display and execute suggestions

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-11648:
--
Comment: was deleted

(was: !table_for_suggestions.png|thumbnail!)

> Create a web UI to display and execute suggestions
> --
>
> Key: SOLR-11648
> URL: https://issues.apache.org/jira/browse/SOLR-11648
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: AutoScaling
>Reporter: Noble Paul
> Attachments: sidebar.jpg, suggestions_table.jpg, suggestions_table.jpg
>
>
> Steps to show suggestions
> {code}
> bin/solr start -e cloud
> #give the following inputs for prompts
> Please provide a name for your new collection: [gettingstarted] 
> mycoll
> How many shards would you like to split mycoll into? [2]
> 4
> How many replicas per shard would you like to create? [2] 
> 2
> #run the following command so that there are violating replicas
> curl http://localhost:8983/api/cluster/autoscaling -H 
> 'Content-type:application/json' -d{
> "set-cluster-policy": [
>   {"replica": "0", "shard": "#EACH", "port": 7574}
>   ]
> }
> #hit the suggestions end point at the url
> http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
> add an entry to the sidebar as follows
> !sidebar.jpg!
> use the output of the suggestions API to map to the table data
> !suggestions_table.jpg!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11573) Add live-preview support for ref-guide files using asciidoc-includes

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-11573:


Thanks for the clarification Cassandra.  Seems pretty harmless in this case.  
With that cleared up, this is ready-to-review whenever.

> Add live-preview support for ref-guide files using asciidoc-includes
> 
>
> Key: SOLR-11573
> URL: https://issues.apache.org/jira/browse/SOLR-11573
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Affects Versions: master (8.0)
>Reporter: Jason Gerlowski
>Priority: Trivial
> Attachments: SOLR-11573.patch
>
>
> With the completion of SOLR-11032, the "Using SolrJ" page in the ref-guide 
> now imports some Java code snippets from an external file.  This is done to 
> allow the snippets appearing in the documentation to be compiled/run as part 
> of the build...so they will always stay up to date.
> During the ref-guide build, this external file is copied into the ref-guide 
> build directory so that the references to it can be resolved.  However, 
> anyone using the "live preview" feature of modern asciidoc editors (Atom, 
> etc.), will find that the snippets don't appear in their live-preview.  
> Depending on your editor, a discrete error message may be displayed.
> It would be nice to fix this "papercut" in usability, or at least provide a 
> workaround.  The easier we can make it to improve the docs, the better.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
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-9.0.1) - Build # 20963 - Unstable!

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.TestCloudPseudoReturnFields

Error Message:
Error from server at https://127.0.0.1:36717/solr: create the collection time 
out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:36717/solr: create the collection time out:180s
at __randomizedtesting.SeedInfo.seed([2DB827E5B17482D4]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1103)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:883)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:816)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211)
at 
org.apache.solr.cloud.TestCloudPseudoReturnFields.createMiniSolrCloudCluster(TestCloudPseudoReturnFields.java:83)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)


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

Error Message:


Stack Trace:
java.lang.NullPointerException
at __randomizedtesting.SeedInfo.seed([2DB827E5B17482D4]:0)
at 
org.apache.solr.cloud.TestCloudPseudoReturnFields.afterClass(TestCloudPseudoReturnFields.java:114)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at