[jira] [Updated] (LUCENE-6575) Improve API of PhraseQuery.Builder

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat updated LUCENE-6575:
-
Attachment: LUCENE-6575.patch

Here is the patch.

> Improve API of PhraseQuery.Builder
> --
>
> Key: LUCENE-6575
> URL: https://issues.apache.org/jira/browse/LUCENE-6575
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
>Priority: Minor
> Attachments: LUCENE-6575.patch, LUCENE-6575.patch, LUCENE-6575.patch, 
> LUCENE-6575.patch, LUCENE-6575.patch
>
>
> From LUCENE-6531
> In current PhraseQuery.Builder API. User must retype field again and again :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder();
> builder.add(new Term("lyrics", "when"), 1);
> builder.add(new Term("lyrics", "believe"), 3);
> {code}
> Cleaner API :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder("lyrics");
> builder.add("when", 1);
> builder.add("believe", 3);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 880 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/880/

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

Error Message:
Captured an uncaught exception in thread: Thread[id=8690, name=collection1, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=8690, name=collection1, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46399: collection already exists: 
awholynewstresscollection_collection1_3
at __randomizedtesting.SeedInfo.seed([A89EF617A0495773]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:886)




Build Log:
[...truncated 10848 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J2/temp/solr.cloud.CollectionsAPIDistributedZkTest_A89EF617A0495773-001/init-core-data-001
   [junit4]   2> 1103147 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[A89EF617A0495773]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 1103147 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[A89EF617A0495773]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1103151 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1103151 INFO  (Thread-3356) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1103151 INFO  (Thread-3356) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1103251 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.ZkTestServer start zk server on port:40063
   [junit4]   2> 1103251 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1103258 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1103260 INFO  (zkCallback-1063-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@54591b16 
name:ZooKeeperConnection Watcher:127.0.0.1:40063 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1103261 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1103261 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1103261 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1103264 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1103264 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[A89EF617A0495773]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1103265 INFO  (zkCallback-1064-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@28d41c6a 
name:ZooKeeperConnection Watcher:127.0.0.1:40063/solr got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:No

[jira] [Commented] (LUCENE-6575) Improve API of PhraseQuery.Builder

[Cao Manh Dat (JIRA)]

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

Cao Manh Dat commented on LUCENE-6575:
--

>From idea of Robert I will leave the duplications and open another issue to 
>remove duplications from QueryParsers.

> Improve API of PhraseQuery.Builder
> --
>
> Key: LUCENE-6575
> URL: https://issues.apache.org/jira/browse/LUCENE-6575
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Cao Manh Dat
>Priority: Minor
> Attachments: LUCENE-6575.patch, LUCENE-6575.patch, LUCENE-6575.patch, 
> LUCENE-6575.patch
>
>
> From LUCENE-6531
> In current PhraseQuery.Builder API. User must retype field again and again :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder();
> builder.add(new Term("lyrics", "when"), 1);
> builder.add(new Term("lyrics", "believe"), 3);
> {code}
> Cleaner API :
> {code}
> PhraseQuery.Builder builder = new PhraseQuery.Builder("lyrics");
> builder.add("when", 1);
> builder.add("believe", 3);
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13130 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13130/
Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking

Error Message:
Shard a1x2_shard1_replica2 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica2 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([6A65A707D927FD27:2259FEC72D2CECB1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:109)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(Thre

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-6736:
--

The blobhandler does exactly the same. However, you just post the patch in 
whatever gotten you have I shall try to debug

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6590:
--

RE BoostQuery

+1 what a great idea Rob!  I too have found bugs related to improper boost 
handling from time to time (just yesterday in fact).   Heh, lets face it; every 
one of us have.  It's so easy to overlook.  I get that we're not starting from 
scratch (Yonik's point) but I'd hate to see such reasoning blocking Lucene from 
being the Lucene we want it to be.  Pragmatically that means, I think, doing 
this in 6.0 and having a transition to this from 5.0.  It's a pain but if 
someone is stepping up to do the work then great.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 716 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/716/

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

Error Message:
Captured an uncaught exception in thread: Thread[id=16497, name=collection4, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=16497, name=collection4, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:53032/uxupv, 
http://127.0.0.1:59222/uxupv, http://127.0.0.1:38217/uxupv, 
http://127.0.0.1:55026/uxupv, http://127.0.0.1:57926/uxupv]
at __randomizedtesting.SeedInfo.seed([E7088F6DFBD3183F]:0)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:896)
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request:[http://127.0.0.1:53032/uxupv, 
http://127.0.0.1:59222/uxupv, http://127.0.0.1:38217/uxupv, 
http://127.0.0.1:55026/uxupv, http://127.0.0.1:57926/uxupv]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:886)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38217/uxupv: KeeperErrorCode = Session expired 
for /overseer/collection-queue-work/qn-
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
... 7 more


FAILED:  org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest.test

Error Message:
Captured an uncaught exception in thread: Thread[id=8693, name=collection4, 
state=RUNNABLE, group=TGRP-HdfsCollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=8693, name=collection4, state=RUNNABLE, 
group=TGRP-HdfsCollectionsAPIDistributedZkTest]
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:60005: Could not find collection : 
awholynewstresscollection_collection4_0
at __randomizedtesting.SeedInfo.seed([E7088F6DFBD3183F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:235)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:227)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:893)




Build Log:
[...truncated 10806 lines...]
   [junit4] Suite: 
org.apache.solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-trunk/solr/build/solr-core/test/J2/temp/solr.cloud.hdfs.HdfsCollectionsAPIDistributedZkTest_E7088F6DFBD3183F-001/init-core-data-001
   [junit4]   2> 933962 INFO  
(SUITE-HdfsCollec

[jira] [Commented] (LUCENE-6578) Geo3d: arcDistanceToShape() method may be useful

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-6578:
--

Sounds cool, Karl.  It's kinda crunch time for me right now to get some work 
done but I'll get to this eventually but not soon.

> Geo3d: arcDistanceToShape() method may be useful
> 
>
> Key: LUCENE-6578
> URL: https://issues.apache.org/jira/browse/LUCENE-6578
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/spatial
>Reporter: Karl Wright
> Attachments: LUCENE-6578.patch
>
>
> I've got an application that seems like it may need the ability to compute a 
> new kind of arc distance, from a GeoPoint to the nearest edge/point of a 
> GeoShape.  Adding this method to the interface, and corresponding 
> implementations, would increase the utility of the package for ranking 
> purposes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6736) A collections-like request handler to manage solr configurations on zookeeper

[Varun Rajput (JIRA)]

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

Varun Rajput commented on SOLR-6736:


Hey Guys,
I've been trying to work through the issue I am facing and am kind of stuck. 
When I stream a text or xml file, I am able to get the file and read it's 
contents from the request's content stream but the same is not working out for 
zip files. Am I doing it wrong if I am doing it like this:
{code}
for (ContentStream contentStream : req.getContentStreams()) {
InputStream inputStream = contentStream.getStream();
ZipInputStream zis = new ZipInputStream(inputStream, StandardCharsets.UTF_8);
...
break;
}
{code}
Is there an issue or a different way to deal with Archived file formats?

> A collections-like request handler to manage solr configurations on zookeeper
> -
>
> Key: SOLR-6736
> URL: https://issues.apache.org/jira/browse/SOLR-6736
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Varun Rajput
>Assignee: Anshum Gupta
>Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6736.patch, SOLR-6736.patch, SOLR-6736.patch, 
> SOLR-6736.patch, SOLR-6736.patch, zkconfighandler.zip
>
>
> Managing Solr configuration files on zookeeper becomes cumbersome while using 
> solr in cloud mode, especially while trying out changes in the 
> configurations. 
> It will be great if there is a request handler that can provide an API to 
> manage the configurations similar to the collections handler that would allow 
> actions like uploading new configurations, linking them to a collection, 
> deleting configurations, etc.
> example : 
> {code}
> #use the following command to upload a new configset called mynewconf. This 
> will fail if there is alredy a conf called 'mynewconf'. The file could be a 
> jar , zip or a tar file which contains all the files for the this conf.
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary 
> @testconf.zip 
> http://localhost:8983/solr/admin/configs/mynewconf?sig=
> {code}
> A GET to http://localhost:8983/solr/admin/configs will give a list of configs 
> available
> A GET to http://localhost:8983/solr/admin/configs/mynewconf would give the 
> list of files in mynewconf



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7694) Allow setting an overall client request timeout that includes retries

[Timothy Potter (JIRA)]

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

Timothy Potter resolved SOLR-7694.
--
Resolution: Duplicate

> Allow setting an overall client request timeout that includes retries
> -
>
> Key: SOLR-7694
> URL: https://issues.apache.org/jira/browse/SOLR-7694
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jessica Cheng Mallet
>Assignee: Timothy Potter
>  Labels: solrj
>
> Current we're able to set a socket timeout on the underlying httpClient of an 
> LBHttpSolrServer (used by CloudSolrServer). However, this timeout only 
> applies to a single request that's issued from LBHttpSolrServer, but 
> LBHttpSolrServer will go on to try all eligible candidate servers when a 
> SocketTimeoutException is thrown, so that potentially the request can in fact 
> take (socketTimeout * number of eligible servers) time to return from the 
> caller's perspective. This is hard to predict.
> We should allow setting an overall client request timeout apart from the 
> single request socketTimeout, so that the request call is guaranteed 
> terminate by this timeout (either via success or via a timeout exception). 
> This allows the client application to properly size their timeout and request 
> thread pools to avoid request thread exhaustion if solr is experiencing 
> issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Initial work on multi word synonyms and phrase queries

[Michael McCandless]

Ahh, thanks for bringing closure.

Others do successfully run tests from Intellij, I think, so I'm not
sure why you see intermittent issues...


Mike McCandless

http://blog.mikemccandless.com


On Fri, Jun 19, 2015 at 5:10 PM, Ian  wrote:
> The problem with the tests were actually because of the IDE (Intellij).
> Running the tests with ant directly works just fine. Just thought I would
> have this registered for the record.
>
> 
> From: ianri...@hotmail.com
> To: dev@lucene.apache.org
> Subject: RE: Initial work on multi word synonyms and phrase queries
> Date: Thu, 18 Jun 2015 11:53:23 +
>
>
> Issue opened: https://issues.apache.org/jira/browse/LUCENE-6582.
>
> @rcmuir, that change on the test is actually a leftover from one of my
> previous solutions while exploring the problem. It is no longer necessary
> and I removed it from the patch added to the issue above.
>
> To explain a little, in an earlier solution, the current inputs were always
> the first tokens on the output, even if there were longer synonyms (in
> number of terms). That created an inconsistency between position increments
> and position lengths, as I wasn't sure I could have a position increment
> grater than 1. So I changed it to have the first tokens, the ones that
> actually increment the positions, come from the longer synonym. In this way,
> the token stream has the same behavior as before: whenever the position
> increment is 1, the position length is also 1. But that means that, when
> keepOriginal = true and there are synonyms with more terms than the input,
> the original input (tokens with type="word") will come, on the output
> stream,  "stacked" on top of synonym tokens. This seemed to me less likely
> to impact elsewhere.
>
> Glad to hear you also deem that code complicated. I was assuming it was hard
> to me because I'm a beginner on the code base ;-)
>
> About the failing tests, in my setup, they are flaky. Sometimes passing
> sometimes failing, and not always the same. But always complaining of
> missing postings formats (last time it was 'FST50'). I'll look around a
> little more to see if I can figure out what's wrong.
>
> Ian
>
>> From: luc...@mikemccandless.com
>> Date: Thu, 18 Jun 2015 06:02:09 -0400
>> Subject: Re: Initial work on multi word synonyms and phrase queries
>> To: dev@lucene.apache.org; ianri...@hotmail.com
>>
>> +1 to opening an issue, thanks for exploring this! It's hairy :)
>>
>> Your windows test failures complaining about FSTOrd50 missing is
>> curious ... I don't run Windows but maybe someone who does has an
>> idea? That postings format comes from lucene/codecs which should be
>> on the class path during tests...
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> On Wed, Jun 17, 2015 at 10:21 PM, Robert Muir  wrote:
>> > Hey, thanks for tackling this! That synonymfilter is a beast...
>> >
>> > Can you open a JIRA issue with your patch?
>> >
>> > To me the interesting part is this change in the test:
>> >
>> > if (posInc > 0) {
>> > // This token increments position, so it is starting a new position.
>> > // Its position is the last position plus the posLength of the
>> > // last token that started a position.
>> > pos += lastPosLength;
>> > lastPosLength = posLength;
>> > }
>> >
>> > This currently implies some change to how posInc/posLen are treated on
>> > the consumer side: it would need changes to queryparsers and
>> > indexwriter to work (which is fine, we could figure out those
>> > semantics). But its my understanding this logic might be based on some
>> > properties specific to synonymfilter being greedy, and not really
>> > general to all streams. So maybe it synonymfilter or some other filter
>> > needs to do this adjustment internally instead.
>> >
>> > Anyway, I think we should make an issue and investigate it.
>> >
>> > On Wed, Jun 17, 2015 at 9:56 PM, Ian  wrote:
>> >> Hello,
>> >>
>> >> Some time ago, I had a problem with synonyms and phrase type queries
>> >> (actually, it was elasticsearch and I was using a match query with
>> >> multiple
>> >> terms and the "and" operator, as better explained here:
>> >> https://github.com/elastic/elasticsearch/issues/10394).
>> >>
>> >> That issue led to some work on Lucene:
>> >> https://issues.apache.org/jira/browse/LUCENE-6400 (where I helped a
>> >> little
>> >> with tests) and https://issues.apache.org/jira/browse/LUCENE-6401. This
>> >> issue is also related to
>> >> https://issues.apache.org/jira/browse/LUCENE-3843.
>> >>
>> >> Starting from the discussion on LUCENE-6400, I'm attempting to
>> >> implement a
>> >> solution. Here is a patch with a first step - the implementation to fix
>> >> "SynFilter to be able to 'make positions'" (as was mentioned on the
>> >> issue).
>> >> In this way, the synonym filter generates a correct (or, at least,
>> >> better)
>> >> graph.
>> >>
>> >> As the synonym matching is greedy, I only had to worry about fixing the
>> >> position length of the rules of

[jira] [Updated] (SOLR-7182) Make the Schema-API a first class citizen of SolrJ

[Marius Grama (JIRA)]

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

Marius Grama updated SOLR-7182:
---
Attachment: SOLR-7182.patch

Created a new version of the patch containing modifications added due to the 
newest developments done as part of the resolved Schema API issues (see related 
issue links).

> Make the Schema-API a first class citizen of SolrJ
> --
>
> Key: SOLR-7182
> URL: https://issues.apache.org/jira/browse/SOLR-7182
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.0
> Environment: any
>Reporter: Sven Windisch
>Priority: Minor
>  Labels: api, schema, solrj
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7182.patch, SOLR-7182.patch, SOLR-7182.patch, 
> SOLR-7182.patch, SOLR-7182.patch
>
>
> There are several Solr APIs that are handled as first class citizens in 
> SolrJ, esp. the Node API and the Collections API, i.e. they have their own 
> xxxAdminRequest Object extended from the SolrRequest Class. As someone who 
> programmatically changes Schemas a lot, I had hoped to see the Schema API 
> handled first class in release 5.0, too. As far as I dug into the code and 
> docs of SolrJ 5.0, that did not happen. If there is a reasonable point why 
> this won't happen at all, I would really like to hear it. If the only reason 
> is, that nobody had time for this, I would happily help out here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

RE: Initial work on multi word synonyms and phrase queries

[Ian]

The problem with the tests were actually because of the IDE (Intellij). Running 
the tests with ant directly works just fine. Just thought I would have this 
registered for the record.

From: ianri...@hotmail.com
To: dev@lucene.apache.org
Subject: RE: Initial work on multi word synonyms and phrase queries
Date: Thu, 18 Jun 2015 11:53:23 +




Issue opened: https://issues.apache.org/jira/browse/LUCENE-6582.
@rcmuir, that change on the test is actually a leftover from one of my previous 
solutions while exploring the problem. It is no longer necessary and I removed 
it from the patch added to the issue above.
To explain a little, in an earlier solution, the current inputs were always the 
first tokens on the output, even if there were longer synonyms (in number of 
terms). That created an inconsistency between position increments and position 
lengths, as I wasn't sure I could have a position increment grater than 1. So I 
changed it to have the first tokens, the ones that actually increment the 
positions, come from the longer synonym. In this way, the token stream has the 
same behavior as before: whenever the position increment is 1, the position 
length is also 1. But that means that, when keepOriginal = true and there are 
synonyms with more terms than the input, the original input (tokens with 
type="word") will come, on the output stream,  "stacked" on top of synonym 
tokens. This seemed to me less likely to impact elsewhere.
Glad to hear you also deem that code complicated. I was assuming it was hard to 
me because I'm a beginner on the code base ;-)
About the failing tests, in my setup, they are flaky. Sometimes passing 
sometimes failing, and not always the same. But always complaining of missing 
postings formats (last time it was 'FST50'). I'll look around a little more to 
see if I can figure out what's wrong.
Ian
> From: luc...@mikemccandless.com
> Date: Thu, 18 Jun 2015 06:02:09 -0400
> Subject: Re: Initial work on multi word synonyms and phrase queries
> To: dev@lucene.apache.org; ianri...@hotmail.com
> 
> +1 to opening an issue, thanks for exploring this!  It's hairy :)
> 
> Your windows test failures complaining about FSTOrd50 missing is
> curious ... I don't run Windows but maybe someone who does has an
> idea?  That postings format comes from lucene/codecs which should be
> on the class path during tests...
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com
> 
> On Wed, Jun 17, 2015 at 10:21 PM, Robert Muir  wrote:
> > Hey, thanks for tackling this! That synonymfilter is a beast...
> >
> > Can you open a JIRA issue with your patch?
> >
> > To me the interesting part is this change in the test:
> >
> >   if (posInc > 0) {
> > // This token increments position, so it is starting a new 
> > position.
> > // Its position is the last position plus the posLength of the
> > // last token that started a position.
> > pos += lastPosLength;
> > lastPosLength = posLength;
> >   }
> >
> > This currently implies some change to how posInc/posLen are treated on
> > the consumer side: it would need changes to queryparsers and
> > indexwriter to work (which is fine, we could figure out those
> > semantics). But its my understanding this logic might be based on some
> > properties specific to synonymfilter being greedy, and not really
> > general to all streams. So maybe it synonymfilter or some other filter
> > needs to do this adjustment internally instead.
> >
> > Anyway, I think we should make an issue and investigate it.
> >
> > On Wed, Jun 17, 2015 at 9:56 PM, Ian  wrote:
> >> Hello,
> >>
> >> Some time ago, I had a problem with synonyms and phrase type queries
> >> (actually, it was elasticsearch and I was using a match query with multiple
> >> terms and the "and" operator, as better explained here:
> >> https://github.com/elastic/elasticsearch/issues/10394).
> >>
> >> That issue led to some work on Lucene:
> >> https://issues.apache.org/jira/browse/LUCENE-6400 (where I helped a little
> >> with tests) and  https://issues.apache.org/jira/browse/LUCENE-6401. This
> >> issue is also related to https://issues.apache.org/jira/browse/LUCENE-3843.
> >>
> >> Starting from the discussion on LUCENE-6400, I'm attempting to implement a
> >> solution. Here is a patch with a first step - the implementation to fix
> >> "SynFilter to be able to 'make positions'" (as was mentioned on the issue).
> >> In this way, the synonym filter generates a correct (or, at least, better)
> >> graph.
> >>
> >> As the synonym matching is greedy, I only had to worry about fixing the
> >> position length of the rules of the current match, no future or past
> >> synonyms would "span" over this match (please correct me if I'm wrong!). It
> >> did require more buffering, twice as much.
> >>
> >> The new behavior I added is not active by default, a new parameter has to 
> >> be
> >> passed in a new constructor for SynonymFilter. The changes I made do c

[jira] [Updated] (LUCENE-6582) SynonymFilter should generate a correct (or, at least, better) graph

[Ian Ribas (JIRA)]

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

Ian Ribas updated LUCENE-6582:
--
Attachment: LUCENE-6582.patch

New patch with minor fixes: changed -10 to -1 (it was a leftover that I had 
overlooked, sorry for that).Changed the comment on the TODO, making it clearer 
what the problem is: output is still a sausage for multiple multi term synonyms.

Unfortunately, I could not merge the tests into a single file because they have 
different base classes and the new tests depend on asserts on the base class.


> SynonymFilter should generate a correct (or, at least, better) graph
> 
>
> Key: LUCENE-6582
> URL: https://issues.apache.org/jira/browse/LUCENE-6582
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ian Ribas
> Attachments: LUCENE-6582.patch, LUCENE-6582.patch, after.png, 
> after2.png, before.png
>
>
> Some time ago, I had a problem with synonyms and phrase type queries 
> (actually, it was elasticsearch and I was using a match query with multiple 
> terms and the "and" operator, as better explained here: 
> https://github.com/elastic/elasticsearch/issues/10394).
> That issue led to some work on Lucene: LUCENE-6400 (where I helped a little 
> with tests) and  LUCENE-6401. This issue is also related to LUCENE-3843.
> Starting from the discussion on LUCENE-6400, I'm attempting to implement a 
> solution. Here is a patch with a first step - the implementation to fix 
> "SynFilter to be able to 'make positions'" (as was mentioned on the 
> [issue|https://issues.apache.org/jira/browse/LUCENE-6400?focusedCommentId=14498554&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14498554]).
>  In this way, the synonym filter generates a correct (or, at least, better) 
> graph.
> As the synonym matching is greedy, I only had to worry about fixing the 
> position length of the rules of the current match, no future or past synonyms 
> would "span" over this match (please correct me if I'm wrong!). It did 
> require more buffering, twice as much.
> The new behavior I added is not active by default, a new parameter has to be 
> passed in a new constructor for {{SynonymFilter}}. The changes I made do 
> change the token stream generated by the synonym filter, and I thought it 
> would be better to let that be a voluntary decision for now.
> I did some refactoring on the code, but mostly on what I had to change for 
> may implementation, so that the patch was not too hard to read. I created 
> specific unit tests for the new implementation 
> ({{TestMultiWordSynonymFilter}}) that should show how things will be with the 
> new behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3245 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3245/

2 tests failed.
REGRESSION:  org.apache.solr.cloud.OverseerStatusTest.test

Error Message:
No stats for split in OverseerCollectionProcessor expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: No stats for split in OverseerCollectionProcessor 
expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([A3EA03A497CA2A9A:2BBE3C7E39364762]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at 
org.apache.solr.cloud.OverseerStatusTest.test(OverseerStatusTest.java:91)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.jav

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b60) - Build # 13126 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13126/
Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([8A371F76616D5340]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9699 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.HttpPartitionTest_8A371F76616D5340-001/init-core-data-001
   [junit4]   2> 43393 INFO  
(SUITE-HttpPartitionTest-seed#[8A371F76616D5340]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: 
/s_xvn/d
   [junit4]   2> 43395 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 43395 INFO  (Thread-131) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 43395 INFO  (Thread-131) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 43495 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.ZkTestServer start zk server on port:45720
   [junit4]   2> 43495 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 43496 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 43502 INFO  (zkCallback-39-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@3d7f4bba 
name:ZooKeeperConnection Watcher:127.0.0.1:45720 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 43502 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 43503 INFO  
(TEST-HttpPartitionTest.test-seed#[8A371F76616D5340]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 43503 INFO  
(TEST-HttpPartitionTest.test-see

[jira] [Commented] (SOLR-7573) Inconsistent numbers of docs between leader and replica

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-7573:
--

On the theory that the replica being much busier than it needed to be was 
leading to "bad stuff happening", I'm linking in SOLR-7333. Combined with 
SOLR-7344 this may affect all three of these JIRAs.

> Inconsistent numbers of docs between leader and replica
> ---
>
> Key: SOLR-7573
> URL: https://issues.apache.org/jira/browse/SOLR-7573
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.10.3
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> Once again assigning to myself to keep track. And once again not reproducible 
> at will and possible related to firehosing updates to Solr.
> Saw a situation where things seemed to be indexed normally, but the number of 
> docs on a leader and follower were not the same. The leader had, as I 
> remember, a 4.5G index and the follower a 1.9G index. No errors in the logs, 
> no recovery initiated, etc. All nodes green.
> The very curious thing was that when the follower was bounced, it did a full 
> index replication from the leader. How that could be happening without the 
> follower ever going into a recovery state I have no idea.
> Again, if I can get this to reproduce locally I can put more diagnostics into 
> the process and see what I can see. I also have some logs to further explore.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7679) Schema API doesn't take similarity attribute into account when adding field types

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-7679.
--
Resolution: Fixed
  Assignee: Steve Rowe

Committed to trunk and branch_5x.

Thanks Marius!

> Schema API doesn't take similarity attribute into account when adding field 
> types
> -
>
> Key: SOLR-7679
> URL: https://issues.apache.org/jira/browse/SOLR-7679
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.2
>Reporter: Marius Grama
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7679.patch, SOLR-7679.patch, SOLR-7679.patch
>
>
> When using the request
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
>   "add-field-type": {
> "name": "fieldTypeWithSimilarity",
> "class": "org.apache.solr.schema.TextField",
> "analyzer": {
>   "charFilters": [
> {
>   "class": "solr.PatternReplaceCharFilterFactory",
>   "replacement": "$1$1",
>   "pattern": "([a-zA-Z])1+"
> }
>   ],
>   "tokenizer": {
> "class": "solr.WhitespaceTokenizerFactory"
>   }
> },
> "similarity": {
>   "class": "org.apache.lucene.misc.SweetSpotSimilarity"
> }
>   }
> }' http://localhost:8983/solr/gettingstarted/schema
> {code}
> can be seen in the updated schema.xml that the similarity attributes for the 
> newly added field type doesn't contain a _similarity_ entry.
> This is due to the fact that within FieldTypeXmlAdapter the similiarity 
> element is not being added to the field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7679) Schema API doesn't take similarity attribute into account when adding field types

[ASF subversion and git services (JIRA)]

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

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

Commit 1686498 from [~steve_rowe] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1686498 ]

SOLR-7679: Schema API doesn't take similarity attribute into account when 
adding field types (merged trunk r1686491)

> Schema API doesn't take similarity attribute into account when adding field 
> types
> -
>
> Key: SOLR-7679
> URL: https://issues.apache.org/jira/browse/SOLR-7679
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.2
>Reporter: Marius Grama
>Priority: Minor
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7679.patch, SOLR-7679.patch, SOLR-7679.patch
>
>
> When using the request
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
>   "add-field-type": {
> "name": "fieldTypeWithSimilarity",
> "class": "org.apache.solr.schema.TextField",
> "analyzer": {
>   "charFilters": [
> {
>   "class": "solr.PatternReplaceCharFilterFactory",
>   "replacement": "$1$1",
>   "pattern": "([a-zA-Z])1+"
> }
>   ],
>   "tokenizer": {
> "class": "solr.WhitespaceTokenizerFactory"
>   }
> },
> "similarity": {
>   "class": "org.apache.lucene.misc.SweetSpotSimilarity"
> }
>   }
> }' http://localhost:8983/solr/gettingstarted/schema
> {code}
> can be seen in the updated schema.xml that the similarity attributes for the 
> newly added field type doesn't contain a _similarity_ entry.
> This is due to the fact that within FieldTypeXmlAdapter the similiarity 
> element is not being added to the field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7707) Add StreamExpression Support to RollupStream

[Dennis Gove (JIRA)]

Dennis Gove created SOLR-7707:
-

 Summary: Add StreamExpression Support to RollupStream
 Key: SOLR-7707
 URL: https://issues.apache.org/jira/browse/SOLR-7707
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Reporter: Dennis Gove
Priority: Minor


This ticket is to add Stream Expression support to the RollupStream as 
discussed in SOLR-7560.

Proposed expression syntax for the RollupStream (copied from that ticket)

{code}
rollup(
  someStream(),
  over="fieldA, fieldB, fieldC",
  min(fieldA),
  max(fieldA),
  min(fieldB),
  mean(fieldD),
  sum(fieldC)
)
{code}

This requires making the *Metric types Expressible but I think that ends up as 
a good thing. Would make it real easy to support other options on metrics like 
excluding outliers, for example find the sum of values within 3 standard 
deviations from the mean could be 
{code}
sum(fieldC, limit=standardDev(3))
{code}
 (note, how that particular calculation could be implemented is left as an 
exercise for the reader, I'm just using it as an example of adding additional 
options on a relatively simple metric).
Another option example is what to do with null values. For example, in some 
cases a null should not impact a mean but in others it should. You could 
express those as
{code}
mean(fieldA, replace(null, 0))  // replace null values with 0 thus leading to 
an impact on the mean
mean(fieldA, includeNull="true") // nulls are counted in the denominator but 
nothing added to numerator
mean(fieldA, includeNull="false") // nulls neither counted in denominator nor 
added to numerator
mean(fieldA, replace(null, fieldB), includeNull="true") // if fieldA is null 
replace it with fieldB, include null fieldB in mean
{code}
so on and so forth.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[ASF subversion and git services (JIRA)]

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

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

Commit 1686495 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1686495 ]

LUCENE-6591: never write a negative vlong

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6591) Never write negative vLongs

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-6591.

Resolution: Fixed

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60-ea-b12) - Build # 12948 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12948/
Java: 32bit/jdk1.8.0_60-ea-b12 -client -XX:+UseParallelGC

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

Error Message:
Didn't see all replicas for shard shard1 in c8n_1x2 come up within 3 ms! 
ClusterState: {   "collection1":{ "replicationFactor":"1", "shards":{   
"shard1":{ "range":"8000-", "state":"active",   
  "replicas":{"core_node2":{ "core":"collection1", 
"base_url":"http://127.0.0.1:51884";, 
"node_name":"127.0.0.1:51884_", "state":"active", 
"leader":"true"}}},   "shard2":{ "range":"0-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"collection1", "base_url":"http://127.0.0.1:48104";,  
   "node_name":"127.0.0.1:48104_", "state":"active", 
"leader":"true"},   "core_node3":{ "core":"collection1",
 "base_url":"http://127.0.0.1:43747";, 
"node_name":"127.0.0.1:43747_", "state":"active", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false", "autoCreated":"true"},   "control_collection":{  
   "replicationFactor":"1", "shards":{"shard1":{ 
"range":"8000-7fff", "state":"active", 
"replicas":{"core_node1":{ "core":"collection1", 
"base_url":"http://127.0.0.1:39405";, 
"node_name":"127.0.0.1:39405_", "state":"active", 
"leader":"true", "router":{"name":"compositeId"}, 
"maxShardsPerNode":"1", "autoAddReplicas":"false", 
"autoCreated":"true"},   "c8n_1x2":{ "replicationFactor":"2", 
"shards":{"shard1":{ "range":"8000-7fff", 
"state":"active", "replicas":{   "core_node1":{ 
"core":"c8n_1x2_shard1_replica2", 
"base_url":"http://127.0.0.1:51884";, 
"node_name":"127.0.0.1:51884_", "state":"active", 
"leader":"true"},   "core_node2":{ 
"core":"c8n_1x2_shard1_replica1", 
"base_url":"http://127.0.0.1:39405";, 
"node_name":"127.0.0.1:39405_", "state":"recovering", 
"router":{"name":"compositeId"}, "maxShardsPerNode":"1", 
"autoAddReplicas":"false"}}

Stack Trace:
java.lang.AssertionError: Didn't see all replicas for shard shard1 in c8n_1x2 
come up within 3 ms! ClusterState: {
  "collection1":{
"replicationFactor":"1",
"shards":{
  "shard1":{
"range":"8000-",
"state":"active",
"replicas":{"core_node2":{
"core":"collection1",
"base_url":"http://127.0.0.1:51884";,
"node_name":"127.0.0.1:51884_",
"state":"active",
"leader":"true"}}},
  "shard2":{
"range":"0-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:48104";,
"node_name":"127.0.0.1:48104_",
"state":"active",
"leader":"true"},
  "core_node3":{
"core":"collection1",
"base_url":"http://127.0.0.1:43747";,
"node_name":"127.0.0.1:43747_",
"state":"active",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "control_collection":{
"replicationFactor":"1",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{"core_node1":{
"core":"collection1",
"base_url":"http://127.0.0.1:39405";,
"node_name":"127.0.0.1:39405_",
"state":"active",
"leader":"true",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false",
"autoCreated":"true"},
  "c8n_1x2":{
"replicationFactor":"2",
"shards":{"shard1":{
"range":"8000-7fff",
"state":"active",
"replicas":{
  "core_node1":{
"core":"c8n_1x2_shard1_replica2",
"base_url":"http://127.0.0.1:51884";,
"node_name":"127.0.0.1:51884_",
"state":"active",
"leader":"true"},
  "core_node2":{
"core":"c8n_1x2_shard1_replica1",
"base_url":"http://127.0.0.1:39405";,
"node_name":"127.0.0.1:39405_",
"state":"recovering",
"router":{"name":"compositeId"},
"maxShardsPerNode":"1",
"autoAddReplicas":"false"}}
at 
__randomizedtesting.SeedInfo.seed([754102A3D0D97144:FD153D797E251CBC]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.ensureAllReplicasAreActiv

[jira] [Commented] (SOLR-7679) Schema API doesn't take similarity attribute into account when adding field types

[ASF subversion and git services (JIRA)]

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

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

Commit 1686491 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1686491 ]

SOLR-7679: Schema API doesn't take similarity attribute into account when 
adding field types

> Schema API doesn't take similarity attribute into account when adding field 
> types
> -
>
> Key: SOLR-7679
> URL: https://issues.apache.org/jira/browse/SOLR-7679
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.2
>Reporter: Marius Grama
>Priority: Minor
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7679.patch, SOLR-7679.patch, SOLR-7679.patch
>
>
> When using the request
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
>   "add-field-type": {
> "name": "fieldTypeWithSimilarity",
> "class": "org.apache.solr.schema.TextField",
> "analyzer": {
>   "charFilters": [
> {
>   "class": "solr.PatternReplaceCharFilterFactory",
>   "replacement": "$1$1",
>   "pattern": "([a-zA-Z])1+"
> }
>   ],
>   "tokenizer": {
> "class": "solr.WhitespaceTokenizerFactory"
>   }
> },
> "similarity": {
>   "class": "org.apache.lucene.misc.SweetSpotSimilarity"
> }
>   }
> }' http://localhost:8983/solr/gettingstarted/schema
> {code}
> can be seen in the updated schema.xml that the similarity attributes for the 
> newly added field type doesn't contain a _similarity_ entry.
> This is due to the fact that within FieldTypeXmlAdapter the similiarity 
> element is not being added to the field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[ASF subversion and git services (JIRA)]

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

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

Commit 1686487 from [~mikemccand] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1686487 ]

LUCENE-6591: never write a negative vlong

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7706) BJQParserTest failures: Expect to be advanced on child docs only

[Adrien Grand (JIRA)]

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

Adrien Grand resolved SOLR-7706.

Resolution: Fixed

It should be fixed now.

> BJQParserTest failures: Expect to be advanced on child docs only
> 
>
> Key: SOLR-7706
> URL: https://issues.apache.org/jira/browse/SOLR-7706
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Between June18 and June19 there have been 5 jenkins failures on trunk with 
> the following stack (only the docIds have changed)...
> {noformat}
>[junit4] ERROR   0.19s | BJQParserTest.testChildrenParser <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
>[junit4]>  at 
> org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.IllegalStateException: Expect to be 
> advanced on child docs only. got docID=13
>[junit4]>  at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:101)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:130)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionScorer.nextDoc(ConjunctionScorer.java:62)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:620)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:204)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1696)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1512)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:563)
>[junit4]>  at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:519)
>[junit4]>  at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>[junit4]>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>[junit4]>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2057)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:320)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:302)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:744)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (LUCENE-6593) ToChildBlockJoinScorer should not fail when advanced on a parent document

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6593.
--
Resolution: Fixed

> ToChildBlockJoinScorer should not fail when advanced on a parent document
> -
>
> Key: LUCENE-6593
> URL: https://issues.apache.org/jira/browse/LUCENE-6593
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6593.patch
>
>
> ToChildBlockJoinScorer fails if you advance it on a parent document. While 
> this was fine if you wrapped it in a FilteredQuery, it is not if you wrap it 
> in a BooleanQuery because of its approximation support: it can be advanced to 
> a document that has been returned by the approximation of another clause but 
> not confirmed yet. So ToChildBlockJoinScorer should accept any valid doc ID 
> as a target.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6593) ToChildBlockJoinScorer should not fail when advanced on a parent document

[ASF subversion and git services (JIRA)]

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

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

Commit 1686486 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1686486 ]

LUCENE-6593: Fix ToChildBlockJoinQuery's scorer to not refuse to advance to a 
document that belongs to the parent space.

> ToChildBlockJoinScorer should not fail when advanced on a parent document
> -
>
> Key: LUCENE-6593
> URL: https://issues.apache.org/jira/browse/LUCENE-6593
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6593.patch
>
>
> ToChildBlockJoinScorer fails if you advance it on a parent document. While 
> this was fine if you wrapped it in a FilteredQuery, it is not if you wrap it 
> in a BooleanQuery because of its approximation support: it can be advanced to 
> a document that has been returned by the approximation of another clause but 
> not confirmed yet. So ToChildBlockJoinScorer should accept any valid doc ID 
> as a target.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6593) ToChildBlockJoinScorer should not fail when advanced on a parent document

[ASF subversion and git services (JIRA)]

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

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

Commit 1686485 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1686485 ]

LUCENE-6593: Fix ToChildBlockJoinQuery's scorer to not refuse to advance to a 
document that belongs to the parent space.

> ToChildBlockJoinScorer should not fail when advanced on a parent document
> -
>
> Key: LUCENE-6593
> URL: https://issues.apache.org/jira/browse/LUCENE-6593
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6593.patch
>
>
> ToChildBlockJoinScorer fails if you advance it on a parent document. While 
> this was fine if you wrapped it in a FilteredQuery, it is not if you wrap it 
> in a BooleanQuery because of its approximation support: it can be advanced to 
> a document that has been returned by the approximation of another clause but 
> not confirmed yet. So ToChildBlockJoinScorer should accept any valid doc ID 
> as a target.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7513:
--

Thanks for the great work!

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-7513 at 6/19/15 7:09 PM:
---

Dennis, Thanks for the great work!


was (Author: joel.bernstein):
Thanks for the great work!

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[Dennis Gove (JIRA)]

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

Dennis Gove commented on SOLR-7513:
---

I appreciate the help with this, Joel. Thanks!

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7528) Simplify Interfaces used in Streaming Expressions

[ASF subversion and git services (JIRA)]

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

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

Commit 1686481 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1686481 ]

SOLR-7513, SOLR-7528: Add Equalitors to Streaming Expressions

> Simplify Interfaces used in Streaming Expressions
> -
>
> Key: SOLR-7528
> URL: https://issues.apache.org/jira/browse/SOLR-7528
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Affects Versions: 5.2, Trunk
>Reporter: Dennis Gove
>Priority: Minor
>  Labels: streaming
> Fix For: 5.2, Trunk
>
> Attachments: SOLR-7528.patch
>
>
> FieldComparator and StreamComparator have been collapsed into a single class 
> StreamComparator. There was no need for a separate abstract class.
> Added null checks in StreamComparator. For now if both are null then they 
> will evaluate to equal. We can add a later enhancement under a new ticket to 
> make that configurable.
> Interfaces ExpressibleStream and ExpressibleComparator have been collapsed 
> into interface Expressible. They defined the same interface and there's no 
> reason to have separate interfaces for them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[ASF subversion and git services (JIRA)]

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

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

Commit 1686481 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1686481 ]

SOLR-7513, SOLR-7528: Add Equalitors to Streaming Expressions

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7242) Schema API: Edit remaining schema elements: Name, Version, Unique Key, and Global Similarity

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-7242:
--

When global similarity can be set via the Schema API, the Solr Reference Guide 
should updated to warn people that before adding field types with 
per-field-type similarity, they must first change the global similarity to 
{{SchemaSimilarityFactory}} (or another similarity factory that enables 
per-field-type similarity).  More details at 
[SOLR-7679|https://issues.apache.org/jira/browse/SOLR-7679?focusedCommentId=14593764&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14593764].

> Schema API: Edit remaining schema elements: Name, Version, Unique Key, and 
> Global Similarity
> 
>
> Key: SOLR-7242
> URL: https://issues.apache.org/jira/browse/SOLR-7242
> Project: Solr
>  Issue Type: Sub-task
>  Components: Schema and Analysis
>Reporter: Steve Rowe
>Assignee: Steve Rowe
>
> We should be able to specify an entire schema via the bulk schema API.
> The bulk schema API should have the following commands in addition to those 
> already available/planned:
> # {{set-name}}
> # {{set-version}}
> # {{set-unique-key}}
> # {{set-similarity}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6591:


I like writeSignedVLong ... I'll rename to that and commit!

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7706) BJQParserTest failures: Expect to be advanced on child docs only

[Adrien Grand (JIRA)]

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

Adrien Grand commented on SOLR-7706:


LUCENE-6583 caused this issue by exposing an incompatibility between 
ToChildBlockJoinScorer and BooleanQuery (which is the replacement for 
FilteredQuery), I opened LUCENE-6593.

> BJQParserTest failures: Expect to be advanced on child docs only
> 
>
> Key: SOLR-7706
> URL: https://issues.apache.org/jira/browse/SOLR-7706
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Between June18 and June19 there have been 5 jenkins failures on trunk with 
> the following stack (only the docIds have changed)...
> {noformat}
>[junit4] ERROR   0.19s | BJQParserTest.testChildrenParser <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
>[junit4]>  at 
> org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.IllegalStateException: Expect to be 
> advanced on child docs only. got docID=13
>[junit4]>  at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:101)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:130)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionScorer.nextDoc(ConjunctionScorer.java:62)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:620)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:204)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1696)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1512)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:563)
>[junit4]>  at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:519)
>[junit4]>  at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>[junit4]>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>[junit4]>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2057)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:320)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:302)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:744)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6593) ToChildBlockJoinScorer should not fail when advanced on a parent document

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6593:
-
Attachment: LUCENE-6593.patch

