[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+175) - Build # 56 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/56/
Java: 64bit/jdk-9-ea+175 -XX:-UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

4 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestPointFields

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

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


FAILED:  org.apache.solr.schema.TestPointFields.testDoublePointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([C97B65D346980583:E661AB85B2351927]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_131) - Build # 6734 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6734/
Java: 32bit/jdk1.8.0_131 -server -XX:+UseSerialGC

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

Error Message:
Test abandoned because suite timeout was reached.

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


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

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

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




Build Log:
[...truncated 12739 lines...]
   [junit4] Suite: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.ChaosMonkeyNothingIsSafeTest_EEFD8FCB2B22A85F-001\init-core-data-001
   [junit4]   2> 226915 WARN  
(SUITE-ChaosMonkeyNothingIsSafeTest-seed#[EEFD8FCB2B22A85F]-worker) [] 
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=12 numCloses=12
   [junit4]   2> 226915 INFO  
(SUITE-ChaosMonkeyNothingIsSafeTest-seed#[EEFD8FCB2B22A85F]-worker) [] 
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) 
w/NUMERIC_DOCVALUES_SYSPROP=false
   [junit4]   2> 226926 INFO  
(SUITE-ChaosMonkeyNothingIsSafeTest-seed#[EEFD8FCB2B22A85F]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 226926 INFO  
(SUITE-ChaosMonkeyNothingIsSafeTest-seed#[EEFD8FCB2B22A85F]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /_ec/q
   [junit4]   2> 226945 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 226947 INFO  (Thread-485) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 226947 INFO  (Thread-485) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 226950 ERROR (Thread-485) [] o.a.z.s.ZooKeeperServer 
ZKShutdownHandler is not registered, so ZooKeeper server won't take any action 
on ERROR or SHUTDOWN server state changes
   [junit4]   2> 227053 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.ZkTestServer start zk server on port:52487
   [junit4]   2> 227059 WARN  (NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0) [] 
o.a.z.s.NIOServerCnxn caught end of stream exception
   [junit4]   2> EndOfStreamException: Unable to read additional data from 
client sessionid 0x15d2fb32a04, likely client has closed socket
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:239)
   [junit4]   2>at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203)
   [junit4]   2>at java.lang.Thread.run(Thread.java:748)
   [junit4]   2> 227079 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig-tlog.xml
 to /configs/conf1/solrconfig.xml
   [junit4]   2> 227079 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\schema15.xml
 to /configs/conf1/schema.xml
   [junit4]   2> 227096 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\solrconfig.snippet.randomindexconfig.xml
 to /configs/conf1/solrconfig.snippet.randomindexconfig.xml
   [junit4]   2> 227097 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\stopwords.txt
 to /configs/conf1/stopwords.txt
   [junit4]   2> 227099 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\protwords.txt
 to /configs/conf1/protwords.txt
   [junit4]   2> 227101 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 
o.a.s.c.AbstractZkTestCase put 
C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\core\src\test-files\solr\collection1\conf\currency.xml
 to /configs/conf1/currency.xml
   [junit4]   2> 227103 INFO  
(TEST-ChaosMonkeyNothingIsSafeTest.test-seed#[EEFD8FCB2B22A85F]) [] 

[jira] [Reopened] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe reopened SOLR-10796:
---

That was quick... Failures on Policeman Jenkins 
[https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20110/] - I'll 
investigate tomorrow:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPointFields 
-Dtests.method=testDoublePointStats -Dtests.seed=CBFB848A18E90F56 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-LR 
-Dtests.timezone=America/Moncton -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.02s J1 | TestPointFields.testDoublePointStats <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CBFB848A18E90F56:E4E14ADCEC4413F2]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:564)
   [junit4]>at java.base/java.lang.Thread.run(Thread.java:844)
   [junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//*[@numFound='11']
   [junit4]>xml response was: 
   [junit4]> 
   [junit4]> 000-7974577.016774331.0222.19923-6.962364171.40650.8123826-470.86137-0.7848268-15.39769-64376.88-9715025.06774331.0301-1.1905904570462001E73.138795364109037E14-396863.48568206673265042.2061108556
   [junit4]> 
   [junit4]>request 
was:q=*:*=true=id,+number_p_d_dv=xml=number_p_d_dv
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPointFields 
-Dtests.method=testIntPointStats -Dtests.seed=CBFB848A18E90F56 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-LR 
-Dtests.timezone=America/Moncton -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.02s J1 | TestPointFields.testIntPointStats <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CBFB848A18E90F56:A07E7D81864F118F]:0)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
   [junit4]>at 
org.apache.solr.schema.TestPointFields.testIntPointStats(TestPointFields.java:278)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   [junit4]>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   [junit4]>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]>at 
java.base/java.lang.reflect.Method.invoke(Method.java:564)
   [junit4]>at java.base/java.lang.Thread.run(Thread.java:844)
   [junit4]> Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//*[@numFound='11']
   [junit4]>xml response was: 
   [junit4]> 
   [junit4]> 000-392138713935402-2255296360493294-35347795-952726269250948751780978-204796298566785-9527262.09250948.03015505165.09.98913400825957E14183505.55866042.467750296
   [junit4]> 
   [junit4]>request 
was:q=*:*=true=id,+number_p_i_dv=xml=number_p_i_dv
   [junit4]>at 
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
{noformat}

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestPointFields 
-Dtests.method=testFloatPointStats -Dtests.seed=CBFB848A18E90F56 
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en-LR 
-Dtests.timezone=America/Moncton -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR   0.01s J1 | TestPointFields.testFloatPointStats <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Exception during 
query
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CBFB848A18E90F56:71F1FCADA0F8CDB4]:0)
   [junit4]   

Re: New Jenkins build node

[Steve Rowe]

Thanks Pono!

We have a job that does the one-time node configuration that the Lucene/Solr 
jobs need.  I ran that job manually on the “lucene2” node and it looks like 
jobs are now running there.

--
Steve
www.lucidworks.com

> On Jul 10, 2017, at 11:25 PM, Daniel Pono Takamori  wrote:
> 
> Gavin had me make a ticket to provision a new build node [0].  It's
> deployed the same as lucene1-us-west [1].  Now you've got 2 nodes
> which are configured the same in puppet with one executor each with
> the same compute specs.  Please comment on the ticket if you need any
> other configuration or have any questions.
> 
> Cheers,
> -Pono
> 
> [0] - https://issues.apache.org/jira/browse/INFRA-14004
> [1] - https://builds.apache.org/computer/lucene2/


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

[jira] [Commented] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11043:
---

Cool, thanks Tomás!

TestPointFields, SimpleFacetsTest and TestIntervalFaceting each passed a couple 
times for me with your patch.

> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11043.patch
>
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "dv"),
> 18:String.format(countAssertion, field)
> 19:);
> 20:  }
> {code}
> From {{schema.xml}}:
> {code:xml}
>docValues="${solr.tests.numeric.dv}" precisionStep="0" omitNorms="true" 
> positionIncrementGap="0"/>
>docValues="true" multiValued="false"/>
> {code}



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

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

Re: Increasing ASF Jenkins bandwidth

[Steve Rowe]

Well that’s bizarre - as Pono mentioned on thread “New Jenkins build node”, we 
now have a second Jenkins node named “lucene2".  Both the “lucene" and the 
“lucene2" node are under the “lucene” label, which should cause the jobs to be 
distributed across the two nodes without any configuration changes, since all 
our jobs are tied to the “lucene” label.

Many Jenkins jobs have failed since “lucene2" came online an hour ago, because 
“ant ivy-bootstrap” hasn’t been run on “lucene2”.

On Jun 28, 2017, at 5:47 PM, Uwe Schindler  wrote:
> The second question was, if there is anything against using the other nodes 
> for running Lucene tests? My answer to that is:
> […]
> - You can easily run Lucene jobs on other nodes, just not with a 24/7 
> schedule  The only thing you have to do is: (a) invoke "ant iv-bootstrap" 
> once per node (see the manual job on our node to trigger this);

I manually started the "Lucene-Ivy-Bootstrap” job after reconfiguring it to run 
on the “lucene2” node.  Hopefully that will allow jobs to succeed there.

> (b) ideally place a lucene.build.properties file on the node's home directory 
> with node-specific config. Problem is that Lucene's automatic CPU assignment 
> can be tuned for jenkins nodes (you can use all cpus, but on the other hand 
> if a node has multiple executors, go down). As this is job-unspecific, it's 
> better to deploy that as config file on the node's home directy. The lucene 
> node has a lucene.build.properties, the same for Policeman Jenkins.

I copied the contents of /home/jenkins/lucene.build.properties from the 
“lucene” node into a shell script build task on the “Lucene-Ivy-Bootstrap” job, 
then ran the job again to populate the same file on the “lucene2” node.

So the “lucene2” node (and jobs running on it) should be good now.

--
Steve
www.lucidworks.com


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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 23 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/23/

No tests ran.

Build Log:
[...truncated 67 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:810: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1960 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 67 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:810: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[JIRA]

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

Tomás Fernández Löbbe updated SOLR-11043:
-
Attachment: SOLR-11043.patch

There is a bug in IntervalFacets (which range facets “dv” mode uses) for 
negative float values. Attaching patch with the fix. This needs more tests, but 
it passes the two Steve added.

> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
> Attachments: SOLR-11043.patch
>
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "dv"),
> 18:String.format(countAssertion, field)
> 19:);
> 20:  }
> {code}
> From {{schema.xml}}:
> {code:xml}
>docValues="${solr.tests.numeric.dv}" precisionStep="0" omitNorms="true" 
> positionIncrementGap="0"/>
>docValues="true" multiValued="false"/>
> {code}



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

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

[JENKINS] Lucene-Tests-MMAP-master - Build # 385 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Tests-MMAP-master/385/

No tests ran.