Here is a patch.

> ToChildBlockJoinScorer should not fail when advanced on a parent document
> -
>
> Key: LUCENE-6593
> URL: https://issues.apache.org/jira/browse/LUCENE-6593
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6593.patch
>
>
> ToChildBlockJoinScorer fails if you advance it on a parent document. While 
> this was fine if you wrapped it in a FilteredQuery, it is not if you wrap it 
> in a BooleanQuery because of its approximation support: it can be advanced to 
> a document that has been returned by the approximation of another clause but 
> not confirmed yet. So ToChildBlockJoinScorer should accept any valid doc ID 
> as a target.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7679) Schema API doesn't take similarity attribute into account when adding field types

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-7679:
-
Attachment: SOLR-7679.patch

Thanks Marius.

I'm attaching a modified patch:

You switched {{TestBulkSchemaAPI}} to using the to-be-deprecated (SOLR-6594) 
non-bulk API, via extra servlet setup in {{before()}}, AFAICT so that you could 
get the {{showDefaults}} behavior, which is not available with the bulk Schema 
API.  But this is a bug in {{FieldType.getNamedPropertyValues()}}: it only 
outputs similarity when {{showDefaults=true}}, but it should instead always do 
so.  My version of the patch fixes this bug.  (This is a round-tripping 
problem: manual testing shows that when managed schema is persisted, 
per-field-type similarity is currently dropped, which is bad.)

I was then able to revert {{TestBulkSchemaAPI}} to the previously used bulk 
schema API, since {{showDefaults}} is no longer necessary to get the 
per-field-type similarity to show up in the schema api response.

I think this is ready.  I'll commit after running Solr tests and precommit.

In my testing I noticed that {{SchemaSimilarityFactory}}, a prerequisite for 
setting per-field-type similarity, is not the default in any of Solr's example 
schemas.  See [http://markmail.org/message/7icpmwmdhfw4tmwv] and SOLR-3577 for 
rationale.

We need to let people know that in order to set per-field-type similarity, they 
need to first set the global similarity to {{SchemaSimilarityFactory}} or 
something like it.  Unfortunately the Schema API can't yet set the global 
similarity - see SOLR-7242.  I'll leave a comment there about the need to 
check/update the Solr Reference Guide for this.

> Schema API doesn't take similarity attribute into account when adding field 
> types
> -
>
> Key: SOLR-7679
> URL: https://issues.apache.org/jira/browse/SOLR-7679
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.2
>Reporter: Marius Grama
>Priority: Minor
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7679.patch, SOLR-7679.patch, SOLR-7679.patch
>
>
> When using the request
> {code}
> curl -X POST -H 'Content-type:application/json' --data-binary '{
>   "add-field-type": {
> "name": "fieldTypeWithSimilarity",
> "class": "org.apache.solr.schema.TextField",
> "analyzer": {
>   "charFilters": [
> {
>   "class": "solr.PatternReplaceCharFilterFactory",
>   "replacement": "$1$1",
>   "pattern": "([a-zA-Z])1+"
> }
>   ],
>   "tokenizer": {
> "class": "solr.WhitespaceTokenizerFactory"
>   }
> },
> "similarity": {
>   "class": "org.apache.lucene.misc.SweetSpotSimilarity"
> }
>   }
> }' http://localhost:8983/solr/gettingstarted/schema
> {code}
> can be seen in the updated schema.xml that the similarity attributes for the 
> newly added field type doesn't contain a _similarity_ entry.
> This is due to the fact that within FieldTypeXmlAdapter the similiarity 
> element is not being added to the field type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6593) ToChildBlockJoinScorer should not fail when advanced on a parent document

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6593:


 Summary: ToChildBlockJoinScorer should not fail when advanced on a 
parent document
 Key: LUCENE-6593
 URL: https://issues.apache.org/jira/browse/LUCENE-6593
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 5.3


ToChildBlockJoinScorer fails if you advance it on a parent document. While this 
was fine if you wrapped it in a FilteredQuery, it is not if you wrap it in a 
BooleanQuery because of its approximation support: it can be advanced to a 
document that has been returned by the approximation of another clause but not 
confirmed yet. So ToChildBlockJoinScorer should accept any valid doc ID as a 
target.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7513:
--

This patch looks good to me and we have some pretty good tests behind it. the 
Streaming API tests, the Streaming Expressions tests and the Parallel SQL tests 
all exercise this code base. I plan to commit this to trunk shortly.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

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

New patch with all tests passing and precommit. Just needed to add the 
package-info.java file for the new eq package.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch, 
> SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Any clue why I'm being asked to moderate these messages from the build system?

[Steve Rowe]

I’ve reply-all’d to a bunch of these from the moderation queue, but they still 
seem to require moderation though.