Build Log:
[...truncated 58 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Tests-MMAP-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Tests-MMAP-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 2 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/2/

No tests ran.

Build Log:
[...truncated 67 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/build.xml:810: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 22 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/22/

No tests ran.

Build Log:
[...truncated 67 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:810: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-Artifacts-7.0 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-7.0/1/

No tests ran.

Build Log:
[...truncated 87 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.0/solr/build.xml:554: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.0/solr/common-build.xml:431:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.0/lucene/common-build.xml:720:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.0/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.0/lucene/common-build.xml:459:
 Ivy is not available

Total time: 12 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
No prior successful build to compare, so performing full copy of artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Artifacts-7.0 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-7.0/1/

No tests ran.

Build Log:
[...truncated 71 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.0/lucene/common-build.xml:727:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.0/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.0/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/1/

No tests ran.

Build Log:
[...truncated 82 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/build.xml:810: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.0/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-NightlyTests-7.0 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.0/1/

No tests ran.

Build Log:
[...truncated 78 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.0/checkout/build.xml:818:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.0/checkout/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.0/checkout/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 809 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 65 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/common-build.xml:459:
 Ivy is not available

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

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

[JENKINS] Lucene-Artifacts-7.x - Build # 7 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-7.x/7/

No tests ran.

Build Log:
[...truncated 71 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/common-build.xml:727:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-7.x/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 71 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:459:
 Ivy is not available

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

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

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/6/

No tests ran.

Build Log:
[...truncated 71 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:459:
 Ivy is not available

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

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

[JENKINS] Lucene-Tests-MMAP-master - Build # 384 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Tests-MMAP-master/384/

No tests ran.

Build Log:
[...truncated 62 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Tests-MMAP-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Tests-MMAP-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-Artifacts-master - Build # 3142 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-master/3142/

No tests ran.

Build Log:
[...truncated 88 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/build.xml:554: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/solr/common-build.xml:431:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:720:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 12 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1351 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 79 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/build.xml:818:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Artifacts-master - Build # 3270 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Artifacts-master/3270/

No tests ran.

Build Log:
[...truncated 72 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:727:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Artifacts-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 6 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/6/

No tests ran.

Build Log:
[...truncated 66 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/common-build.xml:459:
 Ivy is not available

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

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

New Jenkins build node

[Daniel Pono Takamori]

Gavin had me make a ticket to provision a new build node [0].  It's
deployed the same as lucene1-us-west [1].  Now you've got 2 nodes
which are configured the same in puppet with one executor each with
the same compute specs.  Please comment on the ticket if you need any
other configuration or have any questions.

Cheers,
-Pono

[0] - https://issues.apache.org/jira/browse/INFRA-14004
[1] - https://builds.apache.org/computer/lucene2/

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

[JENKINS] Lucene-Solr-Tests-master - Build # 1959 - Still Failing

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 102 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/build.xml:810: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 6 - Failure

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 79 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/build.xml:818:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Solr-Artifacts-7.x - Build # 6 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-Artifacts-7.x/6/

No tests ran.

Build Log:
[...truncated 88 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/build.xml:554: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/solr/common-build.xml:431:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/lucene/common-build.xml:720:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Solr-Artifacts-7.x/lucene/common-build.xml:459:
 Ivy is not available

Total time: 13 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Publishing Javadoc
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS] Lucene-Solr-Tests-7.x - Build # 21 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/21/

No tests ran.

Build Log:
[...truncated 104 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/build.xml:810: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:422:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/lucene/common-build.xml:459:
 Ivy is not available

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any

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

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+175) - Build # 20110 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20110/
Java: 64bit/jdk-9-ea+175 -XX:+UseCompressedOops -XX:+UseSerialGC 
--illegal-access=deny

5 tests failed.
FAILED:  org.apache.solr.schema.TestPointFields.testDoublePointStats

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([CBFB848A18E90F56:E4E14ADCEC4413F2]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:845)
at 
org.apache.solr.schema.TestPointFields.testPointStats(TestPointFields.java:2197)
at 
org.apache.solr.schema.TestPointFields.testDoublePointStats(TestPointFields.java:689)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: java.lang.RuntimeException: REQUEST FAILED: xpath=//*[@numFound='11']
xml response was: 

[jira] [Created] (SOLR-11044) TestPullReplicaErrorHandling sometimes fails with "Could not fully remove collection"

[JIRA]

Tomás Fernández Löbbe created SOLR-11044:


 Summary: TestPullReplicaErrorHandling sometimes fails with "Could 
not fully remove collection"
 Key: SOLR-11044
 URL: https://issues.apache.org/jira/browse/SOLR-11044
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: Tests
Reporter: Tomás Fernández Löbbe
Priority: Minor


I don't have a full log, but the stacktrace:
{noformat}
Error Message:
Error from server at http://127.0.0.1:38035/solr: Could not fully remove 
collection: pull_replica_error_handling_test_cant_connect_to_pull_replica

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:38035/solr: Could not fully remove collection: 
pull_replica_error_handling_test_cant_connect_to_pull_replica
at 
__randomizedtesting.SeedInfo.seed([9B0D53E6C9EA29B6:933AB52E12445D38]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:624)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:239)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:470)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:400)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1102)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:843)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:774)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:195)
at 
org.apache.solr.cloud.TestPullReplicaErrorHandling.tearDown(TestPullReplicaErrorHandling.java:126)
at jdk.internal.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:965)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

Build Error on Fedora 25

[Michael Alcorn]

Hi all,

When trying to follow the PyLucene installation instructions on Fedora 25,
I was getting the following error:

/opt/gcc-4.9.3/bin/g++ -pthread -shared
-L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
-Wl,-rpath=/home/rdu/malcorn/.pyenv/versions/3.5.2/lib
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-L/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64/
-I/opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3/include/
build/temp.linux-x86_64-3.5/jcc3/sources/jcc.o
build/temp.linux-x86_64-3.5/jcc3/sources/JCCEnv.o
-L/home/rdu/malcorn/.pyenv/versions/3.5.2/lib -lpython3.5m -o
build/lib.linux-x86_64-3.5/libjcc3.so
-L/usr/lib/jvm/java-1.8.0/jre/lib/amd64 -ljava
-L/usr/lib/jvm/java-1.8.0/jre/lib/amd64/server -ljvm
-Wl,-rpath=/usr/lib/jvm/java-1.8.0/jre/lib/amd64:/usr/lib/jvm/java-1.8.0/jre/lib/amd64/server
-Wl,-S -lpython3.5
/usr/bin/ld: cannot find -lpython3.5

It looks like the compile command is assuming an incorrect name for the
Python 3 development library. The development libraries I have include:

libpython3.5m.so.1.0
libpython3.5m.so (linked to the above)
libpython3.so

Providing the expected name through a link, e.g.:

ln -s /path/to/.pyenv/versions/3.5.2/lib/libpython3.5m.so.1.0
/path/to/.pyenv/versions/3.5.2/lib/libpython3.5.so

fixed the issue. Everything works great after that. Thanks for the project!

-Michael

[jira] [Updated] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

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

bq. I'll commit this after beasting it for a while.

10/200 iterations failed, all on the same test: 
{{testIntPointFieldRangeFacet()}}.  I traced this to a test bug: the test 
miscalculates bucket counts because of {{int}} overflow in a calculation. 

In the attached patch I've widened the calculation to long, and none of the 10 
previously reproducing seeds reproduce any longer.

Committing shortly.

> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Created] (LUCENE-7902) Refactoring of IndexSearcher

[JIRA]

João Paulo Lemes Machado created LUCENE-7902:


 Summary: Refactoring of IndexSearcher
 Key: LUCENE-7902
 URL: https://issues.apache.org/jira/browse/LUCENE-7902
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: João Paulo Lemes Machado


Hello everyone.
I was analyzing the modularization of some classes, and I identified that the 
class IndexSearcher  has an opportunity for cohesion improvement. 
The class IndexWriter was in the same situation and the problem was solved as 
follows: The IndexWriterConfig class was created, and several get() and set() 
methods that were used only to configure the class parameters were moved from 
IndexWriter to IndexWriterConfig. 
The new class was then accessed through an instance variable in IndexWriter. 
This strategy has cleaned and improved IndexWriter cohesion.
With this in mind, I would recommend creating a new class: IndexSearcherConfig 
, and moving the following methods:
setDefaultQueryCachingPolicy
getDefaultQueryCachingPolicy
getQueryCachingPolicy
setQueryCachingPolicy
setQueryCache
getQueryCache
setDefaultQueryCache
getDefaultQueryCache
setSimilarity
getSimilarity
from the IndexSearcher.
Those parameters accessed by an instance variable in the IndexSearcher.
Moreover, the orthogonality is the design would be enhanced.

What do you think about that?



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

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/28/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:190)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:446)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1258)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:532)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:517)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:347)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:266)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:216)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:990)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1206)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:752)
  at 
org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:474)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:74)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:91)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:188)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:144)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:311) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:130)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:276) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:178)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:195)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:108)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 

[jira] [Resolved] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10796.
---
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)
   7.0

Committed.

I didn't backport to branch_6x, because there were conflicts in the test suite 
- apparently other changes in this test on 7.0+ haven't been backported.

> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: TestPointFields: increase randomized testing of non-trivial values


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


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

SOLR-10796: TestPointFields: increase randomized testing of non-trivial values


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10796:


Commit 0511aeb5137c81cf4966f691d27b8c74bda04e20 in lucene-solr's branch 
refs/heads/branch_7_0 from [~steve_rowe]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0511aeb ]

SOLR-10796: TestPointFields: increase randomized testing of non-trivial values


> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Updated] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10796:
--
Description: A lot of TestPointFields code just uses positive nums, or only 
ranodmizes values between -100 and 100, etc.  (was: A lot of TestPointsField 
code just uses positive nums, or only ranodmizes values between -100 and 100, 
etc.)

> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointFields code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Updated] (SOLR-10887) Add .xml extension to managed-schema

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-10887:

 Priority: Major  (was: Blocker)
Fix Version/s: (was: 7.0)

> Add .xml extension to managed-schema
> 
>
> Key: SOLR-10887
> URL: https://issues.apache.org/jira/browse/SOLR-10887
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>
> Discussions here SOLR-10574.
> There is consensus to renaming managed-schema back to managed-schema.xml. 
> Requires backcompat handling as mentioned in Yonik's comment:
> {code}
> there is back compat to consider. I'd also prefer that if it get changed, we 
> first look for "managed-schema.xml", then "managed-schema", and then 
> "schema.xml" to preserve back compat.
> {code}



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

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

[jira] [Updated] (SOLR-6630) Deprecate the "implicit" router and rename to "manual"

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-6630:
---
Attachment: SOLR-6630.patch

Here's a WIP patch for renaming "implicit" to "manual". TODO: add deprecation 
comments and warnings and handle backcompat for "implicit".

> Deprecate the "implicit" router and rename to "manual"
> --
>
> Key: SOLR-6630
> URL: https://issues.apache.org/jira/browse/SOLR-6630
> Project: Solr
>  Issue Type: Task
>  Components: SolrCloud
>Reporter: Shawn Heisey
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-6630.patch, SOLR-6630.patch
>
>
> I had this exchange with an IRC user named "kindkid" this morning:
> {noformat}
> 08:30 < kindkid> I'm using sharding with the implicit router, but I'm seeing
>  all my documents end up on just one of my 24 shards. What
>  might be causing this? (4.10.0)
> 08:35 <@elyograg> kindkid: you used the implicit router.  that means that
>   documents will be indexed on the shard you sent them
> to, not
>   routed elsewhere.
> 08:37 < kindkid> oh. wow. not sure where I got the idea, but I was under the
>  impression that implicit router would use a hash of the
>  uniqueKey modulo number of shards to pick a shard.
> 08:38 <@elyograg> I think you probably wanted the compositeId router.
> 08:39 <@elyograg> implicit is not a very good name.  It's technically
> correct,
>   but the meaning of the word is not well known.
> 08:39 <@elyograg> "manual" would be a better name.
> {noformat}
> The word "implicit" has a very specific meaning, and I think it's
> absolutely correct terminology for what it does, but I don't think that
> it's very clear to a typical person.  This is not the first time I've
> encountered the confusion.
> Could we deprecate the implicit name and use something much more
> descriptive and easily understood, like "manual" instead?  Let's go
> ahead and accept implicit in 5.x releases, but issue a warning in the
> log.  Maybe we can have a startup system property or a config option
> that will force the name to be updated in zookeeper and get rid of the
> warning.  If we do this, my bias is to have an upgrade to 6.x force the
> name change in zookeeper.



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

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

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit fd0e520d4e7bc9871ffaf6aa7dc86e3d621c97b5 in lucene-solr's branch 
refs/heads/branch_7_0 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd0e520 ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs

(cherry picked from commit 20153595a4248c34784b0892d83e58ae259c94f0)


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit 95d4a7f3a2adad25d89abac8a5c650949ac7459f in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95d4a7f ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs

(cherry picked from commit 20153595a4248c34784b0892d83e58ae259c94f0)


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Updated] (SOLR-10796) TestPointsField: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

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