> On Jun 19, 2015, at 1:41 PM, Erick Erickson  wrote:
> 
> Right, but I keep getting them even after approving some of them. It's
> like the from address keeps changing.
> 
> Or I'm just confused. I'll "reply-all" for a while and we'll see.
> 
> On Fri, Jun 19, 2015 at 9:55 AM, Chris Hostetter
>  wrote:
>> 
>> : Clearly they're coming from Elastic..
>> 
>> pretty sure it's just standard moderatation queue stuff...
>> 
>> the first time a (non-subscribed) addr sends an email to the list, it gets
>> held in the queue -- if the moderator just hits "reply" tothe "accept"
>> address, then that one message will make it through -- but future messages
>> will not.
>> 
>> Which is why moderators are encouraged to "reply-all" so that the "allow"
>> address is also hit -- this ensures that future messages from the same
>> sender won't get stuck in the moderation queue in the future.
>> 
>> at some point recently elastic changed the email addr used by their CI
>> system, so it needed to be re-allowed to send mail, and they started
>> popping back up in the moderation queue.
>> 
>> (As a reminder: questions like this are why we have the moderator list, so
>> we don't have to distract the entire dev community with meta-discussions
>> about dealing with moderation)
>> 
>> 
>> :
>> : From: bu...@elastic.co
>> : To: d...@elastic.co, dev@lucene.apache.org, sim...@apache.org
>> : Cc:
>> : Date: Fri, 19 Jun 2015 10:56:46 +
>> : Subject: [CI] Lucene 5x Linux 64 Test Only - Build # 51986 - Failure!
>> :  BUILD FAILURE
>> :
>> : Build 
>> URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51986/
>> : Project:lucene_linux_java8_64_test_only
>> : Randomization:JDKEA9,local,heap[1024m],-server +UseConcMarkSweepGC
>> : +UseCompressedOops +AggressiveOpts,sec manager on
>> : Date of build:Fri, 19 Jun 2015 12:54:09 +0200
>> : Build duration:2 min 35 sec
>> :
>> : CHANGES
>> : No Changes
>> :
>> : BUILD ARTIFACTS
>> : checkout/lucene/build/core/test/temp/junit4-J0-20150619_125429_116.events
>> : checkout/lucene/build/core/test/temp/junit4-J1-20150619_125429_116.events
>> : checkout/lucene/build/core/test/temp/junit4-J2-20150619_125429_112.events
>> : checkout/lucene/build/core/test/temp/junit4-J3-20150619_125429_116.events
>> : checkout/lucene/build/core/test/temp/junit4-J4-20150619_125429_112.events
>> : checkout/lucene/build/core/test/temp/junit4-J5-20150619_125429_116.events
>> : checkout/lucene/build/core/test/temp/junit4-J6-20150619_125429_118.events
>> : checkout/lucene/build/core/test/temp/junit4-J7-20150619_125429_119.events
>> :
>> : FAILED JUNIT TESTS
>> : Name: junit.framework Failed: 2 test(s), Passed: 0 test(s), Skipped: 0
>> : test(s), Total: 2 test(s)
>> : Failed: 
>> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
>> : Failed: 
>> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
>> : Name: org.apache.lucene.index Failed: 2 test(s), Passed: 774 test(s),
>> : Skipped: 23 test(s), Total: 799 test(s)
>> : Failed: 
>> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
>> : Failed: 
>> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
>> :
>> : CONSOLE OUTPUT
>> : [...truncated 1849 lines...]
>> : [junit4] - 
>> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
>> : [junit4] - 
>> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
>> : [junit4]
>> : [junit4]
>> : [junit4] JVM J0: 1.02 .. 125.17 = 124.15s
>> : [junit4] JVM J1: 1.01 .. 124.41 = 123.39s
>> : [junit4] JVM J2: 1.33 .. 124.50 = 123.17s
>> : [junit4] JVM J3: 1.11 .. 122.66 = 121.55s
>> : [junit4] JVM J4: 1.24 .. 124.04 = 122.80s
>> : [junit4] JVM J5: 1.01 .. 127.16 = 126.15s
>> : [junit4] JVM J6: 1.00 .. 133.45 = 132.45s
>> : [junit4] JVM J7: 1.03 .. 125.12 = 124.08s
>> : [junit4] Execution time total: 2 minutes 13 seconds
>> : [junit4] Tests summary: 401 suites, 3227 tests, 2 suite-level errors,
>> : 2 errors, 48 ignored (44 assumptions)
>> : BUILD FAILED
>> : 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
>> : The following error occurred while executing this line:
>> : 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
>> : The following error occurred while executing this line:
>> : 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
>> : There were test failures: 401 suites, 3227 tests, 2 suite-level
>> : errors, 2 errors, 48 ignored (44 assumptions)
>> : Total time: 2 minutes 21 seconds
>> :
>> : -
>> : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> : For additional commands, e-mail: dev-h...@lucene.apache.org
>> :
>> :
>> 
>> -Hoss
>> h

[jira] [Commented] (LUCENE-6583) Remove FilteredQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6583:
--

Thanks for the ping, I missed it. I'll dig.

> Remove FilteredQuery
> 
>
> Key: LUCENE-6583
> URL: https://issues.apache.org/jira/browse/LUCENE-6583
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 6.0
>
> Attachments: LUCENE-6583.patch
>
>
> Now that BooleanQuery can handle filters, FilteredQuery should be removed in 
> trunk and deprecated in 5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Any clue why I'm being asked to moderate these messages from the build system?

[Erick Erickson]

Right, but I keep getting them even after approving some of them. It's
like the from address keeps changing.

Or I'm just confused. I'll "reply-all" for a while and we'll see.

On Fri, Jun 19, 2015 at 9:55 AM, Chris Hostetter
 wrote:
>
> : Clearly they're coming from Elastic..
>
> pretty sure it's just standard moderatation queue stuff...
>
> the first time a (non-subscribed) addr sends an email to the list, it gets
> held in the queue -- if the moderator just hits "reply" tothe "accept"
> address, then that one message will make it through -- but future messages
> will not.
>
> Which is why moderators are encouraged to "reply-all" so that the "allow"
> address is also hit -- this ensures that future messages from the same
> sender won't get stuck in the moderation queue in the future.
>
> at some point recently elastic changed the email addr used by their CI
> system, so it needed to be re-allowed to send mail, and they started
> popping back up in the moderation queue.
>
> (As a reminder: questions like this are why we have the moderator list, so
> we don't have to distract the entire dev community with meta-discussions
> about dealing with moderation)
>
>
> :
> : From: bu...@elastic.co
> : To: d...@elastic.co, dev@lucene.apache.org, sim...@apache.org
> : Cc:
> : Date: Fri, 19 Jun 2015 10:56:46 +
> : Subject: [CI] Lucene 5x Linux 64 Test Only - Build # 51986 - Failure!
> :  BUILD FAILURE
> :
> : Build 
> URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51986/
> : Project:lucene_linux_java8_64_test_only
> : Randomization:JDKEA9,local,heap[1024m],-server +UseConcMarkSweepGC
> : +UseCompressedOops +AggressiveOpts,sec manager on
> : Date of build:Fri, 19 Jun 2015 12:54:09 +0200
> : Build duration:2 min 35 sec
> :
> : CHANGES
> : No Changes
> :
> : BUILD ARTIFACTS
> : checkout/lucene/build/core/test/temp/junit4-J0-20150619_125429_116.events
> : checkout/lucene/build/core/test/temp/junit4-J1-20150619_125429_116.events
> : checkout/lucene/build/core/test/temp/junit4-J2-20150619_125429_112.events
> : checkout/lucene/build/core/test/temp/junit4-J3-20150619_125429_116.events
> : checkout/lucene/build/core/test/temp/junit4-J4-20150619_125429_112.events
> : checkout/lucene/build/core/test/temp/junit4-J5-20150619_125429_116.events
> : checkout/lucene/build/core/test/temp/junit4-J6-20150619_125429_118.events
> : checkout/lucene/build/core/test/temp/junit4-J7-20150619_125429_119.events
> :
> : FAILED JUNIT TESTS
> : Name: junit.framework Failed: 2 test(s), Passed: 0 test(s), Skipped: 0
> : test(s), Total: 2 test(s)
> : Failed: 
> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
> : Failed: 
> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
> : Name: org.apache.lucene.index Failed: 2 test(s), Passed: 774 test(s),
> : Skipped: 23 test(s), Total: 799 test(s)
> : Failed: 
> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
> : Failed: 
> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
> :
> : CONSOLE OUTPUT
> : [...truncated 1849 lines...]
> : [junit4] - 
> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
> : [junit4] - 
> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
> : [junit4]
> : [junit4]
> : [junit4] JVM J0: 1.02 .. 125.17 = 124.15s
> : [junit4] JVM J1: 1.01 .. 124.41 = 123.39s
> : [junit4] JVM J2: 1.33 .. 124.50 = 123.17s
> : [junit4] JVM J3: 1.11 .. 122.66 = 121.55s
> : [junit4] JVM J4: 1.24 .. 124.04 = 122.80s
> : [junit4] JVM J5: 1.01 .. 127.16 = 126.15s
> : [junit4] JVM J6: 1.00 .. 133.45 = 132.45s
> : [junit4] JVM J7: 1.03 .. 125.12 = 124.08s
> : [junit4] Execution time total: 2 minutes 13 seconds
> : [junit4] Tests summary: 401 suites, 3227 tests, 2 suite-level errors,
> : 2 errors, 48 ignored (44 assumptions)
> : BUILD FAILED
> : 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
> : The following error occurred while executing this line:
> : 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
> : The following error occurred while executing this line:
> : 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
> : There were test failures: 401 suites, 3227 tests, 2 suite-level
> : errors, 2 errors, 48 ignored (44 assumptions)
> : Total time: 2 minutes 21 seconds
> :
> : -
> : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> : For additional commands, e-mail: dev-h...@lucene.apache.org
> :
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsu

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 13110 - Still Failing!

[Chris Hostetter]

Opened: https://issues.apache.org/jira/browse/SOLR-7706

...tracked to being caused by LUCENE-6583.



: Date: Fri, 19 Jun 2015 10:13:30 -0700 (MST)
: From: Chris Hostetter 
: To: dev@lucene.apache.org
: Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) -
: Build # 13110 - Still Failing!
: 
: 
: There have been 6 failures of this test (on trunk) with the same root 
: cause (but diff docids) in the last 24 hours...
: 
: : 1 tests failed.
: : FAILED:  org.apache.solr.search.join.BJQParserTest.testChildrenParser
: : 
: : Error Message:
: : Exception during query
: : 
: : Stack Trace:
: : java.lang.RuntimeException: Exception during query
:   ...
: : Caused by: java.lang.IllegalStateException: Expect to be advanced on child 
docs only. got docID=13
: :   at 
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.ja$
: 
: 
: ...what changed in the BlockJOin stuff on/arround June 17-18 ?
: 
: 
: 
: 
: : Date: Thu, 18 Jun 2015 18:38:22 + (UTC)
: : From: Policeman Jenkins Server 
: : Reply-To: dev@lucene.apache.org
: : To: dsmi...@apache.org, dev@lucene.apache.org
: : Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - 
Build
: : # 13110 - Still Failing!
: : 
: : Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13110/
: : Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseParallelGC
: : 
: : 1 tests failed.
: : FAILED:  org.apache.solr.search.join.BJQParserTest.testChildrenParser
: : 
: : Error Message:
: : Exception during query
: : 
: : Stack Trace:
: : java.lang.RuntimeException: Exception during query
: : at 
__randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
: : at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
: : at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
: : at 
org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
: : 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:497)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
: : at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
: : at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
: : at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
: : at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
: : at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
: : at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
: : at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
: : at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
: : at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
: : at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
: : at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
: : 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:46)
: : at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
: : at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
: : at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
: : at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethod

[jira] [Comment Edited] (LUCENE-6583) Remove FilteredQuery

[Hoss Man (JIRA)]

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

Hoss Man edited comment on LUCENE-6583 at 6/19/15 5:39 PM:
---

Adrien: your trunk commit seems to be causing a lot of reproducible failures in 
Solr's BJQParserTest (see linked SOLR-7706)


was (Author: hossman):
Adrien: your trunk commit seems to be causing a lot of reproducible failures in 
Solr's BJQParserTest

> Remove FilteredQuery
> 
>
> Key: LUCENE-6583
> URL: https://issues.apache.org/jira/browse/LUCENE-6583
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 6.0
>
> Attachments: LUCENE-6583.patch
>
>
> Now that BooleanQuery can handle filters, FilteredQuery should be removed in 
> trunk and deprecated in 5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6583) Remove FilteredQuery

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-6583:
--

Adrien: your trunk commit seems to be causing a lot of reproducible failures in 
Solr's BJQParserTest

> Remove FilteredQuery
> 
>
> Key: LUCENE-6583
> URL: https://issues.apache.org/jira/browse/LUCENE-6583
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 6.0
>
> Attachments: LUCENE-6583.patch
>
>
> Now that BooleanQuery can handle filters, FilteredQuery should be removed in 
> trunk and deprecated in 5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7706) BJQParserTest failures: Expect to be advanced on child docs only

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7706:


if i revert to r1686202, then all 3 of those seeds pass, as does...

{noformat}
ant beast -Dbeast.iters=10 -Dtestcase=BJQParserTest 
-Dtests.method=testChildrenParser -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.asserts=true
{noformat}

If i update to r1686203, then all 3 of those seeds fail, as does ant beast.

Looks like LUCENE-6583 is somehow the culprit.

> BJQParserTest failures: Expect to be advanced on child docs only
> 
>
> Key: SOLR-7706
> URL: https://issues.apache.org/jira/browse/SOLR-7706
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Between June18 and June19 there have been 5 jenkins failures on trunk with 
> the following stack (only the docIds have changed)...
> {noformat}
>[junit4] ERROR   0.19s | BJQParserTest.testChildrenParser <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
>[junit4]>  at 
> org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.IllegalStateException: Expect to be 
> advanced on child docs only. got docID=13
>[junit4]>  at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:101)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:130)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionScorer.nextDoc(ConjunctionScorer.java:62)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:620)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:204)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1696)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1512)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:563)
>[junit4]>  at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:519)
>[junit4]>  at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>[junit4]>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>[junit4]>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2057)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:320)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:302)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:744)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6143) Bad facet counts from CollapsingQParserPlugin

[Mark Bennett (JIRA)]

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

Mark Bennett commented on SOLR-6143:


Hello [~rebeccatang], I'd say go ahead and log the enhancement request.  
Ideally maybe with some sample data and specific example URLs, maybe even 
examples showing the old vs. new facet counts, etc.

I had wondered about this topic last week, and then this week I'm chatting 
about it with a customer, so I think there's an appetite for it.

> Bad facet counts from CollapsingQParserPlugin 
> --
>
> Key: SOLR-6143
> URL: https://issues.apache.org/jira/browse/SOLR-6143
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 4.8.1
> Environment: UNIX
> Tomcat 7.0.33
> SOLR 4.8.1
> 16 GB RAM
>Reporter: David Fennessey
>
> I'm noticing a very weird bug using the CollapsingQParserPlugin. We tried to 
> use this plugin when we realized that faceting on the groups would take a 
> ridiculous amount of time. To its credit, it works very quickly, however the 
> facet counts that it gives are incorrect. 
> We have a smallish index of about 200k documents with about with about 50k 
> distinct groups within it. 
> When we use the group implementation 
> (&group=true&group.field=PrSKU&group.facet=true) which I believe this 
> attempts to emulate, the facet counts are totally correct. 
> When we use the field collapsing implementation, it will show an incorrect 
> count for the non-filtered query, but when we go to the filtered query, the 
> facet count corrects itself and matches the document count. 
> Here are some SOLR responses:
> solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq={!collapse%20field=PrSKU}&facet=true&facet.field=at_12_wood_tone
> The facet field will return 
> 867
> 441
> 253
> When I actually apply a filter query like so:
> solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq={!collapse%20field=PrSKU}&facet=true&facet.field=at_12_wood_tone&fq=at_12_wood_tone:%22Light%20Wood%22
> I actually pull back 270 results and the facet updates itself with the 
> correct number at the bottom
> 270
> 68
> 66
> If this were the same number pre and post filter query I would assume that it 
> was simply my data that was bad, however I've pored over this for the better 
> part of a day and I'm pretty sure it's the plugin. For reference, this field 
> that I'm faceting on is a multiValued field, however I have noticed the exact 
> same behavior on non multiValued fields (such as price). 
> I can provide any other details you might need



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6591:
-

Can we please rename the method to something simpler than 
'writePossiblyNegativeVLong', like 'writeSignedVLong' ?

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7706) BJQParserTest failures: Expect to be advanced on child docs only

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7706:


A few seeds i've tried that reproduce reliably for me on trunk as of r1686458...

{noformat}
ant test  -Dtestcase=BJQParserTest -Dtests.method=testChildrenParser 
-Dtests.seed=4493157AB2A00BD8 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ro -Dtests.timezone=America/Campo_Grande -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

ant test  -Dtestcase=BJQParserTest -Dtests.method=testChildrenParser 
-Dtests.seed=A8EBF0A8B75EA8BF -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=ru -Dtests.timezone=America/Mexico_City -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8

ant test  -Dtestcase=BJQParserTest -Dtests.method=testChildrenParser 
-Dtests.seed=EC12805F2B3EC03 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=lv -Dtests.timezone=Pacific/Kiritimati -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
{noformat}



> BJQParserTest failures: Expect to be advanced on child docs only
> 
>
> Key: SOLR-7706
> URL: https://issues.apache.org/jira/browse/SOLR-7706
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Between June18 and June19 there have been 5 jenkins failures on trunk with 
> the following stack (only the docIds have changed)...
> {noformat}
>[junit4] ERROR   0.19s | BJQParserTest.testChildrenParser <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
> query
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
>[junit4]>  at 
> org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
>[junit4]> Caused by: java.lang.IllegalStateException: Expect to be 
> advanced on child docs only. got docID=13
>[junit4]>  at 
> org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:101)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:130)
>[junit4]>  at 
> org.apache.lucene.search.ConjunctionScorer.nextDoc(ConjunctionScorer.java:62)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:620)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:204)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1696)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1512)
>[junit4]>  at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:563)
>[junit4]>  at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:519)
>[junit4]>  at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
>[junit4]>  at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
>[junit4]>  at 
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2057)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:320)
>[junit4]>  at 
> org.apache.solr.util.TestHarness.query(TestHarness.java:302)
>[junit4]>  at 
> org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:744)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-7706) BJQParserTest failures: Expect to be advanced on child docs only

[Hoss Man (JIRA)]

Hoss Man created SOLR-7706:
--

 Summary: BJQParserTest failures: Expect to be advanced on child 
docs only
 Key: SOLR-7706
 URL: https://issues.apache.org/jira/browse/SOLR-7706
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


Between June18 and June19 there have been 5 jenkins failures on trunk with the 
following stack (only the docIds have changed)...

{noformat}
   [junit4] ERROR   0.19s | BJQParserTest.testChildrenParser <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
   [junit4]>at 
org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.IllegalStateException: Expect to be 
advanced on child docs only. got docID=13
   [junit4]>at 
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
   [junit4]>at 
org.apache.lucene.search.ConjunctionDISI.doNext(ConjunctionDISI.java:101)
   [junit4]>at 
org.apache.lucene.search.ConjunctionDISI.nextDoc(ConjunctionDISI.java:130)
   [junit4]>at 
org.apache.lucene.search.ConjunctionScorer.nextDoc(ConjunctionScorer.java:62)
   [junit4]>at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:204)
   [junit4]>at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:176)
   [junit4]>at 
org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
   [junit4]>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:620)
   [junit4]>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:204)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1696)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1512)
   [junit4]>at 
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:563)
   [junit4]>at 
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:519)
   [junit4]>at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:255)
   [junit4]>at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
   [junit4]>at 
org.apache.solr.core.SolrCore.execute(SolrCore.java:2057)
   [junit4]>at 
org.apache.solr.util.TestHarness.query(TestHarness.java:320)
   [junit4]>at 
org.apache.solr.util.TestHarness.query(TestHarness.java:302)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:744)
{noformat}





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 13110 - Still Failing!

[Chris Hostetter]

There have been 6 failures of this test (on trunk) with the same root 
cause (but diff docids) in the last 24 hours...

: 1 tests failed.
: FAILED:  org.apache.solr.search.join.BJQParserTest.testChildrenParser
: 
: Error Message:
: Exception during query
: 
: Stack Trace:
: java.lang.RuntimeException: Exception during query
...
: Caused by: java.lang.IllegalStateException: Expect to be advanced on child 
docs only. got docID=13
:   at 
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.ja$


...what changed in the BlockJOin stuff on/arround June 17-18 ?




: Date: Thu, 18 Jun 2015 18:38:22 + (UTC)
: From: Policeman Jenkins Server 
: Reply-To: dev@lucene.apache.org
: To: dsmi...@apache.org, dev@lucene.apache.org
: Subject: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b12) - Build
: # 13110 - Still Failing!
: 
: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13110/
: Java: 64bit/jdk1.8.0_60-ea-b12 -XX:-UseCompressedOops -XX:+UseParallelGC
: 
: 1 tests failed.
: FAILED:  org.apache.solr.search.join.BJQParserTest.testChildrenParser
: 
: Error Message:
: Exception during query
: 
: Stack Trace:
: java.lang.RuntimeException: Exception during query
:   at 
__randomizedtesting.SeedInfo.seed([4493157AB2A00BD8:97A814D5FE80D8B5]:0)
:   at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
:   at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
:   at 
org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
:   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:497)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
:   at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
:   at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
:   at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
:   at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
:   at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
:   at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
:   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
:   at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
:   at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
:   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:46)
:   at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
:   at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
:   at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
:   at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
:   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.l

[jira] [Commented] (LUCENE-6592) backport BooleanQuery.Builder to 5x and deprecated public constructors/setters

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-6592:
--

spin off of LUCENE-6570 per adrian's comments so we don't lose track of it...

bq. ... I know I did not backport to 5.x but the API does not feel stable to me 
yet so I would like to avoid going back-and-forth between different ideas in 
5.x releases. I suggest that we reconsider backporting the new API once we are 
more happy with itI...

> backport BooleanQuery.Builder to 5x and deprecated public constructors/setters
> --
>
> Key: LUCENE-6592
> URL: https://issues.apache.org/jira/browse/LUCENE-6592
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Hoss Man
>Assignee: Adrien Grand
> Fix For: 5.3
>
>
> LUCENE-6570 introduced a new API for instantiating BooleanQuery objects and 
> removed all public constructors.
> This was committed to trunk (for 6.0) but no backporting was done.
> once we are  more confident in definitely including these APIs, the Builder 
> should be backported to 5x, and and the public BooleanQuery constructors & 
> setter methods that change state should be deprecated to help provide a more 
> clear upgrade path for existing users



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6592) backport BooleanQuery.Builder to 5x and deprecated public constructors/setters

[Hoss Man (JIRA)]

Hoss Man created LUCENE-6592:


 Summary: backport BooleanQuery.Builder to 5x and deprecated public 
constructors/setters
 Key: LUCENE-6592
 URL: https://issues.apache.org/jira/browse/LUCENE-6592
 Project: Lucene - Core
  Issue Type: Task
Reporter: Hoss Man
Assignee: Adrien Grand
 Fix For: 5.3


LUCENE-6570 introduced a new API for instantiating BooleanQuery objects and 
removed all public constructors.

This was committed to trunk (for 6.0) but no backporting was done.

once we are  more confident in definitely including these APIs, the Builder 
should be backported to 5x, and and the public BooleanQuery constructors & 
setter methods that change state should be deprecated to help provide a more 
clear upgrade path for existing users



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6585) Make ConjunctionDISI flatten sub ConjunctionDISI instances

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6585:
-

My primary concern is if the flattening optimization is safe.

The test is great for testing this DISI itself, but some of our scorers are 
complicated and have things like coord() at play. 

So it would be great to see some simple nested boolean cases added to 
TestBooleanCoord, so we know the correct scores are still produced when DISIs 
are flattened. Maybe we should also add "conjunction-of-phrases" tests to 
*SearchEquivalence to know that phrase/sloppyphrase/spans/etc are ok with the 
change too.

> Make ConjunctionDISI flatten sub ConjunctionDISI instances
> --
>
> Key: LUCENE-6585
> URL: https://issues.apache.org/jira/browse/LUCENE-6585
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6585.patch
>
>
> Today ConjunctionDISI wraps some sub (two-phase) iterators. I would like to 
> improve it by flattening sub iterators when they implement ConjunctionDISI. 
> In practice, this would make "+A +(+B +C)" be executed more like "+A +B +C" 
> (only in terms of matching, scoring would not change).
> My motivation for this is that if we don't flatten and are unlucky, we can 
> sometimes hit some worst cases. For instance consider the 3 following 
> postings lists (sorted by increasing cost):
> A: 1, 1001, 2001, 3001, ...
> C: 0, 2, 4, 6, 8, 10, 12, 14, ...
> B: 1, 3, 5, 7, 9, 11, 13, 15, ...
> If we run "+A +B +C", then everything works fine, we use A as a lead, and 
> advance B 1000 by 1000 to find the next match (if any).
> However if we run "+A +(+B +C)", then we would iterate B and C 2 by 2 over 
> the entire doc ID space when trying to find the first match which occurs on 
> or after A:1.
> This is an extreme example which is unlikely to happen in practice, but 
> flattening would also help a bit on some more common cases. For instance 
> imagine that A, B and C have respective costs of 100, 10 and 1000. If you 
> search for "+A +(+B +C)", then we will use the most costly iterator (C) to 
> confirm matches of B (the least costly iterator, used as a lead) while it 
> would have been more efficient to confirm matches of B with A first, since A 
> is less costly than C.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Any clue why I'm being asked to moderate these messages from the build system?

[Chris Hostetter]

: Clearly they're coming from Elastic..

pretty sure it's just standard moderatation queue stuff...

the first time a (non-subscribed) addr sends an email to the list, it gets 
held in the queue -- if the moderator just hits "reply" tothe "accept" 
address, then that one message will make it through -- but future messages 
will not.

Which is why moderators are encouraged to "reply-all" so that the "allow" 
address is also hit -- this ensures that future messages from the same 
sender won't get stuck in the moderation queue in the future.

at some point recently elastic changed the email addr used by their CI 
system, so it needed to be re-allowed to send mail, and they started 
popping back up in the moderation queue.

(As a reminder: questions like this are why we have the moderator list, so 
we don't have to distract the entire dev community with meta-discussions 
about dealing with moderation)


: 
: From: bu...@elastic.co
: To: d...@elastic.co, dev@lucene.apache.org, sim...@apache.org
: Cc:
: Date: Fri, 19 Jun 2015 10:56:46 +
: Subject: [CI] Lucene 5x Linux 64 Test Only - Build # 51986 - Failure!
:  BUILD FAILURE
: 
: Build 
URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51986/
: Project:lucene_linux_java8_64_test_only
: Randomization:JDKEA9,local,heap[1024m],-server +UseConcMarkSweepGC
: +UseCompressedOops +AggressiveOpts,sec manager on
: Date of build:Fri, 19 Jun 2015 12:54:09 +0200
: Build duration:2 min 35 sec
: 
: CHANGES
: No Changes
: 
: BUILD ARTIFACTS
: checkout/lucene/build/core/test/temp/junit4-J0-20150619_125429_116.events
: checkout/lucene/build/core/test/temp/junit4-J1-20150619_125429_116.events
: checkout/lucene/build/core/test/temp/junit4-J2-20150619_125429_112.events
: checkout/lucene/build/core/test/temp/junit4-J3-20150619_125429_116.events
: checkout/lucene/build/core/test/temp/junit4-J4-20150619_125429_112.events
: checkout/lucene/build/core/test/temp/junit4-J5-20150619_125429_116.events
: checkout/lucene/build/core/test/temp/junit4-J6-20150619_125429_118.events
: checkout/lucene/build/core/test/temp/junit4-J7-20150619_125429_119.events
: 
: FAILED JUNIT TESTS
: Name: junit.framework Failed: 2 test(s), Passed: 0 test(s), Skipped: 0
: test(s), Total: 2 test(s)
: Failed: 
junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
: Failed: 
junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
: Name: org.apache.lucene.index Failed: 2 test(s), Passed: 774 test(s),
: Skipped: 23 test(s), Total: 799 test(s)
: Failed: 
org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
: Failed: 
org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
: 
: CONSOLE OUTPUT
: [...truncated 1849 lines...]
: [junit4] - 
org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
: [junit4] - 
org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
: [junit4]
: [junit4]
: [junit4] JVM J0: 1.02 .. 125.17 = 124.15s
: [junit4] JVM J1: 1.01 .. 124.41 = 123.39s
: [junit4] JVM J2: 1.33 .. 124.50 = 123.17s
: [junit4] JVM J3: 1.11 .. 122.66 = 121.55s
: [junit4] JVM J4: 1.24 .. 124.04 = 122.80s
: [junit4] JVM J5: 1.01 .. 127.16 = 126.15s
: [junit4] JVM J6: 1.00 .. 133.45 = 132.45s
: [junit4] JVM J7: 1.03 .. 125.12 = 124.08s
: [junit4] Execution time total: 2 minutes 13 seconds
: [junit4] Tests summary: 401 suites, 3227 tests, 2 suite-level errors,
: 2 errors, 48 ignored (44 assumptions)
: BUILD FAILED
: 
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
: The following error occurred while executing this line:
: 
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
: The following error occurred while executing this line:
: 
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
: There were test failures: 401 suites, 3227 tests, 2 suite-level
: errors, 2 errors, 48 ignored (44 assumptions)
: Total time: 2 minutes 21 seconds
: 
: -
: To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: For additional commands, e-mail: dev-h...@lucene.apache.org
: 
: 

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

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

[jira] [Created] (SOLR-7705) CoreAdminHandler Unload no longer handles null core name.

[John Call (JIRA)]

John Call created SOLR-7705:
---

 Summary: CoreAdminHandler Unload no longer handles null core name.
 Key: SOLR-7705
 URL: https://issues.apache.org/jira/browse/SOLR-7705
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 5.2, 5.1, 5.0, 4.10
 Environment: Windows 8 and Windows Server 2012 R2
Reporter: John Call
Priority: Minor
 Fix For: Trunk, 5.2, 5.1, 5.0, 4.10


Pre 4.10 If a null core name was passed in it would be handled as a bad request 
with error message "No such core exists [ null ]". From 4.10 onwards an unload 
call goes to CoreContainer unload where the first action taken is removing the 
core from coreInitFailures which throws when given null and instead of 
returning the expected BadRequest "Cannot unload non-existent core [null]" it 
returns InternalServerError "java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.replaceNode(Unknown Source)
at java.util.concurrent.ConcurrentHashMap.remove(Unknown Source)
at org.apache.solr.core.CoreContainer.unload(CoreContainer.java:661)..."

This was found due to mixing up query parameter "name" used in create vs "core" 
in unload. As a result this is easily reproducible with  
http://localhost:8983/solr/admin/cores?action=UNLOAD&name=core0



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-7513 at 6/19/15 4:40 PM:
---

First impression is that it all looks good. I like the StreamComparator 
introduced in SOLR-7528 and the Equalitors are a nice design. I'll review the 
changes and run all the tests.


was (Author: joel.bernstein):
First impression that it all looks good. I like the StreamComparator introduced 
in SOLR-7528 and Equalitors are a nice design. I'll review the changes some and 
run all the tests.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7513:
--

First impression that it all looks good. I like the StreamComparator introduced 
in SOLR-7528 and Equalitors are a nice design. I'll review the changes some and 
run all the tests.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-7513:
--

The latest patch also includes the work from SOLR-7528.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6591:
--

+1

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-7513) Add Equalitors to Streaming Expressions