Patch with the failing test annotated with {{@AwaitsFix(bugUrl = 
"https://issues.apache.org/jira/browse/SOLR-11043;)}}.

I'll commit this after beasting it for a while.

> TestPointsField: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointsField code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Updated] (SOLR-10796) TestPointFields: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-10796:
--
Summary: TestPointFields: increase randomized testing of non-trivial values 
  (was: TestPointsField: increase randomized testing of non-trivial values )

> TestPointFields: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch, SOLR-10796.patch
>
>
> A lot of TestPointsField code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-9-ea+175) - Build # 54 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/54/
Java: 64bit/jdk-9-ea+175 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([9A1AC686ED36A325:63575529D143EEAF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:279)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-10796) TestPointsField: increase randomized testing of non-trivial values

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10796:
---

bq. There is one nocommit: testFloatPointFieldRangeFacet() fails on a 
docValues="true" field with facet.range.method=dv, but not with the default 
method using the exact same documents and query. None of the other 
test{Double,Long,Int}PointFieldRangeFacet() tests fail in this way. I'll 
investigate more next week.

I filed SOLR-11043 for this.  It's reproducible with Trie fields as well as 
point fields.

> TestPointsField: increase randomized testing of non-trivial values 
> ---
>
> Key: SOLR-10796
> URL: https://issues.apache.org/jira/browse/SOLR-10796
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Steve Rowe
> Attachments: SOLR-10796.patch
>
>
> A lot of TestPointsField code just uses positive nums, or only ranodmizes 
> values between -100 and 100, etc.



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

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

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit fd0e520d4e7bc9871ffaf6aa7dc86e3d621c97b5 in lucene-solr's branch 
refs/heads/branch_7_0 from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fd0e520 ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs

(cherry picked from commit 20153595a4248c34784b0892d83e58ae259c94f0)


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Resolved] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[Hoss Man (JIRA)]

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

Hoss Man resolved SOLR-10898.
-
   Resolution: Fixed
 Assignee: Hoss Man
Fix Version/s: 7.1
   master (8.0)
   7.0

> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit 95d4a7f3a2adad25d89abac8a5c650949ac7459f in lucene-solr's branch 
refs/heads/branch_7x from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95d4a7f ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs

(cherry picked from commit 20153595a4248c34784b0892d83e58ae259c94f0)


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11043:
--
Description: 
Found while increasing TestPointsField randomization on SOLR-10796:

When a non-multiValued float field, either Trie- or points-based, has docvalues 
and a facet.range request uses {{facet.range.method=dv}}, negative values are 
not included in the facet range counts.

This test added to SimpleFacetsTest succeeds for the request with 
{{facet.range.method=filter}}, but fails for the same request with 
{{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
the schema excerpt below for field/type:

{code:java}
 1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
 2:String field = "negative_num_f1_dv";
 3:assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
 4:
 5:final String[] commonParams = { 
 6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
"facet.range.end", "0", "facet.range.gap", "2"
 7:};
 8:final String countAssertion
 9:= 
"//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
10:
11:assertU(adoc("id", "10001", field, "-1.0"));
12:assertU(commit());
13:
14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"filter"),
15:String.format(countAssertion, field)
16:);
17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"dv"),
18:String.format(countAssertion, field)
19:);
20:  }
{code}

>From {{schema.xml}}:

{code:xml}
  
  
{code}


  was:
Found while increasing TestPointsField randomization on SOLR-10796:

When a non-multiValued float field, either Trie- or points-based, has docvalues 
and a facet.range request uses {{facet.range.method=dv}}, negative values are 
not included in the facet range counts.

This test added to SimpleFacetsTest succeeds for the request with 
{{facet.range.method=filter}}, but fails for the same request with 
{{facet.range.method=dv}} (failure is on line 17 in the listing below):

{code:java}
 1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
 2:String field = "negative_num_f1_dv";
 3:assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
 4:
 5:final String[] commonParams = { 
 6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
"facet.range.end", "0", "facet.range.gap", "2"
 7:};
 8:final String countAssertion
 9:= 
"//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
10:
11:assertU(adoc("id", "10001", field, "-1.0"));
12:assertU(commit());
13:
14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"filter"),
15:String.format(countAssertion, field)
16:);
17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"dv"),
18:String.format(countAssertion, field)
19:);
20:  }
{code}


> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below) - see 
> the schema excerpt below for field/type:
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit 20153595a4248c34784b0892d83e58ae259c94f0 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2015359 ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Updated] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-11043:
--
Description: 
Found while increasing TestPointsField randomization on SOLR-10796:

When a non-multiValued float field, either Trie- or points-based, has docvalues 
and a facet.range request uses {{facet.range.method=dv}}, negative values are 
not included in the facet range counts.

This test added to SimpleFacetsTest succeeds for the request with 
{{facet.range.method=filter}}, but fails for the same request with 
{{facet.range.method=dv}} (failure is on line 17 in the listing below):

{code:java}
 1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
 2:String field = "negative_num_f1_dv";
 3:assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
 4:
 5:final String[] commonParams = { 
 6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
"facet.range.end", "0", "facet.range.gap", "2"
 7:};
 8:final String countAssertion
 9:= 
"//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
10:
11:assertU(adoc("id", "10001", field, "-1.0"));
12:assertU(commit());
13:
14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"filter"),
15:String.format(countAssertion, field)
16:);
17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"dv"),
18:String.format(countAssertion, field)
19:);
20:  }
{code}

  was:
Found while increasing TestPointsField randomization on SOLR-10796:

When a non-multiValued float field, either Trie- or points-based, has docvalues 
and a facet.range request specified {{facet.range.method=dv}}, negative values 
are not included in the facet range counts.

This test added to SimpleFacetsTest succeeds for the request with 
{{facet.range.method=filter}}, but fails for the same request with 
{{facet.range.method=dv}} (failure is on line 17 in the listing below):

{code:java}
 1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
 2:String field = "negative_num_f1_dv";
 3:assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
 4:
 5:final String[] commonParams = { 
 6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
"facet.range.end", "0", "facet.range.gap", "2"
 7:};
 8:final String countAssertion
 9:= 
"//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
10:
11:assertU(adoc("id", "10001", field, "-1.0"));
12:assertU(commit());
13:
14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"filter"),
15:String.format(countAssertion, field)
16:);
17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"dv"),
18:String.format(countAssertion, field)
19:);
20:  }
{code}


> Negative single-valued float field values are not included in facet range 
> counts when the field has docvalues and facet.range.method=dv
> ---
>
> Key: SOLR-11043
> URL: https://issues.apache.org/jira/browse/SOLR-11043
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>
> Found while increasing TestPointsField randomization on SOLR-10796:
> When a non-multiValued float field, either Trie- or points-based, has 
> docvalues and a facet.range request uses {{facet.range.method=dv}}, negative 
> values are not included in the facet range counts.
> This test added to SimpleFacetsTest succeeds for the request with 
> {{facet.range.method=filter}}, but fails for the same request with 
> {{facet.range.method=dv}} (failure is on line 17 in the listing below):
> {code:java}
>  1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
>  2:String field = "negative_num_f1_dv";
>  3:
> assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
>  4:
>  5:final String[] commonParams = { 
>  6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
> "facet.range.end", "0", "facet.range.gap", "2"
>  7:};
>  8:final String countAssertion
>  9:= 
> "//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
> 10:
> 11:assertU(adoc("id", "10001", field, "-1.0"));
> 12:assertU(commit());
> 13:
> 14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> "filter"),
> 15:String.format(countAssertion, field)
> 16:);
> 17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
> 

[jira] [Commented] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10898:


Commit 20153595a4248c34784b0892d83e58ae259c94f0 in lucene-solr's branch 
refs/heads/master from Chris Hostetter
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2015359 ]

SOLR-10898: Fix SOLR-10898 to not deterministicly fail 1/512 runs


> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Created] (SOLR-11043) Negative single-valued float field values are not included in facet range counts when the field has docvalues and facet.range.method=dv

[Steve Rowe (JIRA)]

Steve Rowe created SOLR-11043:
-

 Summary: Negative single-valued float field values are not 
included in facet range counts when the field has docvalues and 
facet.range.method=dv
 Key: SOLR-11043
 URL: https://issues.apache.org/jira/browse/SOLR-11043
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Steve Rowe


Found while increasing TestPointsField randomization on SOLR-10796:

When a non-multiValued float field, either Trie- or points-based, has docvalues 
and a facet.range request specified {{facet.range.method=dv}}, negative values 
are not included in the facet range counts.

This test added to SimpleFacetsTest succeeds for the request with 
{{facet.range.method=filter}}, but fails for the same request with 
{{facet.range.method=dv}} (failure is on line 17 in the listing below):

{code:java}
 1:  public void testDvMethodNegativeFloatRangeFacet() throws Exception {
 2:String field = "negative_num_f1_dv";
 3:assertTrue(h.getCore().getLatestSchema().getField(field).hasDocValues());
 4:
 5:final String[] commonParams = { 
 6:"q", "*:*", "facet", "true", "facet.range.start", "-2", 
"facet.range.end", "0", "facet.range.gap", "2"
 7:};
 8:final String countAssertion
 9:= 
"//lst[@name='facet_counts']/lst[@name='facet_ranges']/lst[@name='%s']/lst[@name='counts']/int[@name='-2.0'][.='1']";
10:
11:assertU(adoc("id", "10001", field, "-1.0"));
12:assertU(commit());
13:
14:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"filter"),
15:String.format(countAssertion, field)
16:);
17:assertQ(req(commonParams, "facet.range", field, "facet.range.method", 
"dv"),
18:String.format(countAssertion, field)
19:);
20:  }
{code}



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

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

[jira] [Commented] (SOLR-10263) Different SpellcheckComponents should have their own suggestMode

[James Dyer (JIRA)]

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

James Dyer commented on SOLR-10263:
---

[~asingh2411] , Have you tried using the two parameters, 
"spellcheck.alternativeTermCount" and "spellcheck.maxCollationTries" to solve 
your problem?  The first parameter will tell it to offer some suggestions even 
when a term is in the index.  The second parameter will query the suggestion 
combinations against the index internally, to find corrections that return 
results.

This way even if "gold" and "mine" are valid terms in your index, specifying 
"alternativeTermCount" will suggest up to your specified number of alternatives 
for each of these.  Then, by specifying "maxCollationTries", it will try up to 
your specified number of combinations until it finds valid results.

Using the existing features like this might be a better solution than to add 
the level of complexity to the component that you are suggesting here.

> Different SpellcheckComponents should have their own suggestMode
> 
>
> Key: SOLR-10263
> URL: https://issues.apache.org/jira/browse/SOLR-10263
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spellchecker
>Reporter: Abhishek Kumar Singh
>Priority: Minor
> Attachments: SOLR-10263.v2.patch
>
>
> As of now, common spellcheck options are applied to all the 
> SpellCheckComponents.
> This can create problem in the following case:-
>  It may be the case that we want *DirectSolrSpellChecker* to ALWAYS_SUGGEST 
> spellcheck suggestions. 
> But we may want *WordBreakSpellChecker* to suggest only if the token is not 
> in the index  (for relevance or performance reasons)  
> (SUGGEST_WHEN_NOT_IN_INDEX) . 
> *UPDATE : * Recently, we also figured out that, for 
> {{WordBreakSolrSpellChecker}} also, both - The {{WordBreak}} and {{WordJoin}} 
> should also have different suggestModes.
> We faced this problem in our case, wherein, Most of the WordJoin cases are 
> those where the words individually are valid tokens, but what the users are 
> looking for is actually a  combination (wordjoin) of the two tokens. 
> For example:-
> *gold mine sunglasses* : Here, both *gold* and *mine* are valid tokens. But 
> the actual product being looked for is *goldmine sunglasses* , where 
> *goldmine* is a brand.
> In such cases, we should recommend {{didYouMean:goldmine sunglasses}} . But 
> this wont be possible because we had set   {{SUGGEST_WHEN_NOT_IN_INDEX}}  for 
> {{WordBreakSolrSpellChecker}} (of which, WordJoin is a part)  . 
> For this, we should have separate suggestModes for both `wordJoin` as well as 
> `wordBreak`. 
> Related changes have been done at Latest PR. : 
> https://github.com/apache/lucene-solr/pull/218. 



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

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

[jira] [Resolved] (SOLR-11015) SocketTimeoutException in ChaosMonkey tests when creating testcollection

[JIRA]

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

Tomás Fernández Löbbe resolved SOLR-11015.
--
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)
   7.0

Haven't seen this particular failure in Jenkins since this was committed. 
Resolving

> SocketTimeoutException in ChaosMonkey tests when creating testcollection
> 
>
> Key: SOLR-11015
> URL: https://issues.apache.org/jira/browse/SOLR-11015
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Tests
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Minor
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-11015.patch
>
>
> I've seen this a couple of times already. Always at the "create collection" 
> operation that all ChaosMonkey tests do at the end of the test to check admin 
> operations continue to work.



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:


Stack Trace:
java.lang.AssertionError
at 
__randomizedtesting.SeedInfo.seed([2ABE96A2A8440E7A:F2F3BBF55F99ABDA]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.junit.Assert.assertNotNull(Assert.java:537)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:116)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
 

[jira] [Resolved] (SOLR-10568) Automate HTML builds via Jenkins to occur with each commit

[Cassandra Targett (JIRA)]

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

Cassandra Targett resolved SOLR-10568.
--
Resolution: Fixed
  Assignee: Steve Rowe

I think we're done with this. Set the assignee to Steve since he did all the 
work :)

> Automate HTML builds via Jenkins to occur with each commit
> --
>
> Key: SOLR-10568
> URL: https://issues.apache.org/jira/browse/SOLR-10568
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Steve Rowe
>Priority: Minor
>
> Spin-off from SOLR-10295.
> The idea is to use a mechanism (possibly gitpubsub and/or svnpubsub?) so 
> Jenkins builds of HTML format of the Ref Guide occur as soon as commits are 
> made to any non-released branch.
> This would allow any committer to see doc changes ASAP after a commit to 
> verify the presentation of the information is as expected.



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

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

Re: Fix versions

[Anshum Gupta]

Makes sense, as long as we don’t treat it as ‘optional’ in the literal sense. 
We should try and put in some affected version there for the bug fixes as this 
entry certainly doesn’t make sense for anything other than the bugs.

-Anshum



> On Jul 10, 2017, at 12:48 PM, David Smiley  wrote:
> 
> RE Affected Versions.  "All ..." seems wrong. to clarify, this is an optional 
> entry and shouldn't imply an exhaustive list.  The submitter and anyone 
> helping can put the known version (bug experienced in version X for sure) 
> and/or perhaps the earliest known/believed.
> 
> On Mon, Jul 10, 2017 at 1:58 PM Anshum Gupta  > wrote:
> As long as all of us agree, and try to use the same system, I think we'll be 
> fine.
> 
> I think there's a reasonable consensus on the following understanding of 
> "fixVersion/s", and "Affected Versions"
> - fixVersion: All branches that the code was committed. Example, assuming 
> that the last released version was x.y.z:
>   - If the code was committed to master: master (x + 1.0)
>   - If the code was committed to the current stable branch (branch_ax), x.y + 
> 1
>   - If the code was committed to a release branch  - the next release version 
> from that branch. There would be one entry for each of the release branches 
> that this fix is committed to.
>   
> - Affected Versions: All affected git tags (released versions of Lucene/Solr).
> 
> If there are no objections by tomorrow morning (24 hours), I'll change the 
> wiki page to reflect this, and it would be great if we could all just follow 
> this convention.
> 
> -Anshum
> 
> 
> 
>> On Jul 6, 2017, at 2:40 AM, Dawid Weiss > > wrote:
>> 
>>> But for new features, it is different. The CHANGES entry is only added to
>>> the first version the feature was introduced (e.g. 7.0.0), even if the
>>> feature is committed to master, branch_7x, branch_7_0. In my head it would
>>> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
>> 
>> I don't think it's that much different, really.
>> 
>> If you introduce a feature on branch_7x and apply it to master then
>> it's both on branch_7x and master. Let's say somebody then cuts out
>> branch_8x from master and creates a release of version 8.0. Then that
>> somebody should tag patches on current master with branch_8x and 8.0
>> (assuming he's immediately going for the release). And then you'd see
>> this on your feature issue's fix-for:
>> 
>> branch_7x, branch_8x, 8.0, master
>> 
>> and since branch_7x hasn't been released yet, the feature would be
>> introduced in version 8.0, not any tagged version on 7x (because they
>> haven't been released yet). You could either rollback that feature
>> from branch_7x (and remove the tag), or keep it and release that
>> feature from both branches (next version of 7x). Or never release
>> branch_7x at all, but keep the patch there anyway.
>> 
>> Sure, this is a bit abnormal to have the same new "feature" on two
>> different branches, but you can apply the same thinking to bugfix
>> versions as well (features or any kind of patch). This is something
>> Hoss mentioned -- when you're doing multiple parallel releases of
>> versions from different branches it becomes a headache quickly to
>> figure out which version carries a certain patch (whether it's a bug,
>> feature or whatever else). But in reality it is often the case (in my
>> personal experience) that multiple versions do carry the same set of
>> patches, be it bug fixes, refactorings or even new features and those
>> tags in jira help to figure out where a given patch exists.
>> 
>> Dawid
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
> 
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley 
>  | Book: 
> http://www.solrenterprisesearchserver.com 
> 

[jira] [Commented] (SOLR-11032) Update solrj tutorial

[JIRA]

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

Jan Høydahl commented on SOLR-11032:


Yes, it's easier for us to maintain a sub directory in solr's git, so perhaps 
start with that. The ref guide can instruct to clone lucene-solr and then cd 
into solr/example/solrj or something

> Update solrj tutorial
> -
>
> Key: SOLR-11032
> URL: https://issues.apache.org/jira/browse/SOLR-11032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ, website
>Reporter: Karl Richter
>
> The [solrj tutorial](https://wiki.apache.org/solr/Solrj) has the following 
> issues:
>   * It refers to 1.4.0 whereas the current release is 6.x, some classes are 
> deprecated or no longer exist.
>   * Document-object-binding is a crucial feature [which should be working in 
> the meantime](https://issues.apache.org/jira/browse/SOLR-1945) and thus 
> should be covered in the tutorial.



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

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

Re: Fix versions

[David Smiley]

RE *Affected Versions*.  "All ..." seems wrong. to clarify, this is an
optional entry and shouldn't imply an exhaustive list.  The submitter and
anyone helping can put the known version (bug experienced in version X for
sure) and/or perhaps the earliest known/believed.

On Mon, Jul 10, 2017 at 1:58 PM Anshum Gupta  wrote:

> As long as all of us agree, and try to use the same system, I think we'll
> be fine.
>
> I think there's a reasonable consensus on the following understanding of
> "fixVersion/s", and "Affected Versions"
> - *fixVersion*: All branches that the code was committed. Example,
> assuming that the last released version was x.y.z:
>   - If the code was committed to master: master (x + 1.0)
>   - If the code was committed to the current stable branch (branch_ax),
> x.y + 1
>   - If the code was committed to a release branch  - the next release
> version from that branch. There would be one entry for each of the release
> branches that this fix is committed to.
>
> - *Affected Versions*: All affected git tags (released versions of
> Lucene/Solr).
>
> If there are no objections by *tomorrow morning (24 hours)*, I'll change
> the wiki page to reflect this, and it would be great if we could all just
> follow this convention.
>
> -Anshum
>
>
>
> On Jul 6, 2017, at 2:40 AM, Dawid Weiss  wrote:
>
> But for new features, it is different. The CHANGES entry is only added to
> the first version the feature was introduced (e.g. 7.0.0), even if the
> feature is committed to master, branch_7x, branch_7_0. In my head it would
> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
>
>
> I don't think it's that much different, really.
>
> If you introduce a feature on branch_7x and apply it to master then
> it's both on branch_7x and master. Let's say somebody then cuts out
> branch_8x from master and creates a release of version 8.0. Then that
> somebody should tag patches on current master with branch_8x and 8.0
> (assuming he's immediately going for the release). And then you'd see
> this on your feature issue's fix-for:
>
> branch_7x, branch_8x, 8.0, master
>
> and since branch_7x hasn't been released yet, the feature would be
> introduced in version 8.0, not any tagged version on 7x (because they
> haven't been released yet). You could either rollback that feature
> from branch_7x (and remove the tag), or keep it and release that
> feature from both branches (next version of 7x). Or never release
> branch_7x at all, but keep the patch there anyway.
>
> Sure, this is a bit abnormal to have the same new "feature" on two
> different branches, but you can apply the same thinking to bugfix
> versions as well (features or any kind of patch). This is something
> Hoss mentioned -- when you're doing multiple parallel releases of
> versions from different branches it becomes a headache quickly to
> figure out which version carries a certain patch (whether it's a bug,
> feature or whatever else). But in reality it is often the case (in my
> personal experience) that multiple versions do carry the same set of
> patches, be it bug fixes, refactorings or even new features and those
> tags in jira help to figure out where a given patch exists.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10892:


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

SOLR-10892: change from tables for params; change heading levels so lookup and 
dictionary impls aren't buried


> Ref Guide: Move parameters out of tables
> 
>
> Key: SOLR-10892
> URL: https://issues.apache.org/jira/browse/SOLR-10892
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> We've overused a bit the concept of using tables to explain various config 
> parameters. We have some tables that are massive and try to cram a ton of 
> complex information into a row (see function-queries.adoc), while other 
> tables are only 1 or 2 rows. It's not impossible, but it's also difficult to 
> link directly to parameters when they are in a table
> AsciiDoc format now allows us to use "description lists" or "definition 
> lists" which in many cases might be better. This issue would change many of 
> the current tables to definition lists. However, some of them may remain, 
> depending on how they work within the content.



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

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

[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10892:


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

SOLR-10892: change from tables for params; change heading levels so lookup and 
dictionary impls aren't buried


> Ref Guide: Move parameters out of tables
> 
>
> Key: SOLR-10892
> URL: https://issues.apache.org/jira/browse/SOLR-10892
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> We've overused a bit the concept of using tables to explain various config 
> parameters. We have some tables that are massive and try to cram a ton of 
> complex information into a row (see function-queries.adoc), while other 
> tables are only 1 or 2 rows. It's not impossible, but it's also difficult to 
> link directly to parameters when they are in a table
> AsciiDoc format now allows us to use "description lists" or "definition 
> lists" which in many cases might be better. This issue would change many of 
> the current tables to definition lists. However, some of them may remain, 
> depending on how they work within the content.



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

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

[jira] [Commented] (SOLR-10892) Ref Guide: Move parameters out of tables

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10892:


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

SOLR-10892: change from tables for params; change heading levels so lookup and 
dictionary impls aren't buried


> Ref Guide: Move parameters out of tables
> 
>
> Key: SOLR-10892
> URL: https://issues.apache.org/jira/browse/SOLR-10892
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
> Fix For: 7.0
>
>
> We've overused a bit the concept of using tables to explain various config 
> parameters. We have some tables that are massive and try to cram a ton of 
> complex information into a row (see function-queries.adoc), while other 
> tables are only 1 or 2 rows. It's not impossible, but it's also difficult to 
> link directly to parameters when they are in a table
> AsciiDoc format now allows us to use "description lists" or "definition 
> lists" which in many cases might be better. This issue would change many of 
> the current tables to definition lists. However, some of them may remain, 
> depending on how they work within the content.



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

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

[jira] [Commented] (SOLR-11032) Update solrj tutorial

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-11032:
--

bq. Can't it be both?

Yes, it could be both.

If you decide to make a 2nd github repo, and you write your README and any 
other docs in AsciiDoc format, it would be easily possible to pull sections of 
it into the Ref Guide as intro or basic materials, and point users to the repo 
for more details. We could even pull in snippets of example code as necessary 
(and annotate it).

Or, instead of a separate repo, maybe we should find a way to add the examples 
to Solr's source itself? Then they can be tested and updated as changes occur 
in Solr.

Either way, I've long wished someone would beef up the Solr Ref Guide's SolrJ 
coverage - whether it's in Solr's repo or another one, I hope some progress can 
be made.

> Update solrj tutorial
> -
>
> Key: SOLR-11032
> URL: https://issues.apache.org/jira/browse/SOLR-11032
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, SolrJ, website
>Reporter: Karl Richter
>
> The [solrj tutorial](https://wiki.apache.org/solr/Solrj) has the following 
> issues:
>   * It refers to 1.4.0 whereas the current release is 6.x, some classes are 
> deprecated or no longer exist.
>   * Document-object-binding is a crucial feature [which should be working in 
> the meantime](https://issues.apache.org/jira/browse/SOLR-1945) and thus 
> should be covered in the tutorial.



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

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

[jira] [Commented] (SOLR-10887) Add .xml extension to managed-schema

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-10887:
-

[~ichattopadhyaya] , I don't see this as a blocker for 7.0. Let us get this 
done as part of the next release.

> Add .xml extension to managed-schema
> 
>
> Key: SOLR-10887
> URL: https://issues.apache.org/jira/browse/SOLR-10887
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
>
> Discussions here SOLR-10574.
> There is consensus to renaming managed-schema back to managed-schema.xml. 
> Requires backcompat handling as mentioned in Yonik's comment:
> {code}
> there is back compat to consider. I'd also prefer that if it get changed, we 
> first look for "managed-schema.xml", then "managed-schema", and then 
> "schema.xml" to preserve back compat.
> {code}



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

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

[jira] [Updated] (SOLR-10898) TestRandomRequestDistribution.testRequestTracking is terrible and should be removed

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-10898:

Attachment: SOLR-10898.patch

Here's a patch that keeps the test around, but reworks it so it instead of a 
fixed number of requests, it executes them in a loop until each of the (2) 
replicas has received at least one request -- or until a total of 1000 requests 
have been made, at which point the assertion failure message is clear that the 
problem could just be a *very* unlucky seed.

> TestRandomRequestDistribution.testRequestTracking is terrible and should be 
> removed
> ---
>
> Key: SOLR-10898
> URL: https://issues.apache.org/jira/browse/SOLR-10898
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10898.patch
>
>
> TestRandomRequestDistribution.testRequestTracking() is a badly written test 
> that tries to assert that if 10 requests are sent to a shard has 2 replicas, 
> at least 1 of those requests must be routed to each replica.  
> This is essentially a test that says "flip a coin 10 times, fail if all 10 
> are heads *OR* if all 10 are tails"
> Statistically speaking 2 out of every 1024 runs of this test (1/512) should 
> fail.



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

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

[jira] [Closed] (SOLR-11040) CdcrBootstrapTest failing on 'master' branch

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar closed SOLR-11040.
---
Resolution: Invalid

> CdcrBootstrapTest failing on 'master' branch
> 
>
> Key: SOLR-11040
> URL: https://issues.apache.org/jira/browse/SOLR-11040
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 6.6
>Reporter: Amrit Sarkar
>Priority: Critical
> Attachments: cdcr-bs-test-error
>
>
> {{CdcrBootstrapTest}} is constantly failing for all seeds on master branch 
> both in terminal and IDE.
> {code}
> 86599 ERROR (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:54919_solr 
> x:cdcr-target_shard1_replica_n1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:54919_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica_n1] o.a.s.h.ReplicationHandler Index fetch 
> failed :org.apache.solr.common.SolrException: Index fetch failed : 
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:655)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:332)
> at 
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:757)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:712)
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.solr.handler.IndexFetcher.openNewSearcherAndUpdateCommitPoint(IndexFetcher.java:888)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:632)
> ... 10 more
> {code}
> Attached detailed logs: 



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

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

[jira] [Commented] (SOLR-11040) CdcrBootstrapTest failing on 'master' branch

[Amrit Sarkar (JIRA)]

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

Amrit Sarkar commented on SOLR-11040:
-

Yeah. [~ichattopadhyaya] [~varunthacker], I did `ant clean` at top level, git 
clone fresh code, blew up the ivy cache. No luck. I will close this JIRA as it 
is looking like machine specific issue. Thank you for looking into it.

> CdcrBootstrapTest failing on 'master' branch
> 
>
> Key: SOLR-11040
> URL: https://issues.apache.org/jira/browse/SOLR-11040
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 6.6
>Reporter: Amrit Sarkar
>Priority: Critical
> Attachments: cdcr-bs-test-error
>
>
> {{CdcrBootstrapTest}} is constantly failing for all seeds on master branch 
> both in terminal and IDE.
> {code}
> 86599 ERROR (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:54919_solr 
> x:cdcr-target_shard1_replica_n1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:54919_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica_n1] o.a.s.h.ReplicationHandler Index fetch 
> failed :org.apache.solr.common.SolrException: Index fetch failed : 
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:655)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:332)
> at 
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:757)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:712)
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.solr.handler.IndexFetcher.openNewSearcherAndUpdateCommitPoint(IndexFetcher.java:888)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:632)
> ... 10 more
> {code}
> Attached detailed logs: 



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

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