[Joel Bernstein (JIRA)]

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

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

New patch created with svn diff against current trunk. StreamingTests are 
passing.

> Add Equalitors to Streaming Expressions
> ---
>
> Key: SOLR-7513
> URL: https://issues.apache.org/jira/browse/SOLR-7513
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Assignee: Joel Bernstein
>Priority: Minor
> Fix For: 5.3
>
> Attachments: SOLR-7513.patch, SOLR-7513.patch, SOLR-7513.patch
>
>
> Right now all streams use the Comparator interface to compare tuples. 
> The Comparator interface will tell you if tupleA is before, after, or equal 
> to tupleB. This is great for most streams as they use this logic when 
> combining multiple streams together. However, some streams only care about 
> the equality of two tuples and the less/greater than logic is unnecessary.
> This depends on SOLR-7377.
> This patch is to introduce a new interface into streaming expressions called 
> Equalitor which will return if two tuples are equal. The benefit here 
> is that the expressions for streams using Equalitor instead of Comparator can 
> omit the ordering part.
> {code}
> unique(somestream, over="fieldA asc, fieldB desc")
> {code}
> can become
> {code}
> unique(somestream, over="fieldA,fieldB")
> {code}
> The added benefit is that this will set us up with simplier expressions for 
> joins (hash, merge, inner, outer, etc...) as those only care about equality.
> By adding this as an interface we make no assumptions about what it means to 
> be equal, just that some implementation needs to exist adhering to the 
> Equalitor interface which will determine if two tuples are logically 
> equal. 
> We do define at least one concrete class which checks for equality but that 
> does not preclude others from adding additional concrete classes with their 
> own logic in place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6591) Never write negative vLongs

[Ryan Ernst (JIRA)]

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

Ryan Ernst commented on LUCENE-6591:


+1

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-6590:


+1 to relegate boosting to a new BoostQuery, nomatter the pain!

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b60) - Build # 12946 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12946/
Java: 64bit/jdk1.9.0-ea-b60 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls

Error Message:
Shard split did not complete. Last recorded state: running 
expected:<[completed]> but was:<[running]>

Stack Trace:
org.junit.ComparisonFailure: Shard split did not complete. Last recorded state: 
running expected:<[completed]> but was:<[running]>
at 
__randomizedtesting.SeedInfo.seed([C699BD1DCC8D7991:9EFD317CCAE7D145]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at 
org.apache.solr.cloud.CollectionsAPIAsyncDistributedZkTest.testSolrJAPICalls(CollectionsAPIAsyncDistributedZkTest.java:83)
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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.car

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6590:
-

If we just removed Query.get/setBoost and replaced with something like 
BoostQuery(Query q, float boost) then it could simplify some APIs in scoring as 
well.

Today we already have to handle the case of 2 different boosts (boosts coming 
from parent queries in Weight.normalize, and also the leaf's own Query.boost). 
It makes things confusing in Weight/Similarity.normalize() where they must deal 
with these 2 separate boosts and combine them to one.

So this could all be removed and reduced to boosts handled via one codepath in 
Weight:

{code}
  /** Assigns the query normalization factor and boost to this. */
  public abstract void normalize(float norm, float boost);
{code}

That is in addition to reducing the possibility of bugs like forgetting to use 
boost higher up the stack, which I think is very common.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6591) Never write negative vLongs

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-6591:
---
Attachment: LUCENE-6591.patch

Patch.

I also renamed a private method in DataOutput, and fixed typo in comment.

> Never write negative vLongs
> ---
>
> Key: LUCENE-6591
> URL: https://issues.apache.org/jira/browse/LUCENE-6591
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6591.patch
>
>
> Today we only assert that the incoming argument to writeVLong is 
> non-negative; I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-6590:
--

Removing boost from Query and having a dedicated BoostQuery makes the most 
sense if one were starting from scratch.
We're not starting from scratch though (messing with boost would change a *lot* 
of code), so I'm not sure where that leaves us.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6591) Never write negative vLongs

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-6591:
--

 Summary: Never write negative vLongs
 Key: LUCENE-6591
 URL: https://issues.apache.org/jira/browse/LUCENE-6591
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.3, Trunk


Today we only assert that the incoming argument to writeVLong is non-negative; 
I think this is quite important and should be a real check?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-7701) NPE on spatial RPT field

[Markus Jelsma (JIRA)]

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

Markus Jelsma resolved SOLR-7701.
-
Resolution: Duplicate

> NPE on spatial RPT field
> 
>
> Key: SOLR-7701
> URL: https://issues.apache.org/jira/browse/SOLR-7701
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 5.2.1
>Reporter: Markus Jelsma
> Fix For: 5.3
>
>
> We have a field type:
>  class="solr.SpatialRecursivePrefixTreeFieldType" geo="true" maxLevels="5" 
> distanceUnits="kilometers"/>
> We need all docs that have a value for it:
> http://localhost:8983/solr/select?q=coord:[*+TO+*]
> NPE
> {log}
> 87063 [qtp2096057945-14] ERROR org.apache.solr.servlet.SolrDispatchFilter  [  
>  logs] – null:java.lang.NullPointerException
> at java.lang.String.contains(String.java:2120)
> at 
> org.apache.solr.util.SpatialUtils.parsePointSolrException(SpatialUtils.java:111)
> at 
> org.apache.solr.schema.AbstractSpatialFieldType.getRangeQuery(AbstractSpatialFieldType.java:294)
> at 
> org.apache.solr.parser.SolrQueryParserBase.getRangeQuery(SolrQueryParserBase.java:761)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:382)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:185)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:107)
> at 
> org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:96)
> at 
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:151)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:50)
> at org.apache.solr.search.QParser.getQuery(QParser.java:141)
> at 
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:203)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:229)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:640)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:436)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:497)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at 
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> {log}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (LUCENE-6570) Make BooleanQuery immutable

[Adrien Grand (JIRA)]

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

Adrien Grand closed LUCENE-6570.

Resolution: Fixed

I opened LUCENE-6590 as a follow-up for the boosting issue.

I am re-closing now: I know I did not backport to 5.x but the API does not feel 
stable to me yet so I would like to avoid going back-and-forth between 
different ideas in 5.x releases. I suggest that we reconsider backporting the 
new API once we are more happy with itI...

> Make BooleanQuery immutable
> ---
>
> Key: LUCENE-6570
> URL: https://issues.apache.org/jira/browse/LUCENE-6570
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6570.patch
>
>
> In the same spirit as LUCENE-6531 for the PhraseQuery, we should make 
> BooleanQuery immutable.
> The plan is the following:
>  - create BooleanQuery.Builder with the same setters as BooleanQuery today 
> (except setBoost) and a build() method that returns a BooleanQuery
>  - remove setters from BooleanQuery (except setBoost)
> I would also like to add some static utility methods for common use-cases of 
> this query, for instance:
>  - static BooleanQuery disjunction(Query... queries) to create a disjunction
>  - static BooleanQuery conjunction(Query... queries) to create a conjunction
>  - static BooleanQuery filtered(Query query, Query... filters) to create a 
> filtered query
> Hopefully this will help keep tests not too verbose, and the latter will also 
> help with the FilteredQuery derecation/removal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6590) Explore different ways to apply boosts

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6590:


 Summary: Explore different ways to apply boosts
 Key: LUCENE-6590
 URL: https://issues.apache.org/jira/browse/LUCENE-6590
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Adrien Grand
Priority: Minor


Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
allow for applying a boost raises issues since it makes queries bad cache keys 
since their hashcode can change anytime. We could just document that queries 
should never be modified after they have gone through IndexSearcher but it 
would be even better if the API made queries impossible to mutate at all.

I think there are two main options:
 - either replace "void setBoost(boost)" with something like "Query 
withBoost(boost)" which would return a clone that has a different boost
 - or move boost handling outside of Query, for instance we could have a 
(immutable) query impl that would be dedicated to applying boosts, that queries 
that need to change boosts at rewrite time (such as BooleanQuery) would use as 
a wrapper.

The latter idea is from Robert and I like it a lot given how often I either 
introduced or found a bug which was due to the boost parameter being ignored. 
Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6570) Make BooleanQuery immutable

[ASF subversion and git services (JIRA)]

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

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

Commit 1686440 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1686440 ]

LUCENE-6570: Add a MIGRATE entry.

> Make BooleanQuery immutable
> ---
>
> Key: LUCENE-6570
> URL: https://issues.apache.org/jira/browse/LUCENE-6570
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6570.patch
>
>
> In the same spirit as LUCENE-6531 for the PhraseQuery, we should make 
> BooleanQuery immutable.
> The plan is the following:
>  - create BooleanQuery.Builder with the same setters as BooleanQuery today 
> (except setBoost) and a build() method that returns a BooleanQuery
>  - remove setters from BooleanQuery (except setBoost)
> I would also like to add some static utility methods for common use-cases of 
> this query, for instance:
>  - static BooleanQuery disjunction(Query... queries) to create a disjunction
>  - static BooleanQuery conjunction(Query... queries) to create a conjunction
>  - static BooleanQuery filtered(Query query, Query... filters) to create a 
> filtered query
> Hopefully this will help keep tests not too verbose, and the latter will also 
> help with the FilteredQuery derecation/removal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Any clue why I'm being asked to moderate these messages from the build system?

[Erick Erickson]

Clearly they're coming from Elastic..

From: bu...@elastic.co
To: d...@elastic.co, dev@lucene.apache.org, sim...@apache.org
Cc:
Date: Fri, 19 Jun 2015 10:56:46 +
Subject: [CI] Lucene 5x Linux 64 Test Only - Build # 51986 - Failure!
 BUILD FAILURE

Build 
URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51986/
Project:lucene_linux_java8_64_test_only
Randomization:JDKEA9,local,heap[1024m],-server +UseConcMarkSweepGC
+UseCompressedOops +AggressiveOpts,sec manager on
Date of build:Fri, 19 Jun 2015 12:54:09 +0200
Build duration:2 min 35 sec

CHANGES
No Changes

BUILD ARTIFACTS
checkout/lucene/build/core/test/temp/junit4-J0-20150619_125429_116.events
checkout/lucene/build/core/test/temp/junit4-J1-20150619_125429_116.events
checkout/lucene/build/core/test/temp/junit4-J2-20150619_125429_112.events
checkout/lucene/build/core/test/temp/junit4-J3-20150619_125429_116.events
checkout/lucene/build/core/test/temp/junit4-J4-20150619_125429_112.events
checkout/lucene/build/core/test/temp/junit4-J5-20150619_125429_116.events
checkout/lucene/build/core/test/temp/junit4-J6-20150619_125429_118.events
checkout/lucene/build/core/test/temp/junit4-J7-20150619_125429_119.events

FAILED JUNIT TESTS
Name: junit.framework Failed: 2 test(s), Passed: 0 test(s), Skipped: 0
test(s), Total: 2 test(s)
Failed: 
junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
Failed: 
junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32
Name: org.apache.lucene.index Failed: 2 test(s), Passed: 774 test(s),
Skipped: 23 test(s), Total: 799 test(s)
Failed: 
org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
Failed: 
org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream

CONSOLE OUTPUT
[...truncated 1849 lines...]
[junit4] - 
org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
[junit4] - 
org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
[junit4]
[junit4]
[junit4] JVM J0: 1.02 .. 125.17 = 124.15s
[junit4] JVM J1: 1.01 .. 124.41 = 123.39s
[junit4] JVM J2: 1.33 .. 124.50 = 123.17s
[junit4] JVM J3: 1.11 .. 122.66 = 121.55s
[junit4] JVM J4: 1.24 .. 124.04 = 122.80s
[junit4] JVM J5: 1.01 .. 127.16 = 126.15s
[junit4] JVM J6: 1.00 .. 133.45 = 132.45s
[junit4] JVM J7: 1.03 .. 125.12 = 124.08s
[junit4] Execution time total: 2 minutes 13 seconds
[junit4] Tests summary: 401 suites, 3227 tests, 2 suite-level errors,
2 errors, 48 ignored (44 assumptions)
BUILD FAILED
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
The following error occurred while executing this line:
/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
There were test failures: 401 suites, 3227 tests, 2 suite-level
errors, 2 errors, 48 ignored (44 assumptions)
Total time: 2 minutes 21 seconds

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

[jira] [Assigned] (LUCENE-6554) ToBlockJoinFieldComparator wrapping is illegal

[Adrien Grand (JIRA)]

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

Adrien Grand reassigned LUCENE-6554:


Assignee: Adrien Grand

> ToBlockJoinFieldComparator wrapping is illegal
> --
>
> Key: LUCENE-6554
> URL: https://issues.apache.org/jira/browse/LUCENE-6554
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Attachments: LUCENE-6554.patch
>
>
> The following test case triggers an AssertionError:
> {code}
>   public void testMissingValues() throws IOException {
> final Directory dir = newDirectory();
> final RandomIndexWriter w = new RandomIndexWriter(random(), dir, 
> newIndexWriterConfig(new MockAnalyzer(random()))
> .setMergePolicy(NoMergePolicy.INSTANCE));
> w.addDocument(new Document());
> w.getReader().close();
> w.addDocument(new Document());
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> // all docs are parent
> BitDocIdSetFilter parentFilter = new BitDocIdSetCachingWrapperFilter(new 
> QueryWrapperFilter(new MatchAllDocsQuery()));
> BitDocIdSetFilter childFilter = new BitDocIdSetCachingWrapperFilter(new 
> QueryWrapperFilter(new MatchNoDocsQuery()));
> ToParentBlockJoinSortField sortField = new ToParentBlockJoinSortField(
> "some_random_field", SortField.Type.STRING, false, parentFilter, 
> childFilter
> );
> Sort sort = new Sort(sortField);
> TopFieldDocs topDocs = searcher.search(new MatchAllDocsQuery(), 1, sort);
> searcher.getIndexReader().close();
> dir.close();
>   }
> {code}
> {code}
> java.lang.AssertionError
>   at 
> __randomizedtesting.SeedInfo.seed([E9D45D81F597AE4B:83490FC7D11D9ABA]:0)
>   at 
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.setBottom(FieldComparator.java:800)
>   at 
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.getLeafComparator(FieldComparator.java:783)
>   at 
> org.apache.lucene.search.join.ToParentBlockJoinFieldComparator.doSetNextReader(ToParentBlockJoinFieldComparator.java:83)
>   at 
> org.apache.lucene.search.SimpleFieldComparator.getLeafComparator(SimpleFieldComparator.java:36)
>   at 
> org.apache.lucene.search.FieldValueHitQueue.getComparators(FieldValueHitQueue.java:183)
>   at 
> org.apache.lucene.search.TopFieldCollector$NonScoringCollector.getLeafCollector(TopFieldCollector.java:141)
>   at 
> org.apache.lucene.search.FilterCollector.getLeafCollector(FilterCollector.java:40)
>   at 
> org.apache.lucene.search.AssertingCollector.getLeafCollector(AssertingCollector.java:48)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:611)
>   at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:543)
>   at 
> org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:528)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:455)
>   at 
> org.apache.lucene.search.join.TestBlockJoinSorting.testMissingValues(TestBlockJoinSorting.java:347)
>   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:483)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
>   at 
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
>   at 
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
>   a

[jira] [Updated] (LUCENE-6554) ToBlockJoinFieldComparator wrapping is illegal

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6554:
-
Attachment: LUCENE-6554.patch

I tried to think about a replacement for this feature and it would require us 
to implement a selector for all combinations of dv types and sort modes. 
Additionally, these selectors would have the downside of being linear with the 
number of child documents, which I don't think is something we should 
encourage: it would be more efficient to store aggregated information at the 
parent level directly.

So I propose that we just remove the functionnality from the join module.

> ToBlockJoinFieldComparator wrapping is illegal
> --
>
> Key: LUCENE-6554
> URL: https://issues.apache.org/jira/browse/LUCENE-6554
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
> Attachments: LUCENE-6554.patch
>
>
> The following test case triggers an AssertionError:
> {code}
>   public void testMissingValues() throws IOException {
> final Directory dir = newDirectory();
> final RandomIndexWriter w = new RandomIndexWriter(random(), dir, 
> newIndexWriterConfig(new MockAnalyzer(random()))
> .setMergePolicy(NoMergePolicy.INSTANCE));
> w.addDocument(new Document());
> w.getReader().close();
> w.addDocument(new Document());
> IndexReader reader = w.getReader();
> w.close();
> IndexSearcher searcher = newSearcher(reader);
> // all docs are parent
> BitDocIdSetFilter parentFilter = new BitDocIdSetCachingWrapperFilter(new 
> QueryWrapperFilter(new MatchAllDocsQuery()));
> BitDocIdSetFilter childFilter = new BitDocIdSetCachingWrapperFilter(new 
> QueryWrapperFilter(new MatchNoDocsQuery()));
> ToParentBlockJoinSortField sortField = new ToParentBlockJoinSortField(
> "some_random_field", SortField.Type.STRING, false, parentFilter, 
> childFilter
> );
> Sort sort = new Sort(sortField);
> TopFieldDocs topDocs = searcher.search(new MatchAllDocsQuery(), 1, sort);
> searcher.getIndexReader().close();
> dir.close();
>   }
> {code}
> {code}
> java.lang.AssertionError
>   at 
> __randomizedtesting.SeedInfo.seed([E9D45D81F597AE4B:83490FC7D11D9ABA]:0)
>   at 
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.setBottom(FieldComparator.java:800)
>   at 
> org.apache.lucene.search.FieldComparator$TermOrdValComparator.getLeafComparator(FieldComparator.java:783)
>   at 
> org.apache.lucene.search.join.ToParentBlockJoinFieldComparator.doSetNextReader(ToParentBlockJoinFieldComparator.java:83)
>   at 
> org.apache.lucene.search.SimpleFieldComparator.getLeafComparator(SimpleFieldComparator.java:36)
>   at 
> org.apache.lucene.search.FieldValueHitQueue.getComparators(FieldValueHitQueue.java:183)
>   at 
> org.apache.lucene.search.TopFieldCollector$NonScoringCollector.getLeafCollector(TopFieldCollector.java:141)
>   at 
> org.apache.lucene.search.FilterCollector.getLeafCollector(FilterCollector.java:40)
>   at 
> org.apache.lucene.search.AssertingCollector.getLeafCollector(AssertingCollector.java:48)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:611)
>   at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:92)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:424)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:543)
>   at 
> org.apache.lucene.search.IndexSearcher.searchAfter(IndexSearcher.java:528)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:455)
>   at 
> org.apache.lucene.search.join.TestBlockJoinSorting.testMissingValues(TestBlockJoinSorting.java:347)
>   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:483)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
>   at 
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
>   at 
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
>   at 
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> 

[jira] [Commented] (LUCENE-6586) There is a typo in GermanStemmer that can lead to wrong stemming

[Erick Erickson (JIRA)]

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

Erick Erickson commented on LUCENE-6586:


Thanks for reporting this! Yeah, Git is there for convenience, JIRAs are how we
track code changes, the "usual" method of drawing attention to a code problem
is to attach a patch to a JIRA.

I noticed that the "How To Contribute" page really doesn't mention this, I'll 
see
if I can update it.

Thanks for both noticing the original problem and your persistence bringing it
to our attention!



> There is a typo in GermanStemmer that can lead to wrong stemming
> 
>
> Key: LUCENE-6586
> URL: https://issues.apache.org/jira/browse/LUCENE-6586
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/analysis
>Affects Versions: 5.2.1
>Reporter: Christoph Kaser
>Priority: Minor
>
> There is a small typo in GermanStemmer that leads to a wrong calclulation of 
> the substCount in line 203:
> {code}substCount =+ 2;{code}
> should be
> {code}substCount += 2;{code}
> I created a Pull Request for this some time ago, but it was apprently 
> overlooked:
> https://github.com/apache/lucene-solr/pull/141



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_45) - Build # 13123 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13123/
Java: 32bit/jdk1.8.0_45 -client -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.search.join.BJQParserTest.testChildrenParser

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([881B76B2F8E4F14A:5B20771DB4C42227]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:770)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:737)
at 
org.apache.solr.search.join.BJQParserTest.testChildrenParser(BJQParserTest.java:218)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Expect to be advanced on child docs 
only. got docID=20
at 
org.apache.lucene.search.join.ToChildBlockJoinQuery$ToChildBlockJoinScorer.advance(ToChildBlockJoinQuery.java:279)
at 
org.apache.lucene.search.ConjunctionDISI.doNe

[jira] [Commented] (LUCENE-6585) Make ConjunctionDISI flatten sub ConjunctionDISI instances

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6585:
--

+1

> Make ConjunctionDISI flatten sub ConjunctionDISI instances
> --
>
> Key: LUCENE-6585
> URL: https://issues.apache.org/jira/browse/LUCENE-6585
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6585.patch
>
>
> Today ConjunctionDISI wraps some sub (two-phase) iterators. I would like to 
> improve it by flattening sub iterators when they implement ConjunctionDISI. 
> In practice, this would make "+A +(+B +C)" be executed more like "+A +B +C" 
> (only in terms of matching, scoring would not change).
> My motivation for this is that if we don't flatten and are unlucky, we can 
> sometimes hit some worst cases. For instance consider the 3 following 
> postings lists (sorted by increasing cost):
> A: 1, 1001, 2001, 3001, ...
> C: 0, 2, 4, 6, 8, 10, 12, 14, ...
> B: 1, 3, 5, 7, 9, 11, 13, 15, ...
> If we run "+A +B +C", then everything works fine, we use A as a lead, and 
> advance B 1000 by 1000 to find the next match (if any).
> However if we run "+A +(+B +C)", then we would iterate B and C 2 by 2 over 
> the entire doc ID space when trying to find the first match which occurs on 
> or after A:1.
> This is an extreme example which is unlikely to happen in practice, but 
> flattening would also help a bit on some more common cases. For instance 
> imagine that A, B and C have respective costs of 100, 10 and 1000. If you 
> search for "+A +(+B +C)", then we will use the most costly iterator (C) to 
> confirm matches of B (the least costly iterator, used as a lead) while it 
> would have been more efficient to confirm matches of B with A first, since A 
> is less costly than C.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6589) Less leniency in lucene/join

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6589:
-
Attachment: LUCENE-6589.patch

Here is a patch which adds a CheckJoinIndex utility class and runs it in the 
join tests.

I fixed some tests to not index garbage documents, and had to remove a test 
that assumed it was ok to have a non-deleted parent document with deleted 
children.

> Less leniency in lucene/join
> 
>
> Key: LUCENE-6589
> URL: https://issues.apache.org/jira/browse/LUCENE-6589
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6589.patch
>
>
> The lucene/join module expects a certain index structure but nothing 
> validates it. Then at search time it either needs to validate the index 
> structure in a slow way or be lenient and cope with what it is given.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-6589) Less leniency in lucene/join

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6589:


 Summary: Less leniency in lucene/join
 Key: LUCENE-6589
 URL: https://issues.apache.org/jira/browse/LUCENE-6589
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Priority: Minor


The lucene/join module expects a certain index structure but nothing validates 
it. Then at search time it either needs to validate the index structure in a 
slow way or be lenient and cope with what it is given.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-6585) Make ConjunctionDISI flatten sub ConjunctionDISI instances

[Ryan Ernst (JIRA)]

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

Ryan Ernst updated LUCENE-6585:
---
Attachment: LUCENE-6585.patch

Here is a patch collapsing all subconjunctions (thanks [~jpountz] for the help 
with twophase).

> Make ConjunctionDISI flatten sub ConjunctionDISI instances
> --
>
> Key: LUCENE-6585
> URL: https://issues.apache.org/jira/browse/LUCENE-6585
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6585.patch
>
>
> Today ConjunctionDISI wraps some sub (two-phase) iterators. I would like to 
> improve it by flattening sub iterators when they implement ConjunctionDISI. 
> In practice, this would make "+A +(+B +C)" be executed more like "+A +B +C" 
> (only in terms of matching, scoring would not change).
> My motivation for this is that if we don't flatten and are unlucky, we can 
> sometimes hit some worst cases. For instance consider the 3 following 
> postings lists (sorted by increasing cost):
> A: 1, 1001, 2001, 3001, ...
> C: 0, 2, 4, 6, 8, 10, 12, 14, ...
> B: 1, 3, 5, 7, 9, 11, 13, 15, ...
> If we run "+A +B +C", then everything works fine, we use A as a lead, and 
> advance B 1000 by 1000 to find the next match (if any).
> However if we run "+A +(+B +C)", then we would iterate B and C 2 by 2 over 
> the entire doc ID space when trying to find the first match which occurs on 
> or after A:1.
> This is an extreme example which is unlikely to happen in practice, but 
> flattening would also help a bit on some more common cases. For instance 
> imagine that A, B and C have respective costs of 100, 10 and 1000. If you 
> search for "+A +(+B +C)", then we will use the most costly iterator (C) to 
> confirm matches of B (the least costly iterator, used as a lead) while it 
> would have been more efficient to confirm matches of B with A first, since A 
> is less costly than C.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6570) Make BooleanQuery immutable

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-6570:
--

Maybe we could satisfy people who want different things by having BooleanQuery 
be an abstract class.
Things like defensive clones could be part of the default builder, but expert 
users could avoid the overhead of extra data structures introduced in 
LUCENE-6305 for example.  It would give a way for well-behaved code that 
generates predictable queries to get maximum performance and minimum memory 
usage.

> Make BooleanQuery immutable
> ---
>
> Key: LUCENE-6570
> URL: https://issues.apache.org/jira/browse/LUCENE-6570
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6570.patch
>
>
> In the same spirit as LUCENE-6531 for the PhraseQuery, we should make 
> BooleanQuery immutable.
> The plan is the following:
>  - create BooleanQuery.Builder with the same setters as BooleanQuery today 
> (except setBoost) and a build() method that returns a BooleanQuery
>  - remove setters from BooleanQuery (except setBoost)
> I would also like to add some static utility methods for common use-cases of 
> this query, for instance:
>  - static BooleanQuery disjunction(Query... queries) to create a disjunction
>  - static BooleanQuery conjunction(Query... queries) to create a conjunction
>  - static BooleanQuery filtered(Query query, Query... filters) to create a 
> filtered query
> Hopefully this will help keep tests not too verbose, and the latter will also 
> help with the FilteredQuery derecation/removal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6305:
-

Slightly off topic to your original goal, but what do you think about deduping 
repeated non scoring (FILTER, MUST_NOT) clauses from the list in the query or 
do you see that as an possible optimization when building the weights/scorers?




> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensible to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6305:
-

Oops, read the patch too quickly and missed that key detail! Sorry for the 
noise.



> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensible to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6305:
--

This is exactly what the patch is doing: clauses are put both into a list and a 
multiset, and the list is used for clauses()/toString() while the multiset is 
used for equals()/hashcode(). So the iteration order is predictable.

> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensible to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6305) BooleanQuery.equals should ignore clause order

[Terry Smith (JIRA)]

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

Terry Smith commented on LUCENE-6305:
-

Having BooleanQuery.equals() ignore order is a great idea but I think it'd be 
better if we could preserve the original clause order for Query.toString(), the 
Explanation, debugging and test expectations. 

Additionally, I've been burnt by JVM changes to String.hashCode() that cause 
HashMap to order entries differently when run in a newer JVM. Are the 
Query hash codes immune to this problem?


> BooleanQuery.equals should ignore clause order
> --
>
> Key: LUCENE-6305
> URL: https://issues.apache.org/jira/browse/LUCENE-6305
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6305.patch
>
>
> BooleanQuery.equals is sensible to the order in which clauses have been 
> added. So for instance "+A +B" would be considered different from "+B +A" 
> although it generates the same matches and scores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13122 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13122/
Java: 32bit/jdk1.9.0-ea-b60 -client -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.search.TestSearcherReuse.test

Error Message:
expected same:
 was not:

Stack Trace:
java.lang.AssertionError: expected same:
 was not:
at 
__randomizedtesting.SeedInfo.seed([36488472EEED0F0E:BE1CBBA8401162F6]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotSame(Assert.java:641)
at org.junit.Assert.assertSame(Assert.java:580)
at org.junit.Assert.assertSame(Assert.java:593)
at 
org.apache.solr.search.TestSearcherReuse.assertSearcherHasNotChanged(TestSearcherReuse.java:247)
at 
org.apache.solr.search.TestSearcherReuse.test(TestSearcherReuse.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:502)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 9620 lines...]
   [junit4] Suite: org.apache.solr.search.TestSearcherReuse
   [junit4]   2>

[jira] [Reopened] (LUCENE-6570) Make BooleanQuery immutable

[Adrien Grand (JIRA)]

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

Adrien Grand reopened LUCENE-6570:
--

I removed the controversial query cloning. Reopening to think about how we 
should handle the boost factor then. Options include cloning as part of 
createWeight since the query we are really interested in is the one returned by 
Weight.getQuery(), removing "void setBoost(boost)" in favour of something like 
"Query withBoost(boost)" or even remove the boost parameter from our queries 
and handle it externally.

> Make BooleanQuery immutable
> ---
>
> Key: LUCENE-6570
> URL: https://issues.apache.org/jira/browse/LUCENE-6570
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6570.patch
>
>
> In the same spirit as LUCENE-6531 for the PhraseQuery, we should make 
> BooleanQuery immutable.
> The plan is the following:
>  - create BooleanQuery.Builder with the same setters as BooleanQuery today 
> (except setBoost) and a build() method that returns a BooleanQuery
>  - remove setters from BooleanQuery (except setBoost)
> I would also like to add some static utility methods for common use-cases of 
> this query, for instance:
>  - static BooleanQuery disjunction(Query... queries) to create a disjunction
>  - static BooleanQuery conjunction(Query... queries) to create a conjunction
>  - static BooleanQuery filtered(Query query, Query... filters) to create a 
> filtered query
> Hopefully this will help keep tests not too verbose, and the latter will also 
> help with the FilteredQuery derecation/removal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 51991 - Failure!

[Michael McCandless]

I committed a fix ...

Mike McCandless

On Fri, Jun 19, 2015 at 9:11 AM, Michael McCandless  wrote:

> I'll dig.
>
> Mike McCandless
>
> On Fri, Jun 19, 2015 at 7:37 AM,  wrote:
>
>>   *BUILD FAILURE*
>> Build URL
>> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51991/
>> Project:lucene_linux_java8_64_test_only Randomization: 
>> JDKEA8,network,heap[531m],-server
>> +UseSerialGC -UseCompressedOops +AggressiveOpts Date of build:Fri, 19
>> Jun 2015 13:34:56 +0200 Build duration:2 min 48 sec
>>  *CHANGES* No Changes
>>  *BUILD ARTIFACTS*
>> checkout/lucene/build/core/test/temp/junit4-J0-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J1-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J2-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J3-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J4-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J5-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J6-20150619_133514_815.events
>> 
>> checkout/lucene/build/core/test/temp/junit4-J7-20150619_133514_816.events
>> 
>>  *FAILED JUNIT TESTS* Name: org.apache.lucene.search Failed: 1 test(s),
>> Passed: 781 test(s), Skipped: 2 test(s), Total: 784 test(s)
>> *Failed:
>> org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution *
>>  *CONSOLE OUTPUT* [...truncated 1772 lines...] [junit4] Tests with
>> failures: [junit4] -
>> org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution 
>> [junit4]
>>  [junit4]  [junit4] JVM J0: 1.08 .. 138.08 = 137.01s [junit4] JVM J1:
>> 0.86 .. 141.69 = 140.83s [junit4] JVM J2: 1.08 .. 139.95 = 138.87s [junit4]
>> JVM J3: 0.86 .. 136.07 = 135.21s [junit4] JVM J4: 1.08 .. 140.07 =
>> 138.98s [junit4] JVM J5: 0.90 .. 140.21 = 139.31s [junit4] JVM J6: 0.84
>> .. 140.76 = 139.92s [junit4] JVM J7: 0.86 .. 148.21 = 147.34s [junit4]
>> Execution time total: 2 minutes 28 seconds [junit4] Tests summary: 401
>> suites, 3250 tests, 1 failure, 50 ignored (46 assumptions) BUILD FAILED 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
>> The following error occurred while executing this line: 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
>> The following error occurred while executing this line: 
>> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
>> There were test failures: 401 suites, 3250 tests, 1 failure, 50 ignored (46
>> assumptions) Total time: 2 minutes 35 seconds Build step 'Invoke Ant'
>> marked build as failure Archiving artifacts Recording test results 
>> [description-setter]
>> Description set: JDKEA8,network,heap[531m],-server +UseSerialGC
>> -UseCompressedOops +AggressiveOpts Email was triggered for: Failure - 1st 
>> Trigger
>> Failure - Any was overridden by another trigger and will not send an email. 
>> Trigger
>> Failure - Still was overridden by another trigger and will not send an
>> email. Sending email for trigger: Failure - 1st
>>
>
>