[jira] [Commented] (SOLR-11040) CdcrBootstrapTest failing on 'master' branch

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-11040:
--

{{ant test  -Dtestcase=CdcrBootstrapTest 
-Dtests.method=testBootstrapWithSourceCluster -Dtests.seed=60B85B48254FC2A9 
-Dtests.slow=true -Dtests.locale=da-DK -Dtests.timezone=America/Inuvik 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCI}} didn't reproduce for me 
either

> CdcrBootstrapTest failing on 'master' branch
> 
>
> Key: SOLR-11040
> URL: https://issues.apache.org/jira/browse/SOLR-11040
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: CDCR
>Affects Versions: 6.6
>Reporter: Amrit Sarkar
>Priority: Critical
> Attachments: cdcr-bs-test-error
>
>
> {{CdcrBootstrapTest}} is constantly failing for all seeds on master branch 
> both in terminal and IDE.
> {code}
> 86599 ERROR (recoveryExecutor-6-thread-1-processing-n:127.0.0.1:54919_solr 
> x:cdcr-target_shard1_replica_n1 s:shard1 c:cdcr-target r:core_node1) 
> [n:127.0.0.1:54919_solr c:cdcr-target s:shard1 r:core_node1 
> x:cdcr-target_shard1_replica_n1] o.a.s.h.ReplicationHandler Index fetch 
> failed :org.apache.solr.common.SolrException: Index fetch failed : 
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:655)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:332)
> at 
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:419)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:757)
> at 
> org.apache.solr.handler.CdcrRequestHandler$BootstrapCallable.call(CdcrRequestHandler.java:712)
> at 
> com.codahale.metrics.InstrumentedExecutorService$InstrumentedCallable.call(InstrumentedExecutorService.java:197)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.solr.handler.IndexFetcher.openNewSearcherAndUpdateCommitPoint(IndexFetcher.java:888)
> at 
> org.apache.solr.handler.IndexFetcher.fetchLatestIndex(IndexFetcher.java:632)
> ... 10 more
> {code}
> Attached detailed logs: 



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

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

Re: Fix versions

[Anshum Gupta]

As long as all of us agree, and try to use the same system, I think we'll be 
fine.

I think there's a reasonable consensus on the following understanding of 
"fixVersion/s", and "Affected Versions"
- fixVersion: All branches that the code was committed. Example, assuming that 
the last released version was x.y.z:
  - If the code was committed to master: master (x + 1.0)
  - If the code was committed to the current stable branch (branch_ax), x.y + 1
  - If the code was committed to a release branch  - the next release version 
from that branch. There would be one entry for each of the release branches 
that this fix is committed to.
  
- Affected Versions: All affected git tags (released versions of Lucene/Solr).

If there are no objections by tomorrow morning (24 hours), I'll change the wiki 
page to reflect this, and it would be great if we could all just follow this 
convention.

-Anshum



> On Jul 6, 2017, at 2:40 AM, Dawid Weiss  wrote:
> 
>> But for new features, it is different. The CHANGES entry is only added to
>> the first version the feature was introduced (e.g. 7.0.0), even if the
>> feature is committed to master, branch_7x, branch_7_0. In my head it would
>> make sense to tag it as Fix-Version=7.0.0 and not also 7.1 and 8.0.
> 
> I don't think it's that much different, really.
> 
> If you introduce a feature on branch_7x and apply it to master then
> it's both on branch_7x and master. Let's say somebody then cuts out
> branch_8x from master and creates a release of version 8.0. Then that
> somebody should tag patches on current master with branch_8x and 8.0
> (assuming he's immediately going for the release). And then you'd see
> this on your feature issue's fix-for:
> 
> branch_7x, branch_8x, 8.0, master
> 
> and since branch_7x hasn't been released yet, the feature would be
> introduced in version 8.0, not any tagged version on 7x (because they
> haven't been released yet). You could either rollback that feature
> from branch_7x (and remove the tag), or keep it and release that
> feature from both branches (next version of 7x). Or never release
> branch_7x at all, but keep the patch there anyway.
> 
> Sure, this is a bit abnormal to have the same new "feature" on two
> different branches, but you can apply the same thinking to bugfix
> versions as well (features or any kind of patch). This is something
> Hoss mentioned -- when you're doing multiple parallel releases of
> versions from different branches it becomes a headache quickly to
> figure out which version carries a certain patch (whether it's a bug,
> feature or whatever else). But in reality it is often the case (in my
> personal experience) that multiple versions do carry the same set of
> patches, be it bug fixes, refactorings or even new features and those
> tags in jira help to figure out where a given patch exists.
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-9-ea+173) - Build # 27 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/27/
Java: 64bit/jdk-9-ea+173 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
__randomizedtesting.SeedInfo.seed([F49535173A2D9BFC:3183F18C2A9BA39C]:0)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffObject(SolrInfoMBeanHandler.java:240)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.diffNamedList(SolrInfoMBeanHandler.java:219)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.getDiff(SolrInfoMBeanHandler.java:187)
at 
org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:87)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2473)
at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:57)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Updated] (SOLR-11036) MetricsHandler should report disk stats for solr.data.home

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  updated SOLR-11036:
-
Fix Version/s: 7.1
   master (8.0)

> MetricsHandler should report disk stats for solr.data.home
> --
>
> Key: SOLR-11036
> URL: https://issues.apache.org/jira/browse/SOLR-11036
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics, SolrCloud
>Affects Versions: 7.0
>Reporter: Shalin Shekhar Mangar
>Assignee: Andrzej Bialecki 
>  Labels: metrics
> Fix For: 7.0, master (8.0), 7.1
>
>
> The totalSpace and usableSpace reported by Metrics API are still based on 
> coreRootDirectory (which is used as the instance dir for individual cores). 
> SOLR-6671 introduced a new solr.data.home configuration for the root 
> directory of all data dirs. So we should expose data home's disk metrics as 
> well.
> Since the current metric names are just totalSpace and usableSpace under the 
> Container group, we need to figure out how to differentiate between them and 
> the data home's metrics. A few options:
> # We can introduce new metrics such as dataHomeTotalSpace and 
> dataHomeUsableSpace. 
> # We use the current names for the data home's metrics and introduce new ones 
> for coreRootDirectory
> I lean towards #2 because of backcompat reasons. Existing users (and 
> monitoring vendors/products) would be using the existing metric names to 
> track disk stats for their solr installations. If a user configures a 
> solr.data.home then they shouldn't get a surprise one day if the data home 
> directory runs out of space when they have monitoring already in place which 
> used to work for earlier versions of Solr. The probability of surprise still 
> exists because one fine day you can run out of space for the 
> coreRootDirectory and solr will refuse to create any cores but that is a less 
> likely scenario than running out of disk space because of increasing size of 
> data directories.



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

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

[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10229:
---

[~hossman_luc...@fucit.org] Agreed, we won't check it in until those JIRAs are 
fixed.

At this point, I'm more looking at whether this approach seems useful in form 
before polishing it. Do you find the code snippet above something you'd 
actually use when writing tests? Or are there better approaches from a _test 
writer's_ perspective?

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



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

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

[jira] [Commented] (LUCENE-7711) TestRandomChains.testRandomChains() failure: got startOffset=10,endOffset=9

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7711:


Another reproducing failure on branch_7_0, from my Jenkins:

{noformat}
Checking out Revision 6cdc0060e5c3b93f0764d7e8e441fa21931fe60d 
(refs/remotes/origin/branch_7_0)
[...]
   [junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
   [junit4]   2> TEST FAIL: useCharFilter=true text='arr]] 
[[ja:\u30de\u30b7\u30e5\u30fc\u30fb\u30d1\u30fc\u30eb '
   [junit4]   2> Exception from random analyzer: 
   [junit4]   2> charfilters=
   [junit4]   2> tokenizer=
   [junit4]   2>   org.apache.lucene.analysis.standard.StandardTokenizer()
   [junit4]   2> filters=
   [junit4]   2>   
org.apache.lucene.analysis.miscellaneous.KeywordRepeatFilter(ValidatingTokenFilter@218bc4e4
 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
   [junit4]   2>   
org.apache.lucene.analysis.core.DecimalDigitFilter(ValidatingTokenFilter@48b9b511
 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
   [junit4]   2>   
org.apache.lucene.analysis.miscellaneous.HyphenatedWordsFilter(ValidatingTokenFilter@6800dfe4
 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
   [junit4]   2>   
org.apache.lucene.analysis.cjk.CJKBigramFilter(ValidatingTokenFilter@507e81ab 
term=,bytes=[],startOffset=0,endOffset=0,positionIncrement=1,positionLength=1,type=word,termFrequency=1,keyword=false)
   [junit4]   2> offsetsAreCorrect=false
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestRandomChains 
-Dtests.method=testRandomChains -Dtests.seed=2577EBB6844BD489 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
-Dtests.locale=en-ZA -Dtests.timezone=America/Argentina/Jujuy 
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
   [junit4] ERROR   18.9s J2 | TestRandomChains.testRandomChains <<<
   [junit4]> Throwable #1: java.lang.IllegalArgumentException: startOffset 
must be non-negative, and endOffset must be >= startOffset, and offsets must 
not go backwards startOffset=11,endOffset=13,lastStartOffset=13 for field 
'dummy'
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([2577EBB6844BD489:1896C2D7C359C949]:0)
   [junit4]>at 
org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:769)
   [junit4]>at 
org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:431)
   [junit4]>at 
org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:393)
   [junit4]>at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:239)
   [junit4]>at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:481)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1717)
   [junit4]>at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1462)
   [junit4]>at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:171)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:650)
   [junit4]>at 
org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:540)
   [junit4]>at 
org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:856)
{noformat}

> TestRandomChains.testRandomChains() failure: got startOffset=10,endOffset=9
> ---
>
> Key: LUCENE-7711
> URL: https://issues.apache.org/jira/browse/LUCENE-7711
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
>
> Found while beasting TestRandomChains for LUCENE-7708 (note though that the 
> failure below reproduces on a clean master checkout):
> {noformat}
>[junit4] Suite: org.apache.lucene.analysis.core.TestRandomChains
>[junit4]   2> TEST FAIL: useCharFilter=false text='\ufac4\u0552H 
> \ua954\ua944 \ud0d2\uaddd\ub6cb\uc388\uc344\uca88\ud224\uc462\uaf42 g '
>[junit4]   2> Exception from random analyzer: 
>[junit4]   2> charfilters=
>[junit4]   2>   
> org.apache.lucene.analysis.charfilter.HTMLStripCharFilter(java.io.StringReader@72c69dd0,
>  [, , , ])
>[junit4]   2> tokenizer=
>[junit4]   2>   
> 

[jira] [Updated] (SOLR-11042) Sort by function query: throw exception if can't parse

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev updated SOLR-11042:
--
Description: 
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be a pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see [^SOLR-11042.patch]) ? WDYT?

  was:
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see [^SOLR-11042.patch]) ? WDYT?


> Sort by function query: throw exception if can't parse
> --
>
> Key: SOLR-11042
> URL: https://issues.apache.org/jira/browse/SOLR-11042
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-11042.patch
>
>
> I have a couple of use cases where I need to sort result list by function 
> query values (something like {{sort query(..) desc}} or {{sort product(...) 
> asc}} )
> Even if that {{...}} could be a pretty complicated query with lots of 
> clauses, this technique worked like a charm until I created a query in 
> incorrect Solr's syntax , i.e. I created a string which {{FunctionQParser}} 

[jira] [Updated] (SOLR-11042) Sort by function query: throw exception if can't parse

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev updated SOLR-11042:
--
Description: 
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see [^SOLR-11042.patch]) ? WDYT?

  was:
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see patch attached) ? WDYT?


> Sort by function query: throw exception if can't parse
> --
>
> Key: SOLR-11042
> URL: https://issues.apache.org/jira/browse/SOLR-11042
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-11042.patch
>
>
> I have a couple of use cases where I need to sort result list by function 
> query values (something like {{sort query(..) desc}} or {{sort product(...) 
> asc}} )
> Even if that {{...}} could be pretty complicated query with lots of clauses, 
> this technique worked like a charm until I created a query in incorrect 
> Solr's syntax , i.e. I created a string which {{FunctionQParser}} failed to 

[jira] [Updated] (SOLR-11042) Sort by function query: throw exception if can't parse

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev updated SOLR-11042:
--
Description: 
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be a pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for +field+ {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see [^SOLR-11042.patch]) ? WDYT?

  was:
I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be a pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see [^SOLR-11042.patch]) ? WDYT?


> Sort by function query: throw exception if can't parse
> --
>
> Key: SOLR-11042
> URL: https://issues.apache.org/jira/browse/SOLR-11042
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-11042.patch
>
>
> I have a couple of use cases where I need to sort result list by function 
> query values (something like {{sort query(..) desc}} or {{sort product(...) 
> asc}} )
> Even if that {{...}} could be a pretty complicated query with lots of 
> clauses, this technique worked like a charm until I created a query in 
> incorrect Solr's syntax , i.e. I created a string which 

[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10229:
-

I haven't done more then just skim the patch, but I would strongly advise 
against any attempt to make more tests leverage ManagedIndexSchema (and adding 
fields as needed in setup) unless/until both SOLR-11034 & SOLR-11035 get fixed. 
 The combination of the two are essentially a guaranteed recipe for confusing 
(non-reproducible seed) failures like SOLR-10562 and SOLR-9843.

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



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

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

[jira] [Resolved] (SOLR-10996) Implement TriggerListener API

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-10996.
--
   Resolution: Fixed
Fix Version/s: 7.1

Committed to {{feature/autoscaling}}. Thanks Shalin for your reviews!

> Implement TriggerListener API
> -
>
> Key: SOLR-10996
> URL: https://issues.apache.org/jira/browse/SOLR-10996
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: 7.1
>
> Attachments: SOLR-10996.patch, SOLR-10996.patch, SOLR-10996.patch
>
>
> SOLR-10340 added API for configuring trigger listeners. This issue is about 
> adding hooks in the framework for calling the listeners and providing a 
> couple implementations (HTTP callback, logging).



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

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

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([74F1B5FB79314654:CE23DA83FA1FA841]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:878)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:353)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529==0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:871)
... 40 more


FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during 

[jira] [Updated] (SOLR-11042) Sort by function query: throw exception if can't parse

[Andrey Kudryavtsev (JIRA)]

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

Andrey Kudryavtsev updated SOLR-11042:
--
Attachment: SOLR-11042.patch