[jira] [Commented] (LUCENE-6570) Make BooleanQuery immutable

[ASF subversion and git services (JIRA)]

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

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

Commit 1686408 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1686408 ]

LUCENE-6570: Remove controversial defensive cloning of queries when adding them 
to a BooleanQuery.

> Make BooleanQuery immutable
> ---
>
> Key: LUCENE-6570
> URL: https://issues.apache.org/jira/browse/LUCENE-6570
> Project: Lucene - Core
>  Issue Type: Task
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 6.0
>
> Attachments: LUCENE-6570.patch
>
>
> In the same spirit as LUCENE-6531 for the PhraseQuery, we should make 
> BooleanQuery immutable.
> The plan is the following:
>  - create BooleanQuery.Builder with the same setters as BooleanQuery today 
> (except setBoost) and a build() method that returns a BooleanQuery
>  - remove setters from BooleanQuery (except setBoost)
> I would also like to add some static utility methods for common use-cases of 
> this query, for instance:
>  - static BooleanQuery disjunction(Query... queries) to create a disjunction
>  - static BooleanQuery conjunction(Query... queries) to create a conjunction
>  - static BooleanQuery filtered(Query query, Query... filters) to create a 
> filtered query
> Hopefully this will help keep tests not too verbose, and the latter will also 
> help with the FilteredQuery derecation/removal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 51991 - Failure!

[Michael McCandless]

I'll dig.

Mike McCandless

On Fri, Jun 19, 2015 at 7:37 AM,  wrote:

>   *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51991/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDKEA8,network,heap[531m],-server
> +UseSerialGC -UseCompressedOops +AggressiveOpts Date of build:Fri, 19 Jun
> 2015 13:34:56 +0200 Build duration:2 min 48 sec
>  *CHANGES* No Changes
>  *BUILD ARTIFACTS*
> checkout/lucene/build/core/test/temp/junit4-J0-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J1-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J2-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J3-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J4-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J5-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J6-20150619_133514_815.events
> 
> checkout/lucene/build/core/test/temp/junit4-J7-20150619_133514_816.events
> 
>  *FAILED JUNIT TESTS* Name: org.apache.lucene.search Failed: 1 test(s),
> Passed: 781 test(s), Skipped: 2 test(s), Total: 784 test(s)
> *Failed:
> org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution *
>  *CONSOLE OUTPUT* [...truncated 1772 lines...] [junit4] Tests with
> failures: [junit4] -
> org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution 
> [junit4]
>  [junit4]  [junit4] JVM J0: 1.08 .. 138.08 = 137.01s [junit4] JVM J1:
> 0.86 .. 141.69 = 140.83s [junit4] JVM J2: 1.08 .. 139.95 = 138.87s [junit4]
> JVM J3: 0.86 .. 136.07 = 135.21s [junit4] JVM J4: 1.08 .. 140.07 = 138.98s 
> [junit4]
> JVM J5: 0.90 .. 140.21 = 139.31s [junit4] JVM J6: 0.84 .. 140.76 = 139.92s 
> [junit4]
> JVM J7: 0.86 .. 148.21 = 147.34s [junit4] Execution time total: 2 minutes
> 28 seconds [junit4] Tests summary: 401 suites, 3250 tests, 1 failure, 50
> ignored (46 assumptions) BUILD FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
> There were test failures: 401 suites, 3250 tests, 1 failure, 50 ignored (46
> assumptions) Total time: 2 minutes 35 seconds Build step 'Invoke Ant'
> marked build as failure Archiving artifacts Recording test results 
> [description-setter]
> Description set: JDKEA8,network,heap[531m],-server +UseSerialGC
> -UseCompressedOops +AggressiveOpts Email was triggered for: Failure - 1st 
> Trigger
> Failure - Any was overridden by another trigger and will not send an email. 
> Trigger
> Failure - Still was overridden by another trigger and will not send an
> email. Sending email for trigger: Failure - 1st
>

Re: [CI] Lucene 5x Linux 64 Test Only - Build # 51986 - Failure!

[Michael McCandless]

I'll commit some asserts so we can see if we are somehow passing null to
System.arraycopy here (I can't see how) vs a new JDK9 bug ...

Mike McCandless

On Fri, Jun 19, 2015 at 6:56 AM,  wrote:

>   *BUILD FAILURE*
> Build URL
> http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51986/
> Project:lucene_linux_java8_64_test_only Randomization: 
> JDKEA9,local,heap[1024m],-server
> +UseConcMarkSweepGC +UseCompressedOops +AggressiveOpts,sec manager on Date
> of build:Fri, 19 Jun 2015 12:54:09 +0200 Build duration:2 min 35 sec
>  *CHANGES* No Changes
>  *BUILD ARTIFACTS*
> checkout/lucene/build/core/test/temp/junit4-J0-20150619_125429_116.events
> 
> checkout/lucene/build/core/test/temp/junit4-J1-20150619_125429_116.events
> 
> checkout/lucene/build/core/test/temp/junit4-J2-20150619_125429_112.events
> 
> checkout/lucene/build/core/test/temp/junit4-J3-20150619_125429_116.events
> 
> checkout/lucene/build/core/test/temp/junit4-J4-20150619_125429_112.events
> 
> checkout/lucene/build/core/test/temp/junit4-J5-20150619_125429_116.events
> 
> checkout/lucene/build/core/test/temp/junit4-J6-20150619_125429_118.events
> 
> checkout/lucene/build/core/test/temp/junit4-J7-20150619_125429_119.events
> 
>  *FAILED JUNIT TESTS* Name: junit.framework Failed: 2 test(s), Passed: 0
> test(s), Skipped: 0 test(s), Total: 2 test(s)
> *Failed:
> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32 *
> *Failed:
> junit.framework.TestSuite.org.apache.lucene.search.TestNumericRangeQuery32 * 
> Name:
> org.apache.lucene.index Failed: 2 test(s), Passed: 774 test(s), Skipped: 23
> test(s), Total: 799 test(s)
> *Failed:
> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
> *
> *Failed:
> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
> *
>  *CONSOLE OUTPUT* [...truncated 1849 lines...] [junit4] -
> org.apache.lucene.index.TestIndexWriterExceptions.testExceptionFromTokenStream
>  [junit4]
> -
> org.apache.lucene.index.TestIndexWriterExceptions.testAddDocsNonAbortingException
>  [junit4]
>  [junit4]  [junit4] JVM J0: 1.02 .. 125.17 = 124.15s [junit4] JVM J1:
> 1.01 .. 124.41 = 123.39s [junit4] JVM J2: 1.33 .. 124.50 = 123.17s [junit4]
> JVM J3: 1.11 .. 122.66 = 121.55s [junit4] JVM J4: 1.24 .. 124.04 = 122.80s 
> [junit4]
> JVM J5: 1.01 .. 127.16 = 126.15s [junit4] JVM J6: 1.00 .. 133.45 = 132.45s 
> [junit4]
> JVM J7: 1.03 .. 125.12 = 124.08s [junit4] Execution time total: 2 minutes
> 13 seconds [junit4] Tests summary: 401 suites, 3227 tests, 2 suite-level
> errors, 2 errors, 48 ignored (44 assumptions) BUILD FAILED 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444:
> The following error occurred while executing this line: 
> /home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999:
> There were test failures: 401 suites, 3227 tests, 2 suite-level errors, 2
> errors, 48 ignored (44 assumptions) Total time: 2 minutes 21 seconds Build
> step 'Invoke Ant' marked build as failure Archiving artifacts Recording
> test results [description-setter] Description set:
> JDKEA9,local,heap[1024m],-server +UseConcMarkSweepGC +UseCompressedOops
> +AggressiveOpts,sec manager on Email was triggered for: Failure - 1st Trigger
> Failure - Any was overridden by another trigger and will not send an email. 
> Trigger
> Failure - Still was overridden by another trigger and will not send an
> email. Sending email for trigger: Failure - 1st
>

[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_60-ea-b12) - Build # 12944 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/12944/
Java: 64bit/jdk1.8.0_60-ea-b12 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking

Error Message:
Shard a1x2_shard1_replica1 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([9D6F18DC732EC34E:D553411C8725D2D8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:109)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(T

[CI] Lucene 5x Linux 64 Test Only - Build # 51991 - Failure!

[build]

  
  BUILD FAILURE
  
  Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/51991/
  Project:lucene_linux_java8_64_test_only

  Randomization:

JDKEA8,network,heap[531m],-server +UseSerialGC -UseCompressedOops +AggressiveOpts


  Date of build:Fri, 19 Jun 2015 13:34:56 +0200
  Build duration:2 min 48 sec





	
CHANGES
	
No Changes

  





  
BUILD ARTIFACTS

  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J0-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J1-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J2-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J3-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J4-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J5-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J6-20150619_133514_815.events
  	  
		
  	  
  	checkout/lucene/build/core/test/temp/junit4-J7-20150619_133514_816.events
  	  

  

  
  








  
FAILED JUNIT TESTS

Name: org.apache.lucene.search Failed: 1 test(s), Passed: 781 test(s), Skipped: 2 test(s), Total: 784 test(s)
   
 Failed: org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution 
   
  





CONSOLE OUTPUT

	[...truncated 1772 lines...]

	   [junit4] Tests with failures:

	   [junit4]   - org.apache.lucene.search.TestTimeLimitingCollector.testModifyResolution

	   [junit4] 

	   [junit4] 

	   [junit4] JVM J0: 1.08 ..   138.08 =   137.01s

	   [junit4] JVM J1: 0.86 ..   141.69 =   140.83s

	   [junit4] JVM J2: 1.08 ..   139.95 =   138.87s

	   [junit4] JVM J3: 0.86 ..   136.07 =   135.21s

	   [junit4] JVM J4: 1.08 ..   140.07 =   138.98s

	   [junit4] JVM J5: 0.90 ..   140.21 =   139.31s

	   [junit4] JVM J6: 0.84 ..   140.76 =   139.92s

	   [junit4] JVM J7: 0.86 ..   148.21 =   147.34s

	   [junit4] Execution time total: 2 minutes 28 seconds

	   [junit4] Tests summary: 401 suites, 3250 tests, 1 failure, 50 ignored (46 assumptions)

	

	BUILD FAILED

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:50: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1444: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:999: There were test failures: 401 suites, 3250 tests, 1 failure, 50 ignored (46 assumptions)

	

	Total time: 2 minutes 35 seconds

	Build step 'Invoke Ant' marked build as failure

	Archiving artifacts

	Recording test results

	[description-setter] Description set: JDKEA8,network,heap[531m],-server +UseSerialGC -UseCompressedOops +AggressiveOpts

	Email was triggered for: Failure - 1st

	Trigger Failure - Any was overridden by another trigger and will not send an email.

	Trigger Failure - Still was overridden by another trigger and will not send an email.

	Sending email for trigger: Failure - 1st








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

[jira] [Updated] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs

[Christoph Kaser (JIRA)]

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

Christoph Kaser updated LUCENE-6588:

External issue URL: https://github.com/apache/lucene-solr/pull/155

> ToChildBlockJoinQuery does not calculate parent score if the first child is 
> not in acceptDocs
> -
>
> Key: LUCENE-6588
> URL: https://issues.apache.org/jira/browse/LUCENE-6588
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/join
>Affects Versions: 5.2.1
>Reporter: Christoph Kaser
> Attachments: 0001-Test-score-calculation.patch, 
> 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 
> 0003-implements-ToChildBlockJoinQuery.explain.patch
>
>
> There is a bug in ToChildBlockJoinQuery that causes the score calculation to 
> be skipped if the first child of a new parent doc is not in acceptDocs.
> I will attach test showing the failure and a patch to fix it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-6588) ToChildBlockJoinQuery does not calculate parent score if the first child is not in acceptDocs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on LUCENE-6588:


GitHub user ChristophKaser opened a pull request:

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

To child block join query fixes

Pull request for LUCENE-6588

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

$ git pull https://github.com/ChristophKaser/lucene-solr 
ToChildBlockJoinQueryFixes

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

https://github.com/apache/lucene-solr/pull/155.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 #155


commit 1242d581519cb01e12a8f32eec89bfdccecad1d8
Author: ChristophKaser 
Date:   2015-06-19T11:42:54Z

Test score calculation

test whether all hits have scores when there are some deleted child
documents (LUCENE-6588)

commit eb9fc9243df085b4324e9f71e3f6d69059924be7
Author: ChristophKaser 
Date:   2015-06-19T11:53:22Z

ToChildBlockJoinQuery score calculation bugfix

Don't skip score calculation if first child is not in acceptDocs.

commit 45ed3c5674a9b6c42ad6669dc57a98eee86e000a
Author: ChristophKaser 
Date:   2015-06-19T12:03:34Z

implements ToChildBlockJoinQuery.explain()




> ToChildBlockJoinQuery does not calculate parent score if the first child is 
> not in acceptDocs
> -
>
> Key: LUCENE-6588
> URL: https://issues.apache.org/jira/browse/LUCENE-6588
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: modules/join
>Affects Versions: 5.2.1
>Reporter: Christoph Kaser
> Attachments: 0001-Test-score-calculation.patch, 
> 0002-ToChildBlockJoinQuery-score-calculation-bugfix.patch, 
> 0003-implements-ToChildBlockJoinQuery.explain.patch
>
>
> There is a bug in ToChildBlockJoinQuery that causes the score calculation to 
> be skipped if the first child of a new parent doc is not in acceptDocs.
> I will attach test showing the failure and a patch to fix it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[GitHub] lucene-solr pull request: To child block join query fixes

[ChristophKaser]

GitHub user ChristophKaser opened a pull request:

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

To child block join query fixes

Pull request for LUCENE-6588

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

$ git pull https://github.com/ChristophKaser/lucene-solr 
ToChildBlockJoinQueryFixes

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

https://github.com/apache/lucene-solr/pull/155.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 #155


commit 1242d581519cb01e12a8f32eec89bfdccecad1d8
Author: ChristophKaser 
Date:   2015-06-19T11:42:54Z

Test score calculation

test whether all hits have scores when there are some deleted child
documents (LUCENE-6588)

commit eb9fc9243df085b4324e9f71e3f6d69059924be7
Author: ChristophKaser 
Date:   2015-06-19T11:53:22Z

ToChildBlockJoinQuery score calculation bugfix

Don't skip score calculation if first child is not in acceptDocs.

commit 45ed3c5674a9b6c42ad6669dc57a98eee86e000a
Author: ChristophKaser 
Date:   2015-06-19T12:03:34Z

implements ToChildBlockJoinQuery.explain()




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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