> Sort by function query: throw exception if can't parse
> --
>
> Key: SOLR-11042
> URL: https://issues.apache.org/jira/browse/SOLR-11042
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Andrey Kudryavtsev
>Priority: Minor
>  Labels: patch
> Attachments: SOLR-11042.patch
>
>
> I have a couple of use cases where I need to sort result list by function 
> query values (something like {{sort query(..) desc}} or {{sort product(...) 
> asc}} )
> Even if that {{...}} could be pretty complicated query with lots of clauses, 
> this technique worked like a charm until I created a query in incorrect 
> Solr's syntax , i.e. I created a string which {{FunctionQParser}} failed to 
> parse ( I had something that in simplification could be described as 
> {{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).
> This lead to unexpected behaviour (at least from my pov). See 
> [SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
>  :
> * FunctionQParser failed to parse query, but exception wasn't thrown:
> {code}
> catch (Exception e) {
> // hang onto this in case the string isn't a full field name 
> either
> qParserException = e;;
> }
> {code}
> * Solr tried to handle sorting clause  as a field and made a lookup into 
> Schema:
> {code}
>   SchemaField sf = schema.getFieldOrNull(field);
>   if (null == sf) {
> ..
> {code}
>  * I had a "match all" field type mapped on {{*}} in schema, and this type 
> was matched by string {{query($sortQuery)}}
> * Then there are two possibilities (and I don't like both of them):
> **  If "match all" field type is multi valued, there would be an exception
> {code}
>  can not sort on multivalued field: query($sortQuery)
> {code}
> ** If "match all" field type is single valued, then it would try to sort by 
> values for field {{query($sortQuery)}}  (without any exceptions)
> I understand (by tests running) from where this error hiding came from. 
> But what if we will make some basic efforts to help guys like me to detect 
> errors in syntax as soon as possible  (see patch attached) ? WDYT?



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

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

[jira] [Created] (SOLR-11042) Sort by function query: throw exception if can't parse

[Andrey Kudryavtsev (JIRA)]

Andrey Kudryavtsev created SOLR-11042:
-

 Summary: Sort by function query: throw exception if can't parse
 Key: SOLR-11042
 URL: https://issues.apache.org/jira/browse/SOLR-11042
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 7.0
Reporter: Andrey Kudryavtsev
Priority: Minor


I have a couple of use cases where I need to sort result list by function query 
values (something like {{sort query(..) desc}} or {{sort product(...) asc}} )

Even if that {{...}} could be pretty complicated query with lots of clauses, 
this technique worked like a charm until I created a query in incorrect Solr's 
syntax , i.e. I created a string which {{FunctionQParser}} failed to parse ( I 
had something that in simplification could be described as 
{{sort=query($sortQuery) desc=type: a b c}} without proper {{df}} ).

This lead to unexpected behaviour (at least from my pov). See 
[SortSpecParsing#parseSortSpecImpl|https://github.com/apache/lucene-solr/blob/e2521b2a8baabdaf43b92192588f51e042d21e97/solr/core/src/java/org/apache/solr/search/SortSpecParsing.java#L88]
 :
* FunctionQParser failed to parse query, but exception wasn't thrown:
{code}
catch (Exception e) {
// hang onto this in case the string isn't a full field name either
qParserException = e;;
}
{code}

* Solr tried to handle sorting clause  as a field and made a lookup into Schema:
{code}
  SchemaField sf = schema.getFieldOrNull(field);
  if (null == sf) {
..
{code}
 * I had a "match all" field type mapped on {{*}} in schema, and this type was 
matched by string {{query($sortQuery)}}
* Then there are two possibilities (and I don't like both of them):
**  If "match all" field type is multi valued, there would be an exception
{code}
 can not sort on multivalued field: query($sortQuery)
{code}
** If "match all" field type is single valued, then it would try to sort by 
values for field {{query($sortQuery)}}  (without any exceptions)

I understand (by tests running) from where this error hiding came from. 

But what if we will make some basic efforts to help guys like me to detect 
errors in syntax as soon as possible  (see patch attached) ? WDYT?



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

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

[jira] [Updated] (SOLR-10908) CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq clauses

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-10908:
--
Attachment: SOLR-10229.patch

Failing test patch showing problem.

> CloudSolrStream.toExpression (and perhaps others) incorrectly handles fq 
> clauses
> 
>
> Key: SOLR-10908
> URL: https://issues.apache.org/jira/browse/SOLR-10908
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6, 7.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Attachments: SOLR-10229.patch
>
>
> toExpression in at least CloudSolrStream concatenates parameters in a 
> comma-separated list. This is fine for things like sorting but incorrect for 
> fq clauses. If my input is something like
> fq=condition1
> fq=condition2
> it winds up being something like
> fq=condition1,condition2
> I've seen it in this class for this parameter, other classes and other 
> parameters might have the same problem.



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

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

[jira] [Commented] (SOLR-10981) Allow update to load gzip files

[JIRA]

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

Jan Høydahl commented on SOLR-10981:


Yes, let's spin off the POST into another issue.

There are no further 6.x feature releases planned, and 7.0 is already in 
feature freeze. So the earliest you can hope for is 7.1.
If we get the feature into 7.1 in not too long time, we can always backport to 
{{branch_6x}} in case of a potential 6.7 release.
You can of course also build your own custom Solr off from 6.6 branch with this 
patch applied.

> Allow update to load gzip files 
> 
>
> Key: SOLR-10981
> URL: https://issues.apache.org/jira/browse/SOLR-10981
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrJ
>Affects Versions: 6.6
>Reporter: Andrew Lundgren
>  Labels: patch
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10981.patch, SOLR-10981.patch, SOLR-10981.patch
>
>
> We currently import large CSV files.  We store them in gzip files as they 
> compress at around 80%.
> To import them we must gunzip them and then import them.  After that we no 
> longer need the decompressed files.
> This patch allows directly opening either URL, or local files that are 
> gzipped.
> For URLs, to determine if the file is gzipped, it will check the content 
> encoding=="gzip" or if the file ends in ".gz"
> For files, if the file ends in ".gz" then it will assume the file is gzipped.
> I have tested the patch with 4.10.4, 6.6.0 and master from git.



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

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

[jira] [Commented] (SOLR-10123) Analytics Component 2.0

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-10123:
---

Non-reproducing failure from 
[https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/38/]:
{noformat}
Checking out Revision 5ba509dbd267d28f616d20c195b7fad70fc6064b 
(refs/remotes/origin/branch_7x)
[...]
   [junit4]   2> NOTE: test params are: 
codec=HighCompressionCompressingStoredFields(storedFieldsFormat=CompressingStoredFieldsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=6, maxDocsPerChunk=997, blockSize=6), 
termVectorsFormat=CompressingTermVectorsFormat(compressionMode=HIGH_COMPRESSION,
 chunkSize=6, blockSize=6)), sim=RandomSimilarity(queryNorm=false): {}, 
locale=en-SG, timezone=Etc/GMT-10
   [junit4]   2> NOTE: Linux 4.10.0-21-generic i386/Oracle Corporation 
1.8.0_131 (32-bit)/cpus=8,threads=1,free=31874992,total=63266816
   [junit4]   2> NOTE: All tests run in this JVM: [AbstractAnalyticsFacetTest, 
FieldFacetExtrasCloudTest, AbstractAnalyticsStatsTest, NoFacetTest, 
FacetSortingTest, FieldFacetExtrasTest, QueryFacetCloudTest]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=QueryFacetCloudTest 
-Dtests.seed=F3E68F7CEEE0C86C -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=en-SG -Dtests.timezone=Etc/GMT-10 -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] ERROR   0.00s J1 | QueryFacetCloudTest (suite) <<<
   [junit4]> Throwable #1: 
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: 
org.apache.http.ParseException: Invalid content type: 
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F3E68F7CEEE0C86C]:0)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:541)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
   [junit4]>at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
   [junit4]>at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
   [junit4]>at 
org.apache.solr.analytics.facet.QueryFacetCloudTest.beforeClass(QueryFacetCloudTest.java:102)
   [junit4]>at java.lang.Thread.run(Thread.java:748)
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
org.apache.http.ParseException: Invalid content type: 
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:523)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
   [junit4]>at 
org.apache.solr.client.solrj.impl.CloudSolrClient.lambda$directUpdate$0(CloudSolrClient.java:516)
   [junit4]>at 
java.util.concurrent.FutureTask.run(FutureTask.java:266)
   [junit4]>at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
   [junit4]>at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   [junit4]>... 1 more
   [junit4]> Caused by: org.apache.http.ParseException: Invalid content 
type: 
   [junit4]>at 
org.apache.http.entity.ContentType.parse(ContentType.java:273)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:252)
   [junit4]>at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
   [junit4]>at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
   [junit4]>... 7 more
{noformat}

> Analytics Component 2.0
> ---
>
> Key: SOLR-10123
> URL: https://issues.apache.org/jira/browse/SOLR-10123
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.0
>Reporter: Houston Putman
>  Labels: features
> Fix For: 7.0
>
> Attachments: SOLR-10123.patch, SOLR-10123.patch, SOLR-10123.patch, 
> SOLR-10123.patch.bugfixes
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * New JSON request language, and response format that fits JSON better.
> * Faceting 

[jira] [Commented] (SOLR-10229) See what it would take to shift many of our one-off schemas used for testing to managed schema and construct them as part of the tests

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-10229:
---

No comments so everything's just fine, right?

[~dsmiley][~sarkaramr...@gmail.com][~arafalov][~hoss...@fucit.org]
Any comments or should we just carry this forward?

> See what it would take to shift many of our one-off schemas used for testing 
> to managed schema and construct them as part of the tests
> --
>
> Key: SOLR-10229
> URL: https://issues.apache.org/jira/browse/SOLR-10229
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229.patch, SOLR-10229.patch, SOLR-10229.patch, 
> SOLR-10229-straw-man.patch
>
>
> The test schema files are intimidating. There are about a zillion of them, 
> and making a change in any of them risks breaking some _other_ test. That 
> leaves people three choices:
> 1> add what they need to some existing schema. Which makes schemas bigger and 
> bigger and bigger.
> 2> create a new schema file, adding to the proliferation thereof.
> 3> Look through all the existing tests to see if they have something that 
> works.
> The recent work on LUCENE-7705 is a case in point. We're adding a maxLen 
> parameter to some tokenizers. Putting those parameters into any of the 
> existing schemas, especially to test < 255 char tokens is virtually 
> guaranteed to break other tests, so the only safe thing to do is make another 
> schema file. Adding to the multiplication of files.
> As part of SOLR-5260 I tried creating the schema on the fly rather than 
> creating a new static schema file and it's not hard. WDYT about making this 
> into some better thought-out utility? 
> At present, this is pretty fuzzy, I wanted to get some reactions before 
> putting much effort into it. I expect that the utility methods would 
> eventually get a bunch of canned types. It's reasonably straightforward for 
> primitive types, if lengthy. But when you get into solr.TextField-based types 
> it gets less straight-forward.
> We could manage to just move the "intimidation" from the plethora of schema 
> files to a zillion fieldTypes in the utility to choose from...
> Also, forcing every test to define the fields up-front is arguably less 
> convenient than just having _some_ canned schemas we can use. And erroneous 
> schemas to test failure modes are probably not very good fits for any such 
> framework.
> [~steve_rowe] and [~hossman_luc...@fucit.org] in particular might have 
> something to say.



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

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

[jira] [Comment Edited] (SOLR-10452) setQueryParams should be deprecated in favor of SolrClientBuilder methods

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski edited comment on SOLR-10452 at 7/10/17 4:40 PM:
-

I think I agree in part, but not in the whole.

bq. Anything that needs flexibility post-construction ... shouldn't be part of 
the builder

Though I tried to do them both in the attached patch, deprecating the setter, 
and adding a builder method are conceptually separate things.  IMO even if we 
don't deprecate the setter, adding this method to the builder still makes 
sense.  (Users probably find it a bit unintuitive that we allow setting some 
options with a builder, but then require others to be specified with a setter 
after creation.)

bq.  i.e. might need to be changed post construction of the client

I'm surprised to hear you say that this is more likely to change than some 
other properties already present in the builders (timeouts, response parsers, 
base urls, etc.).  But this is likely just a failure of imagination on my part; 
I'm admittedly not familiar with all use cases here.  If you think it's 
reasonable for users to change this during execution (as opposed to creating a 
different client with the new options), then I'll of course defer to your 
judgment.  Though I'm curious if there's a use case the requires changing this 
that I'm forgetting/missing.

In that case though, would you mind weighing in over on SOLR-8975 (or here) 
about which other setters you have this concern with? I'd hoped to add builder 
methods for many of these setters (and optionally deprecate the setters 
themselves).  I'd like to get a clearer picture of which ones would still make 
sense for this in your opinion.

My _guess_ is that the following setters are probably exempt from your concern 
above, as they are related to finding/authenticating/connecting to a Solr/ZK 
setup and are unlikely to change frequently are runtime.
- setBaseURL,
- setBasicAuthHeader
- setFollowRedirects
- setZkConnectTimeout
- setZkClientTimeout
- setAliveCheckInterval

There might be others that are exempt, but I'll defer to your judgment on that.


was (Author: gerlowskija):
I think I agree in part, but not in the whole.

bq. Anything that needs flexibility post-construction ... shouldn't be part of 
the builder

Though I tried to do them both in the attached patch, deprecating the setter, 
and adding a builder method are conceptually separate things.  IMO even if we 
don't deprecate the setter, adding this method to the builder still makes 
sense.  (Users probably find it a bit unintuitive that we allow setting some 
options with a builder, but then require others to be specified with a setter 
after creation.)

bq.  i.e. might need to be changed post construction of the client

I'm surprised to hear you say that this is more likely to change than some 
other properties already present in the builders (timeouts, response parsers, 
base urls, etc.).  But this is likely just a failure of imagination on my part; 
I'm admittedly not familiar with all use cases here.  If you think it's 
reasonable for users to change this during execution (as opposed to creating a 
different client with the new options), then I'll of course defer to your 
judgment.  Though I'm curious if there's a use case the requires changing this 
that I'm forgetting/missing.

In that case though, would you mind weighing in over on SOLR-8975 (or here) 
about which other setters you have this concern with? I'd hoped to add builder 
methods for many of these setters (and optionally deprecate the setters 
themselves).  I'd like to get a clearer picture of which ones would still make 
sense for this in your opinion.

> setQueryParams should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10452
> URL: https://issues.apache.org/jira/browse/SOLR-10452
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10452.patch
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setQueryParams}} 
> setter 

[jira] [Commented] (SOLR-10452) setQueryParams should be deprecated in favor of SolrClientBuilder methods

[Jason Gerlowski (JIRA)]

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

Jason Gerlowski commented on SOLR-10452:


I think I agree in part, but not in the whole.

bq. Anything that needs flexibility post-construction ... shouldn't be part of 
the builder

Though I tried to do them both in the attached patch, deprecating the setter, 
and adding a builder method are conceptually separate things.  IMO even if we 
don't deprecate the setter, adding this method to the builder still makes 
sense.  (Users probably find it a bit unintuitive that we allow setting some 
options with a builder, but then require others to be specified with a setter 
after creation.)

bq.  i.e. might need to be changed post construction of the client

I'm surprised to hear you say that this is more likely to change than some 
other properties already present in the builders (timeouts, response parsers, 
base urls, etc.).  But this is likely just a failure of imagination on my part; 
I'm admittedly not familiar with all use cases here.  If you think it's 
reasonable for users to change this during execution (as opposed to creating a 
different client with the new options), then I'll of course defer to your 
judgment.  Though I'm curious if there's a use case the requires changing this 
that I'm forgetting/missing.

In that case though, would you mind weighing in over on SOLR-8975 (or here) 
about which other setters you have this concern with? I'd hoped to add builder 
methods for many of these setters (and optionally deprecate the setters 
themselves).  I'd like to get a clearer picture of which ones would still make 
sense for this in your opinion.

> setQueryParams should be deprecated in favor of SolrClientBuilder methods
> -
>
> Key: SOLR-10452
> URL: https://issues.apache.org/jira/browse/SOLR-10452
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrJ
>Reporter: Jason Gerlowski
>Priority: Minor
> Fix For: 7.0
>
> Attachments: SOLR-10452.patch
>
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the {{setQueryParams}} 
> setter on all {{SolrClient}} implementations.



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

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

[jira] [Commented] (LUCENE-7897) RangeQuery optimization in IndexOrDocValuesQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7897:
--

bq. May be we could refactor this if we can pass the "#matchingdocs or 
minScore" to the place where we decide the scorer.

Would you like to give it a try?

> RangeQuery optimization in IndexOrDocValuesQuery 
> -
>
> Key: LUCENE-7897
> URL: https://issues.apache.org/jira/browse/LUCENE-7897
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Affects Versions: trunk, 7.0
>Reporter: Murali Krishna P
>
> For range queries, Lucene uses either Points or Docvalues based on cost 
> estimation 
> (https://lucene.apache.org/core/6_5_0/core/org/apache/lucene/search/IndexOrDocValuesQuery.html).
>  Scorer is chosen based on the minCost here: 
> https://github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/search/Boolean2ScorerSupplier.java#L16
> However, the cost calculation for TermQuery and IndexOrDocvalueQuery seems to 
> have same weightage. Essentially, cost depends upon the docfreq in TermDict, 
> number of points visited and number of docvalues. In a situation where 
> docfreq is not too restrictive, this is lot of lookups for docvalues and 
> using points would have been better.
> Following query with 1M matches, takes 60ms with docvalues, but only 27ms 
> with points. If I change the query to "message:*", which matches all docs, it 
> choses the points(since cost is same), but with message:xyz it choses 
> docvalues eventhough doc frequency is 1million which results in many docvalue 
> fetches. Would it make sense to change the cost of docvalues query to be 
> higher or use points if the docfreq is too high for the term query(find an 
> optimum threshold where points cost < docvalue cost)?
> {noformat}
> {
>   "query": {
> "bool": {
>   "must": [
> {
>   "query_string": {
> "query": "message:xyz"
>   }
> },
> {
>   "range": {
> "@timestamp": {
>   "gte": 149865240,
>   "lte": 149890500,
>   "format": "epoch_millis"
> }
>   }
> }
>   ]
> }
>   }
> }
> {noformat}



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

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

Re: 7.0 Release Update

[Cassandra Targett]

Thanks Steve.

On Mon, Jul 10, 2017 at 10:35 AM, Anshum Gupta  wrote:
> Thanks Steve, and Cassandra.
>
> On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe  wrote:
>>
>>
>> > On Jul 10, 2017, at 11:04 AM, Cassandra Targett 
>> > wrote:
>> >
>> > We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
>> > maybe you could help with that?
>>
>> I created 7.x & 7.0 ref guide jobs by cloning the master job.
>>
>> > On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
>> >>
>> >> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet
>> >> create
>> >> 7.0 jobs. I just want the 7.x builds succeed.
>>
>> I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x
>> jobs are behaving normally.  I did not create the 7.0 jobs on Policeman
>> Jenkins.
>>
>> >> I disabled all 6.x builds. I’d like to nuke them at some and just leave
>> >> the
>> >> 6.6 builds disabled as a fallback for a new point release. This goes in
>> >> line
>> >> with Erick’s question about JIRA labels! I’d not go for a 6.7 release,
>> >> we
>> >> should just focus on 7.0.
>>
>> I also disabled the 6.x ref guide job.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

Re: unsubscribe

[Erick Erickson]

Please follow the instructions here:
http://lucene.apache.org/solr/community.html, including the "problems"
link if you are having trouble.



On Mon, Jul 10, 2017 at 6:50 AM, Brandon Miller
 wrote:
>
>
> --
> May the Lord Jesus Christ give you grace and peace!
>
> P.S. Have you answered the most important question that you can ask?

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

Re: 7.0 Release Update

[Anshum Gupta]

Thanks Steve, and Cassandra.

On Mon, Jul 10, 2017 at 8:29 AM Steve Rowe  wrote:

>
> > On Jul 10, 2017, at 11:04 AM, Cassandra Targett 
> wrote:
> >
> > We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
> > maybe you could help with that?
>
> I created 7.x & 7.0 ref guide jobs by cloning the master job.
>
> > On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
> >>
> >> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet
> create
> >> 7.0 jobs. I just want the 7.x builds succeed.
>
> I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x
> jobs are behaving normally.  I did not create the 7.0 jobs on Policeman
> Jenkins.
>
> >> I disabled all 6.x builds. I’d like to nuke them at some and just leave
> the
> >> 6.6 builds disabled as a fallback for a new point release. This goes in
> line
> >> with Erick’s question about JIRA labels! I’d not go for a 6.7 release,
> we
> >> should just focus on 7.0.
>
> I also disabled the 6.x ref guide job.
>
> --
> Steve
> www.lucidworks.com
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (SOLR-10574) Choose a default configset for Solr 7

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-10574:
--

bq. I took a quick look at refGuide patch and I think we should commit it

Thanks [~janhoy], I was on vacation last week. I'll give it another review 
later this week once I'm caught up again.

> Choose a default configset for Solr 7
> -
>
> Key: SOLR-10574
> URL: https://issues.apache.org/jira/browse/SOLR-10574
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 7.0
>
> Attachments: SOLR-10574.patch, SOLR-10574.patch, SOLR-10574.patch, 
> SOLR-10574.patch, SOLR-10574-refguide.patch
>
>
> Currently, the data_driven_schema_configs is the default configset when 
> collections are created using the bin/solr script and no configset is 
> specified.
> However, that may not be the best choice. We need to decide which is the best 
> choice, out of the box, considering many users might create collections 
> without knowing about the concept of a configset going forward.
> (See also SOLR-10272)
> Proposed changes:
> # Remove data_driven_schema_configs and basic_configs
> # Introduce a combined configset, {{_default}} based on the above two 
> configsets.
> # Build a "toggleable" data driven functionality into {{_default}}
> Usage:
> # Create a collection (using _default configset)
> # Data driven / schemaless functionality is enabled by default; so just start 
> indexing your documents.
> # If don't want data driven / schemaless, disable this behaviour: {code}
> curl http://host:8983/solr/coll1/config -d '{"set-user-property": 
> {"update.autoCreateFields":"false"}}'
> {code}
> # Create schema fields using schema API, and index documents



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

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

[jira] [Resolved] (LUCENE-2342) DisjunctionSumScorer explain

[Adrien Grand (JIRA)]

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

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

DisjunctiosSumScorer no longer has its own explain.

> DisjunctionSumScorer explain
> 
>
> Key: LUCENE-2342
> URL: https://issues.apache.org/jira/browse/LUCENE-2342
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Reporter: Gary Yngve
>Priority: Minor
>   Original Estimate: 10m
>  Remaining Estimate: 10m
>
> The bottom of the explain method in DisjunctionSumScorer says
> if (nrMatchers >= minimumNrMatchers) {
> This is incorrect.. it should say
> if (nrMatches >= minimumNrMatchers) {
> nrMatchers is the instance variable used for advancing, whereas nrMatches is 
> explain's local variable.
> Minor, because I don't think DSS's explain is ever called by anything 
> (BooleanWeight has its own explain)?



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

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

Re: 7.0 Release Update

[Steve Rowe]

> On Jul 10, 2017, at 11:04 AM, Cassandra Targett  wrote:
> 
> We also need Solr Ref Guide Jenkins jobs for 7.x and 7.0 - Steve Rowe
> maybe you could help with that?

I created 7.x & 7.0 ref guide jobs by cloning the master job.

> On Tue, Jul 4, 2017 at 6:53 AM, Uwe Schindler  wrote:
>> 
>> I enabled the 7.x builds on ASF and Policeman Jenkins. I did not yet create
>> 7.0 jobs. I just want the 7.x builds succeed.

I went ahead and created the 7.0 jobs on ASF Jenkins - seems like the 7.x jobs 
are behaving normally.  I did not create the 7.0 jobs on Policeman Jenkins.

>> I disabled all 6.x builds. I’d like to nuke them at some and just leave the
>> 6.6 builds disabled as a fallback for a new point release. This goes in line
>> with Erick’s question about JIRA labels! I’d not go for a 6.7 release, we
>> should just focus on 7.0.

I also disabled the 6.x ref guide job.

--
Steve
www.lucidworks.com


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

[jira] [Resolved] (LUCENE-2336) off by one: DisjunctionSumScorer::advance

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-2336.
--
Resolution: Not A Problem

We fixed the docs long time ago to state that the behaviour is undefined if 
target is <= docID().

> off by one: DisjunctionSumScorer::advance
> -
>
> Key: LUCENE-2336
> URL: https://issues.apache.org/jira/browse/LUCENE-2336
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Reporter: Gary Yngve
>Priority: Minor
>  Labels: scorer, search
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The bug is:
> if (target <= currentDoc) {
> should be
> if (target < currentDoc) {
> based on the comments for the method as well as the contract for 
> DocIdSetIterator: "Advances to the first beyond the current"
> It can be demonstrated by:
>   assertEquals("advance(1) first match failed", 1, 
> scorer.advance(1));
>   assertEquals("advance(1) second match failed", n, 
> scorer.advance(1));
> if docId: 1 is a hit and n is the next hit.  (Tests all pass if this code 
> change is made.)
> I'm not labeling it as major because the class is package-protected and 
> currently passes spec.
> Relevant excerpt:
>  /**
>* Advances to the first match beyond the current whose document number is
>* greater than or equal to a given target. 
>* When this method is used the {@link #explain(int)} method should not be
>* used. 
>* The implementation uses the skipTo() method on the subscorers.
>* 
>* @param target
>*  The target document number.
>* @return the document whose number is greater than or equal to the given
>* target, or -1 if none exist.
>*/
>   public int advance(int target) throws IOException {
> if (scorerDocQueue.size() < minimumNrMatchers) {
>   return currentDoc = NO_MORE_DOCS;
> }
> if (target <= currentDoc) {
>   return currentDoc;
> }
> do {
>   if (scorerDocQueue.topDoc() >= target) {
> boolean b = advanceAfterCurrent();
> return b ? currentDoc : (currentDoc = NO_MORE_DOCS);
>   } else if (!scorerDocQueue.topSkipToAndAdjustElsePop(target)) {
> if (scorerDocQueue.size() < minimumNrMatchers) {
>   return currentDoc = NO_MORE_DOCS;
> }
>   }
> } while (true);
>   }



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

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