[jira] [Resolved] (LUCENE-7807) Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7807.
--
   Resolution: Fixed
Fix Version/s: 6.6
   master (7.0)

Closing now that LUCENE-7847 has been addressed. Thanks [~steve_rowe] for 
having logged those failures, we should have dug earlier.

> Test*RangeFieldQueries.testRandomBig() and .testRandomTiny() failures
> -
>
> Key: LUCENE-7807
> URL: https://issues.apache.org/jira/browse/LUCENE-7807
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Steve Rowe
> Fix For: master (7.0), 6.6
>
>
> My Jenkins found a failing master seed for {{testRandomBig()}} in all the 
> {{Test\*RangeFieldQueries}} suites:
> {noformat}
> Checking out Revision 2f6101b2ab9e93173a9764450b5f71935495802e 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIntRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=es-VE -Dtests.timezone=US/Hawaii -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  116s J2  | TestIntRangeFieldQueries.testRandomBig <<<
>[junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
> possibly more):
>[junit4]> FAIL (iter 28): id=973300 should not match but did
>[junit4]>  queryRange=Box(-2147483648 TO 2147483647)
>[junit4]>  box=Box(-1240758905 TO 1326270659)
>[junit4]>  queryType=CONTAINS
>[junit4]>  deleted?=false
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([90CE64A8F1BFDF78:1799192760E6A3F8]:0)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:73)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id=Lucene50(blocksize=128)}, docValues:{id=DocValuesFormat(name=Memory), 
> intRangeField=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=805, 
> maxMBSortInHeap=6.031593684373835, sim=RandomSimilarity(queryNorm=true): {}, 
> locale=es-VE, timezone=US/Hawaii
>[junit4]   2> NOTE: Linux 4.1.0-custom2-amd64 amd64/Oracle Corporation 
> 1.8.0_77 (64-bit)/cpus=16,threads=1,free=238346048,total=532152320
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestFloatRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=no-NO -Dtests.timezone=America/Lima -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE  117s J9  | TestFloatRangeFieldQueries.testRandomBig <<<
>[junit4]> Throwable #1: java.lang.AssertionError: wrong hit (first of 
> possibly more):
>[junit4]> FAIL (iter 28): id=973300 should not match but did
>[junit4]>  queryRange=Box(-Infinity TO Infinity)
>[junit4]>  box=Box(-7.845437E37 TO 1.6013746E38)
>[junit4]>  queryType=CONTAINS
>[junit4]>  deleted?=false
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([90CE64A8F1BFDF78:1799192760E6A3F8]:0)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.verify(BaseRangeFieldQueryTestCase.java:287)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.doTestRandom(BaseRangeFieldQueryTestCase.java:158)
>[junit4]>  at 
> org.apache.lucene.search.BaseRangeFieldQueryTestCase.testRandomBig(BaseRangeFieldQueryTestCase.java:73)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id=PostingsFormat(name=Asserting)}, 
> docValues:{floatRangeField=DocValuesFormat(name=Memory), 
> id=DocValuesFormat(name=Lucene70)}, maxPointsInLeafNode=69, 
> maxMBSortInHeap=7.5037451812250175, sim=RandomSimilarity(queryNorm=true): {}, 
> locale=no-NO, timezone=America/Lima
> {noformat}
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestDoubleRangeFieldQueries -Dtests.method=testRandomBig 
> -Dtests.seed=90CE64A8F1BFDF78 -Dtests.multiplier=2 -Dtests.nightly=true 
> -Dtests.slow=true 
> -Dtests.linedocsfile=/home/jenkins/lucene-data/enwiki.random.lines.txt 
> -Dtests.locale=th-TH -Dtests.timezone=America/Argentina/Tucuman 
> -Dtests.asserts=true -Dtests.f

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/849/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke

Error Message:
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)&rows=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}

Stack Trace:
java.lang.AssertionError: 
{main(json.facet={top+:+{+type:terms,+field:field_9_is,+limit:+21,+domain:{join:{from:field_5_idsS,to:field_9_is}}}+}),extra(q=(field_7_ids:6+OR+field_3_is:3)&rows=0)}
 ===> 
{responseHeader={zkConnected=true,status=0,QTime=2},response={numFound=0,start=0,maxScore=0.0,docs=[]},facets={count=0}}
 --> top key missing from: {count=0}
at 
__randomizedtesting.SeedInfo.seed([D2F19637CE167869:D92A120E0696BF9E]:0)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.assertFacetCountsAreCorrect(TestCloudJSONFacetJoinDomain.java:333)
at 
org.apache.solr.cloud.TestCloudJSONFacetJoinDomain.testBespoke(TestCloudJSONFacetJoinDomain.java:262)
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.luc

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19693/
Java: 64bit/jdk-9-ea+168 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([45D511729CDA41A5:8CADA01543151664]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
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:563)
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)


FAILED:  
org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder

Error Message:
mismatch: '3'!='4' @ response/docs/[0]/id

[jira] [Resolved] (SOLR-10736) size of id field was limited under 1000000

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10736.
---
Resolution: Incomplete

Please raise issues on the user's list first, and if there's a bug _then_ raise 
a JIRA. When you do, you need to include enough information for us to have some 
idea what behavior you're seeing, what you've tried, perhaps sample data and 
the like.

It's very unlikely that any code changes will be done that affect the 4.x code 
line so unless a problem can be demonstrated in much more recent Solr releases 
this will not be addressed.

> size of id field was limited under 100
> --
>
> Key: SOLR-10736
> URL: https://issues.apache.org/jira/browse/SOLR-10736
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: finley0066
>
> I met a issue that size of id field was limited under 100, if I continue 
> inserting document, there's no error but insert failed. build number 4.10.3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10736) size of id field was limited under 1000000

[finley0066 (JIRA)]

finley0066 created SOLR-10736:
-

 Summary: size of id field was limited under 100
 Key: SOLR-10736
 URL: https://issues.apache.org/jira/browse/SOLR-10736
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: finley0066


I met a issue that size of id field was limited under 100, if I continue 
inserting document, there's no error but insert failed. build number 4.10.3



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1319 - Failure!

[Policeman Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 19 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:809)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1076)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1107)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1212)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:560)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:619)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
at ..remote call to Solaris VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:830)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor655.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy61.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:807)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:135)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:617)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:186)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1201)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:128)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStrea

Re: [jira] [Resolved] (SOLR-8047) large longs is being saved incorrect

[Erick Erickson]

Unfortunately I spent far too much time chasing this before that
memory surfaced enough for me to check ;(...

On Tue, May 23, 2017 at 4:21 PM, Pushkar Raste  wrote:
> I ran into this issue about 2 years back and posted it on the user list.
> Yonik pointed out that it is Javascript issue :-)
>
> On May 19, 2017 2:50 PM, "Erick Erickson (JIRA)"  wrote:
>>
>>
>>  [
>> https://issues.apache.org/jira/browse/SOLR-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Erick Erickson resolved SOLR-8047.
>> --
>> Resolution: Invalid
>>
>> Now that I spent much of a day chasing down SOLR-10708 I realized that the
>> numbers are being stored and retrieved just fine. What's _not_ being done is
>> the browser rendering the numbers correctly, Solr is just fine.
>>
>> To prove this to yourself, issue the query via curl and you'll see that
>> the long values are returned correctly.
>>
>> > large longs is being saved incorrect
>> > 
>> >
>> > Key: SOLR-8047
>> > URL: https://issues.apache.org/jira/browse/SOLR-8047
>> > Project: Solr
>> >  Issue Type: Bug
>> >  Components: Schema and Analysis
>> >Affects Versions: 5.3
>> >Reporter: Manhal
>> >
>> > I have a solr schema with a field in long type
>> > 
>> > the long type in the schema is the default:
>> > > > positionIncrementGap="0"/>
>> > I am saving to the index in solrJ, the value: 3954983690244748504 to
>> > this field, but it's being saved as 3954983690244748300
>> > I am having the same with different large values.
>> > I also tested it from admin UI, adding the same long and it's being
>> > saved incorrect
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.15#6346)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 885 - Failure!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/885/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

No tests ran.

Build Log:
[...truncated 17 lines...]
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
git://git.apache.org/lucene-solr.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:809)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1076)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1107)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1212)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:560)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:485)
at hudson.model.Run.execute(Run.java:1735)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:415)
Caused by: hudson.plugins.git.GitException: 
org.eclipse.jgit.api.errors.TransportException: Connection reset
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:619)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
at ..remote call to MacOSX VBOX(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:830)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor655.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at com.sun.proxy.$Proxy61.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:807)
... 11 more
Caused by: org.eclipse.jgit.api.errors.TransportException: Connection reset
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:135)
at 
org.jenkinsci.plugins.gitclient.JGitAPIImpl$2.execute(JGitAPIImpl.java:617)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
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:748)
Caused by: org.eclipse.jgit.errors.TransportException: Connection reset
at 
org.eclipse.jgit.transport.BasePackConnection.readAdvertisedRefs(BasePackConnection.java:186)
at 
org.eclipse.jgit.transport.TransportGitAnon$TcpFetchConnection.(TransportGitAnon.java:194)
at 
org.eclipse.jgit.transport.TransportGitAnon.openFetch(TransportGitAnon.java:120)
at 
org.eclipse.jgit.transport.FetchProcess.executeImp(FetchProcess.java:136)
at 
org.eclipse.jgit.transport.FetchProcess.execute(FetchProcess.java:122)
at org.eclipse.jgit.transport.Transport.fetch(Transport.java:1201)
at org.eclipse.jgit.api.FetchCommand.call(FetchCommand.java:128)
... 11 more
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210)
at java.net.SocketInputStre

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

[Policeman Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 11765 lines...]
ERROR: command execution failed.
ERROR: Step ‘Archive the artifacts’ failed: no workspace for 
Lucene-Solr-master-MacOSX #4024
ERROR: Step ‘Scan for compiler warnings’ failed: no workspace for 
Lucene-Solr-master-MacOSX #4024
ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for 
Lucene-Solr-master-MacOSX #4024
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-6.x-Linux (64bit/jdk1.8.0_131) - Build # 3576 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/3576/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([2B451F3BD0B59D1E:A062CCEA91B3369A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:187)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:856)
at 
org.apache.solr.cloud.ShardSplitTest.testSplitWithChaosMonkey(ShardSplitTest.java:437)
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:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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.j

[jira] [Updated] (LUCENE-7844) UnifiedHighlighter: simplify "maxPassages" input API

[David Smiley (JIRA)]

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

David Smiley updated LUCENE-7844:
-
Attachment: LUCENE_7844__UH_maxPassages_simplification.patch

Here's a patch.  In addition to the primary issue at hand, I also:
* cleaned up some obsolete javadocs inherited from the PostingsHighlighter 
lineage that no longer apply
* refactored FieldHighlighter.highlightOffsetsEnums a little to use Java 8 
features related to Comparators & lambdas to save some needless LOC.
* code style: many copy-pasted tests declared {{String snippets[]}} instead of 
{{String[] snippets}}

Perhaps you want to see [~jimczi] or [~Timothy055] ?

Suggested CHANGES.txt under API changes
* Changed UnifiedHighlighter.highlightFields methods which take an array of 
maxPassage integers by field to instead take a single int. To vary per field, 
override UH.getMaxPassageCount(String field).

> UnifiedHighlighter: simplify "maxPassages" input API
> 
>
> Key: LUCENE-7844
> URL: https://issues.apache.org/jira/browse/LUCENE-7844
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Reporter: David Smiley
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: LUCENE_7844__UH_maxPassages_simplification.patch
>
>
> The "maxPassages" input to the UnifiedHighlighter can be provided as an array 
> to some of the public methods on UnifiedHighlighter.  When it's provided as 
> an array, the index in the array is for the field in a parallel array. I 
> think this is awkward and furthermore it's inconsistent with the way this 
> highlighter customizes things on a by field basis.  Instead, the parameter 
> can be a simple int default (not an array), and then there can be a protected 
> method like {{getMaxPassageCount(String field}} that returns an Integer 
> which, when non-null, replaces the default value for this field.
> Aside from API simplicity and consistency, this will also remove some 
> annoying parallel array sorting going on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10700:


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

SOLR-10700: Remove PostingsHighlighter references from docs


> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-10317:
--

Guys, did you look at https://github.com/shalinmangar/solr-perf-tools ? Why is 
the motivation behind creating yet another benchmarking utility?

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19692/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([62CE77C5A261A7E9:ABB6C6A27DAEF028]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
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)


FAILED:  
org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder

Error Message:
mismatch: '3'!=

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

[Policeman Jenkins Server]

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

6 tests failed.
FAILED:  org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard

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

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:51366/solr: deleteshard the collection time 
out:180s
at 
__randomizedtesting.SeedInfo.seed([523F475EFC03B4F5:9761F3427AF67E08]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:281)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:270)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:451)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:392)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1398)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1139)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1074)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.CollectionsAPISolrJTest.testCreateAndDeleteShard(CollectionsAPISolrJTest.java:143)
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.randomizedtesti

[jira] [Resolved] (SOLR-10634) Move calculation of some aggregations to collection phase

[Yonik Seeley (JIRA)]

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

Yonik Seeley resolved SOLR-10634.
-
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

OK, I added DebugAgg to test for the optimization kicking in and committed.

> Move calculation of some aggregations to collection phase
> -
>
> Key: SOLR-10634
> URL: https://issues.apache.org/jira/browse/SOLR-10634
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10634.patch, SOLR-10634.patch
>
>
> From http://markmail.org/message/pwgnt7iqxkzcnckh
> {quote}
> The current code is more optimized for finding the top K buckets from
> a total of N.
> When one asks to return the top 10 buckets when there are potentially
> millions of buckets, it makes sense to defer calculating other metrics
> for those buckets until we know which ones they are.  After we
> identify the top 10 buckets, we calculate the domain for that bucket
> and use that to calculate the remaining metrics.
> The current method is obviously much slower when one is requesting
> *all* buckets.  We might as well just calculate all metrics in the
> first pass rather than trying to defer them.
> {quote}
> So we should move aggregations from the second pass to the first pass under 
> the following conditions:
> - no limit (or a high limit compared to the number of potential buckets?)
> - no sub-facets (or anything else) that will need the domain calculated anyway
> - aggregation is not really memory intensive per-slot (i.e. moving some 
> calculations from per-bucket in the second phase, to all-buckets-in-parallel 
> in the first phase could be really bad for peak memory usage)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10634) Move calculation of some aggregations to collection phase

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10634:


Commit 4f86bf6df8670c3f6d9ceb458be9f14df28b8aeb in lucene-solr's branch 
refs/heads/branch_6x from [~yo...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4f86bf6 ]

SOLR-10634: calc metrics in first phase if limit=-1 and no subfacets


> Move calculation of some aggregations to collection phase
> -
>
> Key: SOLR-10634
> URL: https://issues.apache.org/jira/browse/SOLR-10634
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
> Attachments: SOLR-10634.patch, SOLR-10634.patch
>
>
> From http://markmail.org/message/pwgnt7iqxkzcnckh
> {quote}
> The current code is more optimized for finding the top K buckets from
> a total of N.
> When one asks to return the top 10 buckets when there are potentially
> millions of buckets, it makes sense to defer calculating other metrics
> for those buckets until we know which ones they are.  After we
> identify the top 10 buckets, we calculate the domain for that bucket
> and use that to calculate the remaining metrics.
> The current method is obviously much slower when one is requesting
> *all* buckets.  We might as well just calculate all metrics in the
> first pass rather than trying to defer them.
> {quote}
> So we should move aggregations from the second pass to the first pass under 
> the following conditions:
> - no limit (or a high limit compared to the number of potential buckets?)
> - no sub-facets (or anything else) that will need the domain calculated anyway
> - aggregation is not really memory intensive per-slot (i.e. moving some 
> calculations from per-bucket in the second phase, to all-buckets-in-parallel 
> in the first phase could be really bad for peak memory usage)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: setMinimumNumberShouldMatch() for SynonymQuery

[Koji Sekiguchi]

Indeed!

After I posted the question, I thought same thing. :) I withdraw it but let me explain the 
background of the issue.


In a project, we've been using NGramTokenFilter since Solr 5.5 and the field which uses the 
TokenFilter is used from edismax. The problem I mentioned became actual when we moved to 6.3.0.


After SynonymQuery was introduced in LUCENE-6789, query string which is analyzed by NGramTokenFilter 
produces SynonymQuery and hence mm parameter for edismax couldn't be set to it.


By seeing branch_6x, I'm not sure it's been improved, but I think that tokens which are produced by 
NGramTokenFilter shouldn't be converted to SynonymQuery because they are not synonyms.


I'll check the latest branch and if it still produces SynonymQuery, I'll open a 
ticket.

Thanks,

Koji



On 2017/05/23 23:43, David Smiley wrote:

Koji,
I'm unconvinced it makes sense for SynonymQuery to have minShouldMatch.  Shouldn't the scenario of 
synonyms be a pure disjunction?  If you don't think so can you give a practical counter-example?

~ David

On Tue, May 23, 2017 at 6:01 AM Koji Sekiguchi > wrote:


Hi,

Can we implement setMinimumNumberShouldMatch() for SynonymQuery, like 
BooleanQuery?

SynonymQuery was introduced in this ticket before I was aware:
https://issues.apache.org/jira/browse/LUCENE-6789

By this, analyzeBoolean() of QueryBuilder no longer creates BooleanQuery 
but SynonymQuery
instead, and then precision of certain queries decreased because mm 
parameter cannot be set.

First, I thought we should revert analyzeBoolean() so it uses BooleanQuery 
just like it used to be,
but we are already in 6.6, I think it is better for us to implement 
setMinimumNumberShouldMatch()
for SynonymQuery so we can set mm parameter for it.

Thought?

Thanks,

Koji

-
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


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

[jira] [Commented] (SOLR-10634) Move calculation of some aggregations to collection phase

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10634:


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

SOLR-10634: calc metrics in first phase if limit=-1 and no subfacets


> Move calculation of some aggregations to collection phase
> -
>
> Key: SOLR-10634
> URL: https://issues.apache.org/jira/browse/SOLR-10634
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Facet Module
>Reporter: Yonik Seeley
> Attachments: SOLR-10634.patch, SOLR-10634.patch
>
>
> From http://markmail.org/message/pwgnt7iqxkzcnckh
> {quote}
> The current code is more optimized for finding the top K buckets from
> a total of N.
> When one asks to return the top 10 buckets when there are potentially
> millions of buckets, it makes sense to defer calculating other metrics
> for those buckets until we know which ones they are.  After we
> identify the top 10 buckets, we calculate the domain for that bucket
> and use that to calculate the remaining metrics.
> The current method is obviously much slower when one is requesting
> *all* buckets.  We might as well just calculate all metrics in the
> first pass rather than trying to defer them.
> {quote}
> So we should move aggregations from the second pass to the first pass under 
> the following conditions:
> - no limit (or a high limit compared to the number of potential buckets?)
> - no sub-facets (or anything else) that will need the domain calculated anyway
> - aggregation is not really memory intensive per-slot (i.e. moving some 
> calculations from per-bucket in the second phase, to all-buckets-in-parallel 
> in the first phase could be really bad for peak memory usage)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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 # 1309 - Failure

[Apache Jenkins Server]

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

8 tests failed.
FAILED:  org.apache.lucene.search.join.TestJoinUtil.testEquals_numericJoin

Error Message:
Query shouldn't be equal, because different index readers 

Stack Trace:
java.lang.AssertionError: Query shouldn't be equal, because different index 
readers 
at 
__randomizedtesting.SeedInfo.seed([727888DA3EA9A679:2D1F52677897FF14]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.lucene.search.join.TestJoinUtil.testEquals_numericJoin(TestJoinUtil.java:1162)
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.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 
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:745)


FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:49218/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:43671/solr/test_col_shard1_replica_n2: Server Error
request: 
http://127.0.0.1:43671/solr/test_col_shard1_replica_n2/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A49218%2Fsolr%2Ftest_col_shard5_replica_n1%2F&wt=javabin&version=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0

[jira] [Resolved] (SOLR-10438) schema-point.xml and TestPointFields have suspicious assumptions about useDocValuesAsStored

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-10438.
---
   Resolution: Fixed
 Assignee: Steve Rowe
Fix Version/s: 6.7
   master (7.0)

> schema-point.xml and TestPointFields have suspicious assumptions about 
> useDocValuesAsStored
> ---
>
> Key: SOLR-10438
> URL: https://issues.apache.org/jira/browse/SOLR-10438
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
>Assignee: Steve Rowe
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10438.patch
>
>
> while working on SOLR-10425, i noticed that {{schema-point.xml}}, after 
> defining many dynamicFields with {{docValues="true"}} (and no explicit 
> mention of {{useDocValuesAsStored}}, then has a section with this comment...
> {code}
>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> ...
> {code}
> The problem with this is that the schema version=1.6, so 
> useDocValuesAsStored="true" is already the implicit default for *all* of the 
> other docValue field types defined in this schema -- making me skeptical of 
> the efficacy of this test and any assumptions it has about wether 
> {{useDocValuesAsStored}} is working properly (see also SOLR-10437)
> So we need to audit/clean-up this schema/test up to ensure that the effective 
> value of {{useDocValuesAsStored}}  is true if and only if the test code 
> expects it to be true.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10438) schema-point.xml and TestPointFields have suspicious assumptions about useDocValuesAsStored

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10438:


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

SOLR-10438: Assign explicit useDocValuesAsStored values to all points field 
types in schema-point.xml/TestPointFields.


> schema-point.xml and TestPointFields have suspicious assumptions about 
> useDocValuesAsStored
> ---
>
> Key: SOLR-10438
> URL: https://issues.apache.org/jira/browse/SOLR-10438
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10438.patch
>
>
> while working on SOLR-10425, i noticed that {{schema-point.xml}}, after 
> defining many dynamicFields with {{docValues="true"}} (and no explicit 
> mention of {{useDocValuesAsStored}}, then has a section with this comment...
> {code}
>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> ...
> {code}
> The problem with this is that the schema version=1.6, so 
> useDocValuesAsStored="true" is already the implicit default for *all* of the 
> other docValue field types defined in this schema -- making me skeptical of 
> the efficacy of this test and any assumptions it has about wether 
> {{useDocValuesAsStored}} is working properly (see also SOLR-10437)
> So we need to audit/clean-up this schema/test up to ensure that the effective 
> value of {{useDocValuesAsStored}}  is true if and only if the test code 
> expects it to be true.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10438) schema-point.xml and TestPointFields have suspicious assumptions about useDocValuesAsStored

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10438:


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

SOLR-10438: Assign explicit useDocValuesAsStored values to all points field 
types in schema-point.xml/TestPointFields.


> schema-point.xml and TestPointFields have suspicious assumptions about 
> useDocValuesAsStored
> ---
>
> Key: SOLR-10438
> URL: https://issues.apache.org/jira/browse/SOLR-10438
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10438.patch
>
>
> while working on SOLR-10425, i noticed that {{schema-point.xml}}, after 
> defining many dynamicFields with {{docValues="true"}} (and no explicit 
> mention of {{useDocValuesAsStored}}, then has a section with this comment...
> {code}
>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> ...
> {code}
> The problem with this is that the schema version=1.6, so 
> useDocValuesAsStored="true" is already the implicit default for *all* of the 
> other docValue field types defined in this schema -- making me skeptical of 
> the efficacy of this test and any assumptions it has about wether 
> {{useDocValuesAsStored}} is working properly (see also SOLR-10437)
> So we need to audit/clean-up this schema/test up to ensure that the effective 
> value of {{useDocValuesAsStored}}  is true if and only if the test code 
> expects it to be true.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10438) schema-point.xml and TestPointFields have suspicious assumptions about useDocValuesAsStored

[Steve Rowe (JIRA)]

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

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

Patch, explicitly sets useDocValuesAsStored on all point fields/fieldtypes in 
{{schema-point.xml}}.

{{TestPointFields}} (the only consumer of {{schema-point.xml}}) passes with 
this change.

Committing shortly, once precommit passes.

> schema-point.xml and TestPointFields have suspicious assumptions about 
> useDocValuesAsStored
> ---
>
> Key: SOLR-10438
> URL: https://issues.apache.org/jira/browse/SOLR-10438
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Hoss Man
> Attachments: SOLR-10438.patch
>
>
> while working on SOLR-10425, i noticed that {{schema-point.xml}}, after 
> defining many dynamicFields with {{docValues="true"}} (and no explicit 
> mention of {{useDocValuesAsStored}}, then has a section with this comment...
> {code}
>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> stored="false" docValues="true" useDocValuesAsStored="true"/>
> ...
> {code}
> The problem with this is that the schema version=1.6, so 
> useDocValuesAsStored="true" is already the implicit default for *all* of the 
> other docValue field types defined in this schema -- making me skeptical of 
> the efficacy of this test and any assumptions it has about wether 
> {{useDocValuesAsStored}} is working properly (see also SOLR-10437)
> So we need to audit/clean-up this schema/test up to ensure that the effective 
> value of {{useDocValuesAsStored}}  is true if and only if the test code 
> expects it to be true.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.lucene.search.join.TestJoinUtil.testEquals_numericJoin

Error Message:
Query shouldn't be equal, because different index readers 

Stack Trace:
java.lang.AssertionError: Query shouldn't be equal, because different index 
readers 
at 
__randomizedtesting.SeedInfo.seed([6A4892086D3D814F:352F48B52B03D822]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertFalse(Assert.java:68)
at 
org.apache.lucene.search.join.TestJoinUtil.testEquals_numericJoin(TestJoinUtil.java:1162)
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.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 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([C01CD63A5F11D692:964675D80DE8153]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.T

Re: [jira] [Resolved] (SOLR-8047) large longs is being saved incorrect

[Pushkar Raste]

I ran into this issue about 2 years back and posted it on the user list.
Yonik pointed out that it is Javascript issue :-)

On May 19, 2017 2:50 PM, "Erick Erickson (JIRA)"  wrote:

>
>  [ https://issues.apache.org/jira/browse/SOLR-8047?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Erick Erickson resolved SOLR-8047.
> --
> Resolution: Invalid
>
> Now that I spent much of a day chasing down SOLR-10708 I realized that the
> numbers are being stored and retrieved just fine. What's _not_ being done
> is the browser rendering the numbers correctly, Solr is just fine.
>
> To prove this to yourself, issue the query via curl and you'll see that
> the long values are returned correctly.
>
> > large longs is being saved incorrect
> > 
> >
> > Key: SOLR-8047
> > URL: https://issues.apache.org/jira/browse/SOLR-8047
> > Project: Solr
> >  Issue Type: Bug
> >  Components: Schema and Analysis
> >Affects Versions: 5.3
> >Reporter: Manhal
> >
> > I have a solr schema with a field in long type
> > 
> > the long type in the schema is the default:
> >  positionIncrementGap="0"/>
> > I am saving to the index in solrJ, the value: 3954983690244748504 to
> this field, but it's being saved as 3954983690244748300
> > I am having the same with different large values.
> > I also tested it from admin UI, adding the same long and it's being
> saved incorrect
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Policeman Jenkins Server]

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

7 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.StressHdfsTest.test

Error Message:
java.util.concurrent.TimeoutException: Could not connect to ZooKeeper 
127.0.0.1:58600 within 45000 ms

Stack Trace:
org.apache.solr.common.SolrException: java.util.concurrent.TimeoutException: 
Could not connect to ZooKeeper 127.0.0.1:58600 within 45000 ms
at 
__randomizedtesting.SeedInfo.seed([15616FF778230D6A:9D35502DD6DF6092]:0)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:183)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:117)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:107)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:86)
at 
org.apache.solr.cloud.AbstractZkTestCase.buildZooKeeper(AbstractZkTestCase.java:80)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.distribSetUp(AbstractDistribZkTestBase.java:80)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.distribSetUp(AbstractFullDistribZkTestBase.java:225)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:955)
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.util.concurrent.TimeoutException: Could not connect to 
ZooKeeper 127.0.0.1:58600 within 45000 ms
at 
org.apache.solr.common.cloud.ConnectionManager.waitForConnected(ConnectionManager.java:233)
at 
org.apache.solr.common.cloud.SolrZkClient.(SolrZkClient.java:175)
 

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi [~ichattopadhyaya] An update, now the following graph 
[http://212.47.227.9/dev/IndexingThroughputBenchmarkCloudConcurrent.html] shows 
the throughput performance with different thread configurations (2,4,6,8 and 10 
Threads) on a Solr cluster of 5 Nodes with 2 Shards and 2 Replicas (as an 
example).  Regards. 

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10637) org.apache.solr.client.solrj.util.ClientUtils.toSolrInputDocument is removed in Solr 6.0 and there is no alternative

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10637:
-

bq. No problem. Unfortunately, my IRC session was closed accidentally and I 
lost the comments that Chris and elyograg had made on this issue. So I could 
not add them here. But, the core issue is basically what I have mentioned in 
the description.

In a nutshell:

* I concurred that the reasons given in SOLR-8339 for why the method should be 
deprecated make no sense to me because i didn't see any way the refactoring 
solved the same use case as the method.
* I cautioned that in general, converting from SolrDocument to 
SolrInputDocument isn''t always safe from a client perspective because of 
non-stored fields


Personally: Even though i don't think the reasons given for removing it make 
any sense, I'm not convinced this usage pattern is something should be 
encouraging by adding this functionality back to any public solrj method ... 
ie: +0.

> org.apache.solr.client.solrj.util.ClientUtils.toSolrInputDocument is removed 
> in Solr 6.0 and there is no alternative
> 
>
> Key: SOLR-10637
> URL: https://issues.apache.org/jira/browse/SOLR-10637
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.0
>Reporter: A Bronley
>Priority: Minor
> Attachments: SOLR-10637.patch
>
>
> There is no subtitute available now to convert SolrDocument to 
> SolrInputDocument because 
> org.apache.solr.client.solrj.util.ClientUtils.toSolrInputDocument is removed 
> in Solr 6.0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7540) Upgrade ICU to 58.1

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7540:
-

+1, I think http://bugs.icu-project.org/trac/ticket/12873 was the problem.

> Upgrade ICU to 58.1
> ---
>
> Key: LUCENE-7540
> URL: https://issues.apache.org/jira/browse/LUCENE-7540
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7540.patch, LUCENE-7540.patch
>
>
> ICU is up to 58.1, but our ICU analysis components currently use 56.1, which 
> is ~1 year old by now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7540) Upgrade ICU to 58.1

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7540:


+1, thank you [~jimczi]!

> Upgrade ICU to 58.1
> ---
>
> Key: LUCENE-7540
> URL: https://issues.apache.org/jira/browse/LUCENE-7540
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7540.patch, LUCENE-7540.patch
>
>
> ICU is up to 58.1, but our ICU analysis components currently use 56.1, which 
> is ~1 year old by now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-MacOSX (64bit/jdk1.8.0) - Build # 884 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/884/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:
org.apache.solr.common.SolrException: Collection not found: routeFieldColl
at 
__randomizedtesting.SeedInfo.seed([4672177D552F8DF1:EE4489A0CA4E66AB]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1401)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1094)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter(CustomCollectionTest.java:166)
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 
c

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10700:
-

The _deprecation_ of Postings*Solr*Highlighter (and de-emphasis but still 
present in ref guide) was just committed for 6.6.

The issue title, "Stop using the PostingsHighlighter" is for 7.0.  Later today 
I'll completely remove PostingsHighlighter references from 7.0/master.

> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Houston Putman (JIRA)]

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

Houston Putman updated SOLR-10123:
--
Attachment: SOLR-10123.patch

> 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) 
>Reporter: Houston Putman
>  Labels: features
> Attachments: SOLR-10123.patch
>
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

[Houston Putman (JIRA)]

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

Houston Putman updated SOLR-10123:
--
Description: 
A completely redesigned Analytics Component, introducing the following features:
* Support for distributed collections
* Faceting over mapping functions in addition to fields (Value Faceting)
* PivotFaceting with ValueFacets
* More advanced facet sorting
* Support for PointField types
* Expressions over multi-valued fields
* New types of mapping functions
** Logical
** Conditional
** Comparison
* Concurrent request execution
* Custom user functions, defined within the request

Fully backwards compatible with the orifinal Analytics Component with the 
following exceptions:
* All fields used must have doc-values enabled
* Expression results can no longer be used when defining Range and Query facets
* The reverse(string) mapping function is no longer a native function

  was:
A completely redesigned Analytics Component, introducing the following features:
* Support for distributed collections
* Faceting over mapping functions in addition to fields (Value Faceting)
* Expressions over multi-valued fields
* New types of mapping functions
** Logical
** Conditional
** Comparison
* Concurrent request execution
* Custom user functions, defined within the request

Fully backwards compatible with the orifinal Analytics Component with the 
following exceptions:
* All fields used must have doc-values enabled
* Expression results can no longer be used when defining Range and Query facets
* The reverse(string) mapping function is no longer a native function


> 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) 
>Reporter: Houston Putman
>  Labels: features
>
> A completely redesigned Analytics Component, introducing the following 
> features:
> * Support for distributed collections
> * Faceting over mapping functions in addition to fields (Value Faceting)
> * PivotFaceting with ValueFacets
> * More advanced facet sorting
> * Support for PointField types
> * Expressions over multi-valued fields
> * New types of mapping functions
> ** Logical
> ** Conditional
> ** Comparison
> * Concurrent request execution
> * Custom user functions, defined within the request
> Fully backwards compatible with the orifinal Analytics Component with the 
> following exceptions:
> * All fields used must have doc-values enabled
> * Expression results can no longer be used when defining Range and Query 
> facets
> * The reverse(string) mapping function is no longer a native function



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10700:


Commit f237b8db508bbbaa600a297c57196cd87abd7c0c in lucene-solr's branch 
refs/heads/branch_6_6 from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f237b8d ]

SOLR-10700: Mark PostingsSolrHighlighter as deprecated (code and ref guide)
partially cherry picked from 2218ded

(cherry picked from commit f246717)


> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10700:


Commit f246717ab36611dbb10097cd8b013118c70664b4 in lucene-solr's branch 
refs/heads/branch_6x from [~dsmiley]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f246717 ]

SOLR-10700: Mark PostingsSolrHighlighter as deprecated (code and ref guide)
partially cherry picked from 2218ded


> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7815: Remove more PostingsHighlighter remnants


> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10700:
-

IIUC the changes you made, then yeah ... even if the code is in master for 
backcompat, if it's deprecated/removed/mocked via other code, then there is no 
reason to distract people with it in the ref guide -- we should only doc the 
stuff we actually suggest/recommend that people use.

> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9601) DIH: Radicially simplify Tika example to only show relevant configuration

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: Radicially simplify Tika example to only show relevant configuration
> -
>
> Key: SOLR-9601
> URL: https://issues.apache.org/jira/browse/SOLR-9601
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>  Labels: examples, usability
> Fix For: 6.6, master (7.0)
>
> Attachments: tika2_20170308.tgz, tika2_20170316.tgz
>
>
> Solr DIH examples are legacy examples to show how DIH work. However, they 
> include full configurations that may obscure teaching points. This is no 
> longer needed as we have 3 full-blown examples in the configsets. 
> Specifically for Tika, the field types definitions were at some point 
> simplified to have less support files in the configuration directory. This, 
> however, means that we now have field definitions that have same names as 
> other examples, but different definitions. 
> Importantly, Tika does not use most (any?) of those modified definitions. 
> They are there just for completeness. Similarly, the solrconfig.xml includes 
> extract handler even though we are demonstrating a different path of using 
> Tika. Somebody grepping through config files may get confused about what 
> configuration aspects contributes to what experience.
> I am planning to significantly simplify configuration and schema of Tika 
> example to **only** show DIH Tika extraction path. It will end-up a very 
> short and focused example.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

Jan Høydahl commented on SOLR-9623:
---

I follow that logic, to upper the default limit both in Java and in config, now 
that we disable streaming by default anyway. What is a good value? The number 
2048000 feels a bit like adding zeros to make a big number.. Perhaps 2097152 
(2048 x 1024) could be the new default :-) I could update this patch to make 
that change too.

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7383) DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo possible

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo 
> possible
> 
>
> Key: SOLR-7383
> URL: https://issues.apache.org/jira/browse/SOLR-7383
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.0, 6.0
>Reporter: Upayavira
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: atom_20170315.tgz, rss-data-config.xml, SOLR-7383.patch
>
>
> The DIH example (solr/example/example-DIH/solr/rss/conf/rss-data-config.xml) 
> is broken again. See associated issues.
> Below is a config that should work.
> This is caused by Slashdot seemingly oscillating between RDF/RSS and pure 
> RSS. Perhaps we should depend upon something more static, rather than an 
> external service that is free to change as it desires.
> {code:xml}
> 
> 
> 
>  pk="link"
> url="http://rss.slashdot.org/Slashdot/slashdot";
> processor="XPathEntityProcessor"
> forEach="/RDF/item"
> transformer="DateFormatTransformer">
>   
>  commonField="true" />
>  commonField="true" />
>  commonField="true" />
>   
> 
> 
> 
> 
> 
>  dateTimeFormat="-MM-dd'T'HH:mm:ss" />
> 
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9601) DIH: Radicially simplify Tika example to only show relevant configuration

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: Radicially simplify Tika example to only show relevant configuration
> -
>
> Key: SOLR-9601
> URL: https://issues.apache.org/jira/browse/SOLR-9601
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>  Labels: examples, usability
> Fix For: 6.6, master (7.0)
>
> Attachments: tika2_20170308.tgz, tika2_20170316.tgz
>
>
> Solr DIH examples are legacy examples to show how DIH work. However, they 
> include full configurations that may obscure teaching points. This is no 
> longer needed as we have 3 full-blown examples in the configsets. 
> Specifically for Tika, the field types definitions were at some point 
> simplified to have less support files in the configuration directory. This, 
> however, means that we now have field definitions that have same names as 
> other examples, but different definitions. 
> Importantly, Tika does not use most (any?) of those modified definitions. 
> They are there just for completeness. Similarly, the solrconfig.xml includes 
> extract handler even though we are demonstrating a different path of using 
> Tika. Somebody grepping through config files may get confused about what 
> configuration aspects contributes to what experience.
> I am planning to significantly simplify configuration and schema of Tika 
> example to **only** show DIH Tika extraction path. It will end-up a very 
> short and focused example.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7383) DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo possible

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo 
> possible
> 
>
> Key: SOLR-7383
> URL: https://issues.apache.org/jira/browse/SOLR-7383
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.0, 6.0
>Reporter: Upayavira
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: atom_20170315.tgz, rss-data-config.xml, SOLR-7383.patch
>
>
> The DIH example (solr/example/example-DIH/solr/rss/conf/rss-data-config.xml) 
> is broken again. See associated issues.
> Below is a config that should work.
> This is caused by Slashdot seemingly oscillating between RDF/RSS and pure 
> RSS. Perhaps we should depend upon something more static, rather than an 
> external service that is free to change as it desires.
> {code:xml}
> 
> 
> 
>  pk="link"
> url="http://rss.slashdot.org/Slashdot/slashdot";
> processor="XPathEntityProcessor"
> forEach="/RDF/item"
> transformer="DateFormatTransformer">
>   
>  commonField="true" />
>  commonField="true" />
>  commonField="true" />
>   
> 
> 
> 
> 
> 
>  dateTimeFormat="-MM-dd'T'HH:mm:ss" />
> 
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-7383) DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo possible

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: rewrite XPathEntityProcessor/RSS example as the smallest good demo 
> possible
> 
>
> Key: SOLR-7383
> URL: https://issues.apache.org/jira/browse/SOLR-7383
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 5.0, 6.0
>Reporter: Upayavira
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Fix For: 6.6, master (7.0)
>
> Attachments: atom_20170315.tgz, rss-data-config.xml, SOLR-7383.patch
>
>
> The DIH example (solr/example/example-DIH/solr/rss/conf/rss-data-config.xml) 
> is broken again. See associated issues.
> Below is a config that should work.
> This is caused by Slashdot seemingly oscillating between RDF/RSS and pure 
> RSS. Perhaps we should depend upon something more static, rather than an 
> external service that is free to change as it desires.
> {code:xml}
> 
> 
> 
>  pk="link"
> url="http://rss.slashdot.org/Slashdot/slashdot";
> processor="XPathEntityProcessor"
> forEach="/RDF/item"
> transformer="DateFormatTransformer">
>   
>  commonField="true" />
>  commonField="true" />
>  commonField="true" />
>   
> 
> 
> 
> 
> 
>  dateTimeFormat="-MM-dd'T'HH:mm:ss" />
> 
> 
> 
> 
> 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9601) DIH: Radicially simplify Tika example to only show relevant configuration

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: update DIH docs for SOLR-7383; SOLR-9601; plus major surgery on page 
layout


> DIH: Radicially simplify Tika example to only show relevant configuration
> -
>
> Key: SOLR-9601
> URL: https://issues.apache.org/jira/browse/SOLR-9601
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - DataImportHandler, contrib - Solr Cell (Tika 
> extraction)
>Affects Versions: master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>  Labels: examples, usability
> Fix For: 6.6, master (7.0)
>
> Attachments: tika2_20170308.tgz, tika2_20170316.tgz
>
>
> Solr DIH examples are legacy examples to show how DIH work. However, they 
> include full configurations that may obscure teaching points. This is no 
> longer needed as we have 3 full-blown examples in the configsets. 
> Specifically for Tika, the field types definitions were at some point 
> simplified to have less support files in the configuration directory. This, 
> however, means that we now have field definitions that have same names as 
> other examples, but different definitions. 
> Importantly, Tika does not use most (any?) of those modified definitions. 
> They are there just for completeness. Similarly, the solrconfig.xml includes 
> extract handler even though we are demonstrating a different path of using 
> Tika. Somebody grepping through config files may get confused about what 
> configuration aspects contributes to what experience.
> I am planning to significantly simplify configuration and schema of Tika 
> example to **only** show DIH Tika extraction path. It will end-up a very 
> short and focused example.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Resolved] (SOLR-10721) Provide a way to know when Core Discovery is finished and when all async cores are done loading

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-10721.
---
   Resolution: Fixed
Fix Version/s: 6.7
   master (7.0)

> Provide a way to know when Core Discovery is finished and when all async 
> cores are done loading
> ---
>
> Key: SOLR-10721
> URL: https://issues.apache.org/jira/browse/SOLR-10721
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: master (7.0), 6.7
>
> Attachments: SOLR-10721.patch, SOLR-10721.patch
>
>
> Custom transient core implementations could benefit from knowing two things:
> 1> that core discovery is over
> 2> that all cores that are going to be loaded have been loaded, i.e. all 
> loadOnStartup cores are done.
> It should be trivial to add a method to CoreContainer like "isLoaded" that 
> would answer the first question since you can't get past the load() method 
> without all the cores being discovered. I think this is a more generally 
> useful bit of information than just core discovery is done.
> As for the second, that too seems trivial, just add a method to CoreContainer 
> that returns the number of entries in SolrCores.currentlyLoadingCores.
> I'll add this in a few days unless there are objections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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+168) - Build # 19690 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19690/
Java: 64bit/jdk-9-ea+168 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([3F4DAE0A860A82E4:F6351F6D59C5D525]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
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:563)
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)


FAILED:  
org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder

Error Message:
mismatch: '3'!='4' @ response/docs/[0]/id

Stack Trac

[jira] [Commented] (SOLR-9623) Disable remote streaming by default

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on SOLR-9623:


bq. Changes all multipartUploadLimitInKB="2048000" to 2048

This seems like it's just one more step to get to useable remote streaming that 
won't break when it goes over a magic limit.  If it's disabled by default, 
surely we can have a very high limit, or disable the limit altogether by 
default?

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows

[JIRA]

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

Jan Høydahl commented on SOLR-10735:


+1 to blocker. A regression in such a central feature as {{bin\solr.cmd 
create}} should probably be fixed before a release!

> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace 
> directory names, which is standard on Windows. It does give an error message 
> not while server startup, but when trying to create the techproducts core. I 
> am about to open issue.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4023 - Failure!

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([968E04F0686847E3:1EDA3B2AC6942A1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:159)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:144)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:139)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:910)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:620)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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(Statem

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-10700:
-

So do you suggest I update 6.x & 6.6 ASAP to include the highlighting.adoc 
change I did here... and then on master further remove any mention of the 
PostingsHighlighter?

> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9153) Update beanutils version to 1.9.2

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9153:


[~mdrob] What's your take on this? Should we commit this change?

> Update beanutils version to 1.9.2
> -
>
> Key: SOLR-9153
> URL: https://issues.apache.org/jira/browse/SOLR-9153
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - Velocity
>Affects Versions: 6.0
>Reporter: Mike Drob
>Priority: Minor
> Attachments: SOLR-9153.patch
>
>
> See CVE-2014-0114 -- 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0114
> {quote}
> Apache Commons BeanUtils, as distributed in lib/commons-beanutils-1.8.0.jar 
> in Apache Struts 1.x through 1.3.10 and in other products requiring 
> commons-beanutils through 1.9.2, does not suppress the class property, which 
> allows remote attackers to "manipulate" the ClassLoader and execute arbitrary 
> code via the class parameter, as demonstrated by the passing of this 
> parameter to the getClass method of the ActionForm object in Struts 1. 
> {quote}
> We transitively depend on BeanUtils through Velocity, but it doesn't look 
> like there is much movement on the project there. See BEANUTILS-463 and 
> VELTOOLS-170
> Also, this might have impact on SOLR-3736 but that issue also looks largely 
> abandoned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9623) Disable remote streaming by default

[JIRA]

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

Jan Høydahl updated SOLR-9623:
--
Priority: Blocker  (was: Major)

> Disable remote streaming by default
> ---
>
> Key: SOLR-9623
> URL: https://issues.apache.org/jira/browse/SOLR-9623
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Blocker
>  Labels: configset
> Fix For: master (7.0)
>
> Attachments: SOLR-9623.patch
>
>
> As we set more and more config settings suitable for production use, perhaps 
> it is time to disable remoteStreaming by default, and document how to enable 
> it.
> In all config sets, change into
> {code:xml}
> multipartUploadLimitInKB="2048000"
>formdataUploadLimitInKB="2048"
>addHttpRequestToContext="false"/>
> {code}
> And then consider adding support for it in solr.in.xxx



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10721) Provide a way to know when Core Discovery is finished and when all async cores are done loading

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10721:


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

SOLR-10721: Provide a way to know when Core Discovery is finished and when all 
async cores are done loading

(cherry picked from commit 28b8696)


> Provide a way to know when Core Discovery is finished and when all async 
> cores are done loading
> ---
>
> Key: SOLR-10721
> URL: https://issues.apache.org/jira/browse/SOLR-10721
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10721.patch, SOLR-10721.patch
>
>
> Custom transient core implementations could benefit from knowing two things:
> 1> that core discovery is over
> 2> that all cores that are going to be loaded have been loaded, i.e. all 
> loadOnStartup cores are done.
> It should be trivial to add a method to CoreContainer like "isLoaded" that 
> would answer the first question since you can't get past the load() method 
> without all the cores being discovered. I think this is a more generally 
> useful bit of information than just core discovery is done.
> As for the second, that too seems trivial, just add a method to CoreContainer 
> that returns the number of entries in SolrCores.currentlyLoadingCores.
> I'll add this in a few days unless there are objections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10721) Provide a way to know when Core Discovery is finished and when all async cores are done loading

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10721:


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

SOLR-10721:Provide a way to know when Core Discovery is finished and when all 
async cores are done loading, resolving merge confilct


> Provide a way to know when Core Discovery is finished and when all async 
> cores are done loading
> ---
>
> Key: SOLR-10721
> URL: https://issues.apache.org/jira/browse/SOLR-10721
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10721.patch, SOLR-10721.patch
>
>
> Custom transient core implementations could benefit from knowing two things:
> 1> that core discovery is over
> 2> that all cores that are going to be loaded have been loaded, i.e. all 
> loadOnStartup cores are done.
> It should be trivial to add a method to CoreContainer like "isLoaded" that 
> would answer the first question since you can't get past the load() method 
> without all the cores being discovered. I think this is a more generally 
> useful bit of information than just core discovery is done.
> As for the second, that too seems trivial, just add a method to CoreContainer 
> that returns the number of entries in SolrCores.currentlyLoadingCores.
> I'll add this in a few days unless there are objections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7540) Upgrade ICU to 58.1

[Jim Ferenczi (JIRA)]

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

Jim Ferenczi updated LUCENE-7540:
-
Attachment: LUCENE-7540.patch

[~mikemccand] I ran into the same bug when trying to upgrade icu to 58.1. 
Running ??ant unicode-data?? does not fix the issue. 
Since 59.1 is also out I then tried to upgrade to this new version. This time 
all the tests pass so it might be due to some bug in 58.1 ? 
Here is the patch I used for the upgrade to 59.1.

> Upgrade ICU to 58.1
> ---
>
> Key: LUCENE-7540
> URL: https://issues.apache.org/jira/browse/LUCENE-7540
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7540.patch, LUCENE-7540.patch
>
>
> ICU is up to 58.1, but our ICU analysis components currently use 56.1, which 
> is ~1 year old by now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10721) Provide a way to know when Core Discovery is finished and when all async cores are done loading

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-10721:


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

SOLR-10721: Provide a way to know when Core Discovery is finished and when all 
async cores are done loading


> Provide a way to know when Core Discovery is finished and when all async 
> cores are done loading
> ---
>
> Key: SOLR-10721
> URL: https://issues.apache.org/jira/browse/SOLR-10721
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10721.patch, SOLR-10721.patch
>
>
> Custom transient core implementations could benefit from knowing two things:
> 1> that core discovery is over
> 2> that all cores that are going to be loaded have been loaded, i.e. all 
> loadOnStartup cores are done.
> It should be trivial to add a method to CoreContainer like "isLoaded" that 
> would answer the first question since you can't get past the load() method 
> without all the cores being discovered. I think this is a more generally 
> useful bit of information than just core discovery is done.
> As for the second, that too seems trivial, just add a method to CoreContainer 
> that returns the number of entries in SolrCores.currentlyLoadingCores.
> I'll add this in a few days unless there are objections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10721) Provide a way to know when Core Discovery is finished and when all async cores are done loading

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-10721:
--
Attachment: SOLR-10721.patch

Final patch with CHANGES

> Provide a way to know when Core Discovery is finished and when all async 
> cores are done loading
> ---
>
> Key: SOLR-10721
> URL: https://issues.apache.org/jira/browse/SOLR-10721
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-10721.patch, SOLR-10721.patch
>
>
> Custom transient core implementations could benefit from knowing two things:
> 1> that core discovery is over
> 2> that all cores that are going to be loaded have been loaded, i.e. all 
> loadOnStartup cores are done.
> It should be trivial to add a method to CoreContainer like "isLoaded" that 
> would answer the first question since you can't get past the load() method 
> without all the cores being discovered. I think this is a more generally 
> useful bit of information than just core discovery is done.
> As for the second, that too seems trivial, just add a method to CoreContainer 
> that returns the number of entries in SolrCores.currentlyLoadingCores.
> I'll add this in a few days unless there are objections.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen commented on LUCENE-7810:
---

The change has been backported to 6.6 branch too now.

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: master (7.0), 6.6, 6.7
>
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[Martijn van Groningen (JIRA)]

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

Martijn van Groningen updated LUCENE-7810:
--
Fix Version/s: 6.6

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: master (7.0), 6.6, 6.7
>
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Martijn v Groningen]

Thanks, I've pushed the change to the 6.6 branch.

On Tue, May 23, 2017 at 8:42 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Sure Martijn, please go ahead. Thanks.
>
> On Tue, May 23, 2017 at 11:14 PM, Martijn v Groningen <
> martijn.v.gronin...@gmail.com> wrote:
>
>> Hi Ishan,
>>
>> I like to backport LUCENE-7810 to the 6.6 branch. Is that okay with you?
>>
>> Martijn
>>
>> On Tue, May 23, 2017 at 7:02 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> Thanks Adrien! +1 for the LUCENE-7847 merge.
>>>
>>> On Tue, May 23, 2017 at 10:20 PM, Adrien Grand 
>>> wrote:
>>>
 Hi Ishan,

 I closed LUCENE-7573 which is actually not a problem. We thought it
 would be buggy or at least trappy given another bug that was discovered but
 the merge logic actually uses the doc-values API in a way that there should
 not be problems.

 I took the opportunity of the respin to merge
 https://issues.apache.org/jira/browse/LUCENE-7847 to 6.6, hopefully
 that's ok with you. I can still revert if that does not work for you or if
 you already started building the RC.

 Le lun. 22 mai 2017 à 22:35, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> a écrit :

> * I see that LUCENE-7573 is an outstanding blocker for 6.6, but it
> doesn't have a patch and nor has it been updated since March.
> * I see no other issues marked as a blocker. Can someone aware of the
> issues discussed above please mark them as a blocker if they absolutely
> need to go into 6.6?
>
> If there is no update about LUCENE-7573 or any other blockers (apart
> from LUCENE-7573) in another 24 hours from now, I'm planning to downgrade
> LUCENE-7573 from Blocker to Major and start building the next RC. Please
> let me know if there are any objections.
>
>
> On Fri, May 19, 2017 at 8:14 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> +1 to respin, and have fixes to LUCENE-7833 included.
>> Uwe, I guess the V2 standalone mode issue is SOLR-10711. Do you
>> consider it as a blocker? If so, can we mark it as such on the JIRA? Is
>> there an issue for the Windows space issue?
>> As for SOLR-10004, I don't think it is a release blocker; however a
>> nice one to fix before the re-spin, if possible. I'd be glad to 
>> reconsider,
>> if someone thinks otherwise.
>>
>> On Fri, May 19, 2017 at 6:40 PM, Christine Poerschke (BLOOMBERG/
>> LONDON)  wrote:
>>
>>> The "javadocs want to fail" output sounds like
>>> https://issues.apache.org/jira/browse/SOLR-10004 ticket.
>>>
>>> From: dev@lucene.apache.org At: 05/17/17 18:44:36
>>> To: dev@lucene.apache.org
>>> Subject: Re: [VOTE] Release Lucene/Solr 6.6.0 RC1
>>>
>>> The smoke tester ended with:
>>>
>>> SUCCESS! [0:59:34.797969]
>>>
>>> However, after looking at some of its output, I see a:
>>>***WARNING***: javadocs want to fail!
>>> Which followed many "missing: ..." messages akin to this:
>>>
>>>   unpack solr-6.6.0-src.tgz...
>>>
>>> make sure no JARs/WARs in src dist...
>>>
>>> run "ant validate documentation-lint"
>>>
>>> run tests w/ Java 8 and testArgs=''...
>>>
>>> generate javadocs w/ Java 8...
>>>
>>>
>>>
>>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/expression/package-summary.html
>>>
>>>   missing: ExpressionFactory
>>>
>>>
>>>
>>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/plugin/package-summary.html
>>>
>>>   missing: AnalyticsStatisticsCollector
>>>
>>>
>>> On Wed, May 17, 2017 at 9:49 AM Ishan Chattopadhyaya <
>>> is...@apache.org> wrote:
>>>
 Please vote for release candidate 1 for Lucene/Solr 6.6.0

 The artifacts can be downloaded from:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
 

 You can run the smoke tester directly with this command:

 python3 -u dev-tools/scripts/smokeTestRelease.py \

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
 

 Here's my +1
 SUCCESS! [0:32:20.501484]

>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>

[jira] [Commented] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[ASF subversion and git services (JIRA)]

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

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

Commit 7f62567609e4ffd3181a9c3e713c9736c6604fa6 in lucene-solr's branch 
refs/heads/branch_6_6 from [~martijn.v.groningen]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7f62567 ]

LUCENE-7810: Fix equals() and hashCode() methods of several join queries.


> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_131) - Build # 908 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/908/
Java: 64bit/jdk1.8.0_131 -XX:-UseCompressedOops -XX:+UseSerialGC

1 tests failed.
FAILED:  
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults

Error Message:
mismatch: 'myid1'!='myid' @ response/docs/[0]/id

Stack Trace:
java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
at 
__randomizedtesting.SeedInfo.seed([A420333032C31835:960A34AECA3D3CEC]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
at 
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
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)




Build Log:
[...truncated 13190 lines...]
   [junit4] Suite: org.apache.solr.schema.TestUseDocValuesAsStored
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\L

[jira] [Commented] (SOLR-10735) Solr is broken when directory with spaces used on Windows

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-10735:
-

While I have some time before I spin the next RC, I'm looking to reproduce 
this. I may or may not be able to fix it in time for the next RC, unless 
someone feels this should be a blocker.

> Solr is broken when directory with spaces used on Windows
> -
>
> Key: SOLR-10735
> URL: https://issues.apache.org/jira/browse/SOLR-10735
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.5
>Reporter: Ishan Chattopadhyaya
>
> [~thetaphi] mentioned this in the 6.6 RC1 voting thread:
> {code}
> The startup script (Windows at least) again does not work with whitepsace 
> directory names, which is standard on Windows. It does give an error message 
> not while server startup, but when trying to create the techproducts core. I 
> am about to open issue.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Ishan Chattopadhyaya]

Uwe,
I've filed SOLR-10735  for
the first issue you reported.
Thanks,
Ishan

On Fri, May 19, 2017 at 12:30 PM, Uwe Schindler  wrote:

> I tried,
>
> the 6.6 branch and this test release has 2 problems:
>
>
>
>- The startup script (Windows at least) again does not work with
>whitepsace directory names, which is standard on Windows. It does give an
>error message not while server startup, but when trying to create the
>techproducts core. I am about to open issue.
>- The Solr v2 API returns an error if you go to root entry point in
>standalone mode. This is bad user experience.
>
>
>
> Both issues also affect 6.5, too. On 6.5 the startup script does not work
> at all, it does not even give an error message when trying to start a node.
> I was just not able to test this during the release candidate
>
>
>
> -1 and let’s respin.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Ishan Chattopadhyaya [mailto:is...@apache.org]
> *Sent:* Wednesday, May 17, 2017 3:50 PM
> *To:* dev@lucene.apache.org
> *Subject:* [VOTE] Release Lucene/Solr 6.6.0 RC1
>
>
>
> Please vote for release candidate 1 for Lucene/Solr 6.6.0
>
>
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
> 
>
>
>
> You can run the smoke tester directly with this command:
>
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
> 
>
>
>
> Here's my +1
>
> SUCCESS! [0:32:20.501484]
>

[jira] [Created] (SOLR-10735) Solr is broken when directory with spaces used on Windows

[Ishan Chattopadhyaya (JIRA)]

Ishan Chattopadhyaya created SOLR-10735:
---

 Summary: Solr is broken when directory with spaces used on Windows
 Key: SOLR-10735
 URL: https://issues.apache.org/jira/browse/SOLR-10735
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.5
Reporter: Ishan Chattopadhyaya


[~thetaphi] mentioned this in the 6.6 RC1 voting thread:

{code}
The startup script (Windows at least) again does not work with whitepsace 
directory names, which is standard on Windows. It does give an error message 
not while server startup, but when trying to create the techproducts core. I am 
about to open issue.
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10233) Add support for different replica types in Solr

[JIRA]

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

Tomás Fernández Löbbe commented on SOLR-10233:
--

Thanks Steve, looking into fixing that. 

> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master (7.0)
>
> Attachments: 11431.consoleText.txt, SOLR-10233.patch, 
> SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's  distributed indexing is 
> great. There is a subset of use cases for which the legacy Master/Slave 
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their 
> transaction log. This Jira is to extend that idea and provide the following 
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas 
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica 
> can become a leader. This is the only type supported in SolrCloud at this 
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication. 
> Any _append_ replica can become leader (by first applying all local 
> transaction log elements). If a replica is of type _append_ but is also the 
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is 
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from 
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders 
> (i.e., if there are only passive replicas in the collection at some point, 
> updates will fail same as if there is no leaders, queries continue to work), 
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute 
> it to all _realtime_ and _append_ replicas, the same as it does today. It 
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an 
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with 
> most of its benefits, including high availability of writes. 
> h2. API (v1 style)
> {{/admin/collections?action=CREATE…&*realtimeReplicas=X&appendReplicas=Y&passiveReplicas=Z*}}
> {{/admin/collections?action=ADDREPLICA…&*type=\[realtime/append/passive\]*}}
> * “replicationFactor=” will translate to “realtime=“ for back compatibility
> * if _passive_ > 0, _append_ or _realtime_ need to be >= 1 (can’t be all 
> passives)
> h2. Placement Strategies
> By using replica placement rules, one should be able to dedicate nodes to 
> search-only and write-only workloads. For example:
> {code}
> shard:*,replica:*,type:passive,fleet:slaves
> {code}
> where “type” is a new condition supported by the rule engine, and 
> “fleet:slaves” is a regular tag. Note that rules are only applied when the 
> replicas are created, so a later change in tags won't affect existing 
> replicas. Also, rules are per collection, so each collection could contain 
> it's own different rules.
> Note that on the server side Solr also needs to know how to distribute the 
> shard requests (maybe ShardHandler?) if we want to hit only a subset of 
> replicas (i.e. *passive *replicas only, or similar rules)
> h2. SolrJ
> SolrCloud client could be smart to prefer _passive_ replicas for search 
> requests when available (and if configured to do so). _Passive_ replicas 
> can’t respond RTG requests, so those should go to _realtime_ replicas. 
> h2. Cluster/Collection state
> {code}
> {"gettingstarted":{
>   "replicationFactor":"1",
>   "router":{"name":"compositeId"},
>   "maxShardsPerNode":"2",
>   "autoAddReplicas":"false",
>   "shards":{
> "shard1":{
>   "range":"8000-",
>   "state":"active",
>   "replicas":{
> "core_node5":{
>   "core":"gettingstarted_shard1_replica1",
>   "base_url":"http://127.0.0.1:8983/solr";,
>   "node_name":"127.0.0.1:8983_solr",
>   "state":"active",
>   "leader":"true",
>   **"type": "realtime"**},
> "core_node10":{
>   "core":"gettingstarted_shard1_replica2",
>   "base_url":"http://127.0.0.1:7574/solr";,
>   "node_name":"127.0.0.1:7574_solr",
>   "s

[jira] [Commented] (SOLR-10700) In 7.0 stop using the PostingsHighlighter

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10700:
-

David: if {{hl.method=postings}} is deprecated in 6x then why mention it in the 
master ref-guide at all?

> In 7.0 stop using the PostingsHighlighter
> -
>
> Key: SOLR-10700
> URL: https://issues.apache.org/jira/browse/SOLR-10700
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: SOLR_10700_Stop_using_PostingsHighlighter.patch, 
> SOLR_10700_Stop_using_PostingsHighlighter.patch
>
>
> In 7.0 we should stop using the PostingsHighlighter (see LUCENE-7815 wherein 
> it may not even exist anymore).  Instead we can mark it deprecated and 
> configure the UnifiedHighlighter to behave like the PostingsHighlighter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7815:
--

Hmmm ... ok, i guess i'm confused by the distinction, but i'll ask my followup 
question in SOLR-10700

> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Ishan Chattopadhyaya]

Sure Martijn, please go ahead. Thanks.

On Tue, May 23, 2017 at 11:14 PM, Martijn v Groningen <
martijn.v.gronin...@gmail.com> wrote:

> Hi Ishan,
>
> I like to backport LUCENE-7810 to the 6.6 branch. Is that okay with you?
>
> Martijn
>
> On Tue, May 23, 2017 at 7:02 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Thanks Adrien! +1 for the LUCENE-7847 merge.
>>
>> On Tue, May 23, 2017 at 10:20 PM, Adrien Grand  wrote:
>>
>>> Hi Ishan,
>>>
>>> I closed LUCENE-7573 which is actually not a problem. We thought it
>>> would be buggy or at least trappy given another bug that was discovered but
>>> the merge logic actually uses the doc-values API in a way that there should
>>> not be problems.
>>>
>>> I took the opportunity of the respin to merge https://issues.apache.org/
>>> jira/browse/LUCENE-7847 to 6.6, hopefully that's ok with you. I can
>>> still revert if that does not work for you or if you already started
>>> building the RC.
>>>
>>> Le lun. 22 mai 2017 à 22:35, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> a écrit :
>>>
 * I see that LUCENE-7573 is an outstanding blocker for 6.6, but it
 doesn't have a patch and nor has it been updated since March.
 * I see no other issues marked as a blocker. Can someone aware of the
 issues discussed above please mark them as a blocker if they absolutely
 need to go into 6.6?

 If there is no update about LUCENE-7573 or any other blockers (apart
 from LUCENE-7573) in another 24 hours from now, I'm planning to downgrade
 LUCENE-7573 from Blocker to Major and start building the next RC. Please
 let me know if there are any objections.


 On Fri, May 19, 2017 at 8:14 PM, Ishan Chattopadhyaya <
 ichattopadhy...@gmail.com> wrote:

> +1 to respin, and have fixes to LUCENE-7833 included.
> Uwe, I guess the V2 standalone mode issue is SOLR-10711. Do you
> consider it as a blocker? If so, can we mark it as such on the JIRA? Is
> there an issue for the Windows space issue?
> As for SOLR-10004, I don't think it is a release blocker; however a
> nice one to fix before the re-spin, if possible. I'd be glad to 
> reconsider,
> if someone thinks otherwise.
>
> On Fri, May 19, 2017 at 6:40 PM, Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
>
>> The "javadocs want to fail" output sounds like
>> https://issues.apache.org/jira/browse/SOLR-10004 ticket.
>>
>> From: dev@lucene.apache.org At: 05/17/17 18:44:36
>> To: dev@lucene.apache.org
>> Subject: Re: [VOTE] Release Lucene/Solr 6.6.0 RC1
>>
>> The smoke tester ended with:
>>
>> SUCCESS! [0:59:34.797969]
>>
>> However, after looking at some of its output, I see a:
>>***WARNING***: javadocs want to fail!
>> Which followed many "missing: ..." messages akin to this:
>>
>>   unpack solr-6.6.0-src.tgz...
>>
>> make sure no JARs/WARs in src dist...
>>
>> run "ant validate documentation-lint"
>>
>> run tests w/ Java 8 and testArgs=''...
>>
>> generate javadocs w/ Java 8...
>>
>>
>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff
>> 06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-
>> analytics/org/apache/solr/analytics/expression/package-summary.html
>>
>>   missing: ExpressionFactory
>>
>>
>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff
>> 06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-
>> analytics/org/apache/solr/analytics/plugin/package-summary.html
>>
>>   missing: AnalyticsStatisticsCollector
>>
>>
>> On Wed, May 17, 2017 at 9:49 AM Ishan Chattopadhyaya <
>> is...@apache.org> wrote:
>>
>>> Please vote for release candidate 1 for Lucene/Solr 6.6.0
>>>
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
>>> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
>>> 
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
>>> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
>>> 
>>>
>>> Here's my +1
>>> SUCCESS! [0:32:20.501484]
>>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
>> solrenterprisesearchserver.com
>>
>>
>

>>

[jira] [Resolved] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[David Smiley (JIRA)]

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

David Smiley resolved LUCENE-7815.
--
Resolution: Fixed

> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7815: Removed the PostingsHighlighter


> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7815:
--

[~hossman] I think you meant for your comment to be on SOLR-10700 and on that 
issue I did update highlighting.adoc.

> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-10238) Remove LatLonType in 7.0; replaced by LatLonPointSpatialField

[David Smiley (JIRA)]

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

David Smiley closed SOLR-10238.
---
Resolution: Won't Fix

Marking as won't-fix.  We can outright remove this and other spatial fields I 
deprecated today in the future for 8.0.

RE example: I was kinda hoping [~arafalov] would (eventually) massively slim 
down our example configs to not even have what aren't being demonstrated in the 
sample in question.  But we needn't wait for that.

> Remove LatLonType in 7.0; replaced by LatLonPointSpatialField
> -
>
> Key: SOLR-10238
> URL: https://issues.apache.org/jira/browse/SOLR-10238
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
>
> LatLonPointSpatialField is about to land in SOLR-10039.  This field is 
> superior to LatLonType.  In 7.0, lets remove LatLonType and mark it 
> deprecated in 6.x?  Or must this wait yet another release cycle?
> FYI RPT fields still have life in them due to their ability to index 
> non-point shapes, handle custom (user coded ) shapes, and heatmaps, and are 
> not limited to a lat-lon coordinate space.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7815) Remove PostingsHighlighter in 7.0

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7815:
--

david: now that the ref-guide is in git, can you please make sure to remove 
mentions of the PostingsHighlither from the asciidoc files as well when you 
commit these changes to master?

> Remove PostingsHighlighter in 7.0
> -
>
> Key: LUCENE-7815
> URL: https://issues.apache.org/jira/browse/LUCENE-7815
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/highlighter
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
> Attachments: LUCENE_7815_Remove_PostingsHighlighter.patch, 
> LUCENE_7815_Remove_PostingsHighlighter.patch
>
>
> The UnifiedHighlighter is derived from the PostingsHighlighter, which should 
> be quite obvious to anyone who cares to look at them.  There is no feature in 
> the PH that is not also present in the UH.  The PH is marked as 
> {{lucene.experimental}} so we may remove it in 7.0.  The upgrade path is 
> pretty easy given the API similarity.  By removing the PH, the goal is to 
> ease maintenance.  Some issues lately have been applicable to both of these 
> highlighters which is annoying to apply twice.  In one case I forgot to.  And 
> of course there is user confusion by having both.
> What I propose to do in this issue is move {{CustomSeparatorBreakIterator}} 
> and {{WholeBreakIterator}} out of the {{postingshighlight}} package into the 
> {{uhighlight}} package (or perhaps add a {{common}} or {{util}} should future 
> highlighters need them?).  Then of course remove {{postingshighlight}} 
> package.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10238) Remove LatLonType in 7.0; replaced by LatLonPointSpatialField

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10238:
-

bq. I think it would be too soon. AFAIK we try to keep index back compatibility 
...

yeah, that's also my concern -- people who have built indexes with 6.x should 
be able to use them in 7.0,which means keeping all the solr FieldType's around.

But we can/should certainly remove any mention of them from the master ref 
guide and sample schema (looks like it's still mentioned in example/files and 
example/example-DIH)

> Remove LatLonType in 7.0; replaced by LatLonPointSpatialField
> -
>
> Key: SOLR-10238
> URL: https://issues.apache.org/jira/browse/SOLR-10238
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: spatial
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: master (7.0)
>
>
> LatLonPointSpatialField is about to land in SOLR-10039.  This field is 
> superior to LatLonType.  In 7.0, lets remove LatLonType and mark it 
> deprecated in 6.x?  Or must this wait yet another release cycle?
> FYI RPT fields still have life in them due to their ability to index 
> non-point shapes, handle custom (user coded ) shapes, and heatmaps, and are 
> not limited to a lat-lon coordinate space.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-10731) Add knn Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-10731:
-

Assignee: Joel Bernstein

> Add knn Streaming Expression
> 
>
> Key: SOLR-10731
> URL: https://issues.apache.org/jira/browse/SOLR-10731
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10731.patch
>
>
> The *knn* Streaming Expression will use the MLTQueryParser to return the 
> k nearest neighbors for a document. This will support knn classification and 
> regression use cases.
> Syntax:
> {code}
> knn(collection, docId="doc1", k="10", ...)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-10731) Add knn Streaming Expression

[Joel Bernstein (JIRA)]

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

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

Basic implementation without tests.

> Add knn Streaming Expression
> 
>
> Key: SOLR-10731
> URL: https://issues.apache.org/jira/browse/SOLR-10731
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Fix For: master (7.0)
>
> Attachments: SOLR-10731.patch
>
>
> The *knn* Streaming Expression will use the MLTQueryParser to return the 
> k nearest neighbors for a document. This will support knn classification and 
> regression use cases.
> Syntax:
> {code}
> knn(collection, docId="doc1", k="10", ...)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10338:
-

no major concerns.

minor concerns...

* the {{log.info}} about java.security.egd being null should probably be a 
warning
** shouldn't there *also* be a warning if java.security.egd is non-null but not 
equals to {{"file:/dev/./urandom"}} ?
* shouldn't the very first thing in the assertion failure message be a 
suggestion to try setting  {{-Djava.security.egd=file:/dev/./urandom}} and only 
if that doesn't work use the {{test.solr}} property to disable these checks?
* I'd feel more comfortable with something like the {{final String allowed = 
System.getProperty("test.solr.allowed.securerandom");}} and associated 
validation/logging in the snipped i suggested above (instead of a simple 
{{Boolean.parseBoolean(System.getProperty("test.solr.allow.any.securerandom","false")}})
** same amount of work from an end user to bypass the checks (add 1 sys prop 
they cut and past from failure msg)
** would help ensure that if/when they do bypass with that system property, 
they'll get an error to revisit that decision if/when something happens to 
change the SecureRandom in the future (ie: perhaps later upgrade their JVM, or 
change how they run the tests such that our attempts at setting 
"java.security.egd" start working) 
** ie: i'd rather they get a nice error that they said they expect to be 
running algortihm=foo, but it's not so maybe they should remove the 
"test.solr.allowed.securerandom" and try setting "java.security.egd" again then 
just silently be using a blocking SecureRandom forever.
* even if nothing else changes, the quick {{return}} if the user has disabled 
these checks (with whatever {{test.solr}} sysprop we use) should probably 
log something about bypassing the non-blocking SecureRandom checks.

> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch, SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Release planning for 7.0

[Shawn Heisey]

On 5/23/2017 9:14 AM, Erick Erickson wrote:
> Do others expect there to be a 6.7 release? I'm guessing there'll be a
> 6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
> we want to put a bow on the 6x code line.
>
> Really a plea for people not to assume that the 6x code line is
> moribund for a bit, and merge changes into 6x if it's easy. Up to
> individuals of course.

What is our plan for legacy numerics in Solr 7.0?  Looking at the
example configs in branch_6x, I see that they have been partially
converted to the point field types, but not fully.  The _version_ field
and many dynamic fields are still using Trie types.

If legacy numerics disappear from Solr 7.0 (since normal deprecation
rules indicate they will be gone from Lucene 7.0), very few 6.x users
will be able to upgrade to 7.0 without redesigning and completely
rebuilding their indexes.

Regarding Adrien's concern, if the index format doesn't change and
existing analysis components don't do anything radically different, it
should be pretty safe to fix minor problems and backport self-contained
features in 6.x releases after 7.0 hits.

Thanks,
Shawn


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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Martijn v Groningen]

Hi Ishan,

I like to backport LUCENE-7810 to the 6.6 branch. Is that okay with you?

Martijn

On Tue, May 23, 2017 at 7:02 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Thanks Adrien! +1 for the LUCENE-7847 merge.
>
> On Tue, May 23, 2017 at 10:20 PM, Adrien Grand  wrote:
>
>> Hi Ishan,
>>
>> I closed LUCENE-7573 which is actually not a problem. We thought it would
>> be buggy or at least trappy given another bug that was discovered but the
>> merge logic actually uses the doc-values API in a way that there should not
>> be problems.
>>
>> I took the opportunity of the respin to merge
>> https://issues.apache.org/jira/browse/LUCENE-7847 to 6.6, hopefully
>> that's ok with you. I can still revert if that does not work for you or if
>> you already started building the RC.
>>
>> Le lun. 22 mai 2017 à 22:35, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> a écrit :
>>
>>> * I see that LUCENE-7573 is an outstanding blocker for 6.6, but it
>>> doesn't have a patch and nor has it been updated since March.
>>> * I see no other issues marked as a blocker. Can someone aware of the
>>> issues discussed above please mark them as a blocker if they absolutely
>>> need to go into 6.6?
>>>
>>> If there is no update about LUCENE-7573 or any other blockers (apart
>>> from LUCENE-7573) in another 24 hours from now, I'm planning to downgrade
>>> LUCENE-7573 from Blocker to Major and start building the next RC. Please
>>> let me know if there are any objections.
>>>
>>>
>>> On Fri, May 19, 2017 at 8:14 PM, Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 +1 to respin, and have fixes to LUCENE-7833 included.
 Uwe, I guess the V2 standalone mode issue is SOLR-10711. Do you
 consider it as a blocker? If so, can we mark it as such on the JIRA? Is
 there an issue for the Windows space issue?
 As for SOLR-10004, I don't think it is a release blocker; however a
 nice one to fix before the re-spin, if possible. I'd be glad to reconsider,
 if someone thinks otherwise.

 On Fri, May 19, 2017 at 6:40 PM, Christine Poerschke (BLOOMBERG/
 LONDON)  wrote:

> The "javadocs want to fail" output sounds like
> https://issues.apache.org/jira/browse/SOLR-10004 ticket.
>
> From: dev@lucene.apache.org At: 05/17/17 18:44:36
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Release Lucene/Solr 6.6.0 RC1
>
> The smoke tester ended with:
>
> SUCCESS! [0:59:34.797969]
>
> However, after looking at some of its output, I see a:
>***WARNING***: javadocs want to fail!
> Which followed many "missing: ..." messages akin to this:
>
>   unpack solr-6.6.0-src.tgz...
>
> make sure no JARs/WARs in src dist...
>
> run "ant validate documentation-lint"
>
> run tests w/ Java 8 and testArgs=''...
>
> generate javadocs w/ Java 8...
>
>
>
> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/expression/package-summary.html
>
>   missing: ExpressionFactory
>
>
>
> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/plugin/package-summary.html
>
>   missing: AnalyticsStatisticsCollector
>
>
> On Wed, May 17, 2017 at 9:49 AM Ishan Chattopadhyaya 
> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 6.6.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
>> 
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
>> 
>>
>> Here's my +1
>> SUCCESS! [0:32:20.501484]
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>

>>>
>

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6580/
Java: 64bit/jdk1.8.0_131 -XX:+UseCompressedOops -XX:+UseSerialGC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([57B9EACF23CE8733:9EC15BA8FC01D0F2]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
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)


FAILED:  
org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder

Error Message:
mismatch: '3'!='4' @ 

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/19689/
Java: 64bit/jdk-9-ea+168 -XX:-UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest

Error Message:
mismatch: '0.09271725'!='0.105360515' @ response/docs/[3]/score

Stack Trace:
java.lang.RuntimeException: mismatch: '0.09271725'!='0.105360515' @ 
response/docs/[3]/score
at 
__randomizedtesting.SeedInfo.seed([65AEAE32032811B9:ACD61F55DCE74678]:0)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:248)
at org.apache.solr.util.RestTestBase.assertJQ(RestTestBase.java:192)
at 
org.apache.solr.ltr.TestLTRQParserPlugin.ltrMoreResultsThanReRankedTest(TestLTRQParserPlugin.java:94)
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:563)
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)


FAILED:  
org.apache.solr.ltr.TestParallelWeightCreation.testLTRScoringQueryParallelWeightCreationResultOrder

Error Message:
mismatch: '3'!='4' @ response/docs/[0]/id

Stack Trac

[jira] [Updated] (SOLR-10233) Add support for different replica types in Solr

[Anshum Gupta (JIRA)]

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

Anshum Gupta updated SOLR-10233:

Fix Version/s: master (7.0)

> Add support for different replica types in Solr
> ---
>
> Key: SOLR-10233
> URL: https://issues.apache.org/jira/browse/SOLR-10233
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
> Fix For: master (7.0)
>
> Attachments: 11431.consoleText.txt, SOLR-10233.patch, 
> SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch, SOLR-10233.patch
>
>
> For the majority of the cases, current SolrCloud's  distributed indexing is 
> great. There is a subset of use cases for which the legacy Master/Slave 
> replication may fit better:
> * Don’t require NRT
> * LIR can become an issue, prefer availability of reads vs consistency or NRT
> * High number of searches (requiring many search nodes)
> SOLR-9835 is adding replicas that don’t do indexing, just update their 
> transaction log. This Jira is to extend that idea and provide the following 
> replica types:
> * *Realtime:* Writes updates to transaction log and indexes locally. Replicas 
> of type “realtime” support NRT (soft commits) and RTG. Any _realtime_ replica 
> can become a leader. This is the only type supported in SolrCloud at this 
> time and will be the default.
> * *Append:* Writes to transaction log, but not to index, uses replication. 
> Any _append_ replica can become leader (by first applying all local 
> transaction log elements). If a replica is of type _append_ but is also the 
> leader, it will behave as a _realtime_. This is exactly what SOLR-9835 is 
> proposing (non-live replicas)
> * *Passive:* Doesn’t index or writes to transaction log. Just replicates from 
> _realtime_ or _append_ replicas. Passive replicas can’t become shard leaders 
> (i.e., if there are only passive replicas in the collection at some point, 
> updates will fail same as if there is no leaders, queries continue to work), 
> so they don’t even participate in elections.
> When the leader replica of the shard receives an update, it will distribute 
> it to all _realtime_ and _append_ replicas, the same as it does today. It 
> won't distribute to _passive_ replicas.
> By using a combination of _append_ and _passive_ replicas, one can achieve an 
> equivalent of the legacy Master/Slave architecture in SolrCloud mode with 
> most of its benefits, including high availability of writes. 
> h2. API (v1 style)
> {{/admin/collections?action=CREATE…&*realtimeReplicas=X&appendReplicas=Y&passiveReplicas=Z*}}
> {{/admin/collections?action=ADDREPLICA…&*type=\[realtime/append/passive\]*}}
> * “replicationFactor=” will translate to “realtime=“ for back compatibility
> * if _passive_ > 0, _append_ or _realtime_ need to be >= 1 (can’t be all 
> passives)
> h2. Placement Strategies
> By using replica placement rules, one should be able to dedicate nodes to 
> search-only and write-only workloads. For example:
> {code}
> shard:*,replica:*,type:passive,fleet:slaves
> {code}
> where “type” is a new condition supported by the rule engine, and 
> “fleet:slaves” is a regular tag. Note that rules are only applied when the 
> replicas are created, so a later change in tags won't affect existing 
> replicas. Also, rules are per collection, so each collection could contain 
> it's own different rules.
> Note that on the server side Solr also needs to know how to distribute the 
> shard requests (maybe ShardHandler?) if we want to hit only a subset of 
> replicas (i.e. *passive *replicas only, or similar rules)
> h2. SolrJ
> SolrCloud client could be smart to prefer _passive_ replicas for search 
> requests when available (and if configured to do so). _Passive_ replicas 
> can’t respond RTG requests, so those should go to _realtime_ replicas. 
> h2. Cluster/Collection state
> {code}
> {"gettingstarted":{
>   "replicationFactor":"1",
>   "router":{"name":"compositeId"},
>   "maxShardsPerNode":"2",
>   "autoAddReplicas":"false",
>   "shards":{
> "shard1":{
>   "range":"8000-",
>   "state":"active",
>   "replicas":{
> "core_node5":{
>   "core":"gettingstarted_shard1_replica1",
>   "base_url":"http://127.0.0.1:8983/solr";,
>   "node_name":"127.0.0.1:8983_solr",
>   "state":"active",
>   "leader":"true",
>   **"type": "realtime"**},
> "core_node10":{
>   "core":"gettingstarted_shard1_replica2",
>   "base_url":"http://127.0.0.1:7574/solr";,
>   "node_name":"127.0.0.1:7574_solr",
>   "state":"active",
>   **"type": "passive"**}},
>   }},
> "shard2":{
>  

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-10338:


I like this approach. I have to finish testing it, mostly with Java 9, but I 
like this. Any concerns [~hossman]?

> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
> Fix For: 6.6, master (7.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch, SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10728) fix/improve rat-sources and check-forbidden-api in solr-ref-guide

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-10728:
-

bq.  I suggest to use the same layout for the ref guide: src/docs (or src/main) 
and src/tools/java. When you have main, test and tools you have 3 types of 
source files.

Ok ... gotcha ... {{src/docs}} is the part i wasn't clear on before ... you 
mentioned setting it up to match other modules, and having a {{src/.../java}} 
but the ref-guide is different then every other module becuase there is no 
"main source java" -- just the tools.  so i was trying to figure out where you 
wanted to shoehorn the {{\*.adoc}} files into the {{src/(java|test|tools)}} 
convention we use everywhere else ... adding "src/docs" clears that up

FWIW: I experimented locally with this (moving everything in {{src}} to 
{{src/docs}} and {{tools}} to {{src/tools}}) and making the minor tweaks needed 
to the build.xml to get the html & pdf builds to work, but that still didn't 
make {{ant check-forbidden-apis}} happy because there's still no {{src/java}} 
... which is the same error as before i tried re-orging files (hence my 
confusion and vague concern that maybe you ment we should put the {{\*.adoc}} 
files in {{src/java}} to "fix" this) ... so i abandoned that.

bq. I can look into this!

That would be awesome, because i just keep confusing myself as i try to unravel 
the build targets ... if/when you get a chance to take a look at it, feel free 
to ping me if you have any questions/concerns about where/how/why any of the 
solr-ref-guide specific build targets/tools work.

> fix/improve rat-sources and check-forbidden-api in solr-ref-guide
> -
>
> Key: SOLR-10728
> URL: https://issues.apache.org/jira/browse/SOLR-10728
> Project: Solr
>  Issue Type: Sub-task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation
>Reporter: Hoss Man
>Assignee: Uwe Schindler
>
> via email from uwe...
> {noformat}
> We have already a check for licenses by default enabled in all sub 
> directories of the build. It's called "rat-sources"
> The problem with the rat-sources ant target is, that although it runs on the 
> ref-guide subdirectory, it does not catch
> violations for several reasons:
> 1. it does not yet look into all file types
> 2. for some files, e.g. the java code, you are using a non-standard 
> subdirectory of the project folder. To fix this, there are
> two options: a) move to src/.../java or tools like in other modules (by that 
> they are also compiled automatically without extra
> compilation tasks in build.xml) or b) add the additional directories  to some 
> special ANT property _before_ loading
> common-build.xml:
>   
>   
>   
> In the local build, you can configure the license checker by adding those 
> lines fillesd out *before* including
> common-build.xml. If you open an issue, I can maybe take care of that this 
> week (I am a bit busy). I'd also like to clean up
> the build directory, because it has some code duplication automatically 
> handled by common-build.xml. In addition other checks
> are missing, too - because the non-standard folder names (e.g. 
> forbidden-apis).
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Ishan Chattopadhyaya]

Thanks Adrien! +1 for the LUCENE-7847 merge.

On Tue, May 23, 2017 at 10:20 PM, Adrien Grand  wrote:

> Hi Ishan,
>
> I closed LUCENE-7573 which is actually not a problem. We thought it would
> be buggy or at least trappy given another bug that was discovered but the
> merge logic actually uses the doc-values API in a way that there should not
> be problems.
>
> I took the opportunity of the respin to merge https://issues.apache.org/
> jira/browse/LUCENE-7847 to 6.6, hopefully that's ok with you. I can still
> revert if that does not work for you or if you already started building the
> RC.
>
> Le lun. 22 mai 2017 à 22:35, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> a écrit :
>
>> * I see that LUCENE-7573 is an outstanding blocker for 6.6, but it
>> doesn't have a patch and nor has it been updated since March.
>> * I see no other issues marked as a blocker. Can someone aware of the
>> issues discussed above please mark them as a blocker if they absolutely
>> need to go into 6.6?
>>
>> If there is no update about LUCENE-7573 or any other blockers (apart from
>> LUCENE-7573) in another 24 hours from now, I'm planning to downgrade
>> LUCENE-7573 from Blocker to Major and start building the next RC. Please
>> let me know if there are any objections.
>>
>>
>> On Fri, May 19, 2017 at 8:14 PM, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> +1 to respin, and have fixes to LUCENE-7833 included.
>>> Uwe, I guess the V2 standalone mode issue is SOLR-10711. Do you consider
>>> it as a blocker? If so, can we mark it as such on the JIRA? Is there an
>>> issue for the Windows space issue?
>>> As for SOLR-10004, I don't think it is a release blocker; however a nice
>>> one to fix before the re-spin, if possible. I'd be glad to reconsider, if
>>> someone thinks otherwise.
>>>
>>> On Fri, May 19, 2017 at 6:40 PM, Christine Poerschke (BLOOMBERG/ LONDON)
>>>  wrote:
>>>
 The "javadocs want to fail" output sounds like
 https://issues.apache.org/jira/browse/SOLR-10004 ticket.

 From: dev@lucene.apache.org At: 05/17/17 18:44:36
 To: dev@lucene.apache.org
 Subject: Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

 The smoke tester ended with:

 SUCCESS! [0:59:34.797969]

 However, after looking at some of its output, I see a:
***WARNING***: javadocs want to fail!
 Which followed many "missing: ..." messages akin to this:

   unpack solr-6.6.0-src.tgz...

 make sure no JARs/WARs in src dist...

 run "ant validate documentation-lint"

 run tests w/ Java 8 and testArgs=''...

 generate javadocs w/ Java 8...


 /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff
 06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-
 analytics/org/apache/solr/analytics/expression/package-summary.html

   missing: ExpressionFactory


 /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff
 06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-
 analytics/org/apache/solr/analytics/plugin/package-summary.html

   missing: AnalyticsStatisticsCollector


 On Wed, May 17, 2017 at 9:49 AM Ishan Chattopadhyaya 
 wrote:

> Please vote for release candidate 1 for Lucene/Solr 6.6.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
> 
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-
> rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
> 
>
> Here's my +1
> SUCCESS! [0:32:20.501484]
>
 --
 Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.
 solrenterprisesearchserver.com


>>>
>>

Re: [VOTE] Release Lucene/Solr 6.6.0 RC1

[Adrien Grand]

Hi Ishan,

I closed LUCENE-7573 which is actually not a problem. We thought it would
be buggy or at least trappy given another bug that was discovered but the
merge logic actually uses the doc-values API in a way that there should not
be problems.

I took the opportunity of the respin to merge
https://issues.apache.org/jira/browse/LUCENE-7847 to 6.6, hopefully that's
ok with you. I can still revert if that does not work for you or if you
already started building the RC.

Le lun. 22 mai 2017 à 22:35, Ishan Chattopadhyaya 
a écrit :

> * I see that LUCENE-7573 is an outstanding blocker for 6.6, but it doesn't
> have a patch and nor has it been updated since March.
> * I see no other issues marked as a blocker. Can someone aware of the
> issues discussed above please mark them as a blocker if they absolutely
> need to go into 6.6?
>
> If there is no update about LUCENE-7573 or any other blockers (apart from
> LUCENE-7573) in another 24 hours from now, I'm planning to downgrade
> LUCENE-7573 from Blocker to Major and start building the next RC. Please
> let me know if there are any objections.
>
>
> On Fri, May 19, 2017 at 8:14 PM, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> +1 to respin, and have fixes to LUCENE-7833 included.
>> Uwe, I guess the V2 standalone mode issue is SOLR-10711. Do you consider
>> it as a blocker? If so, can we mark it as such on the JIRA? Is there an
>> issue for the Windows space issue?
>> As for SOLR-10004, I don't think it is a release blocker; however a nice
>> one to fix before the re-spin, if possible. I'd be glad to reconsider, if
>> someone thinks otherwise.
>>
>> On Fri, May 19, 2017 at 6:40 PM, Christine Poerschke (BLOOMBERG/ LONDON)
>>  wrote:
>>
>>> The "javadocs want to fail" output sounds like
>>> https://issues.apache.org/jira/browse/SOLR-10004 ticket.
>>>
>>> From: dev@lucene.apache.org At: 05/17/17 18:44:36
>>> To: dev@lucene.apache.org
>>> Subject: Re: [VOTE] Release Lucene/Solr 6.6.0 RC1
>>>
>>> The smoke tester ended with:
>>>
>>> SUCCESS! [0:59:34.797969]
>>>
>>> However, after looking at some of its output, I see a:
>>>***WARNING***: javadocs want to fail!
>>> Which followed many "missing: ..." messages akin to this:
>>>
>>>   unpack solr-6.6.0-src.tgz...
>>>
>>> make sure no JARs/WARs in src dist...
>>>
>>> run "ant validate documentation-lint"
>>>
>>> run tests w/ Java 8 and testArgs=''...
>>>
>>> generate javadocs w/ Java 8...
>>>
>>>
>>>
>>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/expression/package-summary.html
>>>
>>>   missing: ExpressionFactory
>>>
>>>
>>>
>>> /tmp/smoke_lucene_6.6.0_4d055f00bba9a745737e4b6c3f9dff06dd35aa2e/unpack/solr-6.6.0/solr/build/docs/solr-analytics/org/apache/solr/analytics/plugin/package-summary.html
>>>
>>>   missing: AnalyticsStatisticsCollector
>>>
>>>
>>> On Wed, May 17, 2017 at 9:49 AM Ishan Chattopadhyaya 
>>> wrote:
>>>
 Please vote for release candidate 1 for Lucene/Solr 6.6.0

 The artifacts can be downloaded from:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
 

 You can run the smoke tester directly with this command:

 python3 -u dev-tools/scripts/smokeTestRelease.py \

 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.0-RC1-rev4d055f00bba9a745737e4b6c3f9dff06dd35aa2e
 

 Here's my +1
 SUCCESS! [0:32:20.501484]

>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>>>
>>
>

[jira] [Resolved] (LUCENE-7847) RangeFieldQuery optimization for "all docs match" is broken

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7847.
--
   Resolution: Fixed
Fix Version/s: 6.6
   master (7.0)

> RangeFieldQuery optimization for "all docs match" is broken
> ---
>
> Key: LUCENE-7847
> URL: https://issues.apache.org/jira/browse/LUCENE-7847
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Fix For: master (7.0), 6.6
>
> Attachments: LUCENE-7847.patch, LUCENE-7847.patch
>
>
> RangeFieldQuery tries to detect based on the min/max values of the field 
> whether all values match. However this detection is broken and can sometimes 
> consider that all documents match when they actually don't.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7847) RangeFieldQuery optimization for "all docs match" is broken

[ASF subversion and git services (JIRA)]

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

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

Commit 8db5e5acfae2335a63c3f845158fbcc6d9471677 in lucene-solr's branch 
refs/heads/branch_6x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8db5e5a ]

LUCENE-7847: Fix the all-docs-match optimization of range queries on range 
fields.


> RangeFieldQuery optimization for "all docs match" is broken
> ---
>
> Key: LUCENE-7847
> URL: https://issues.apache.org/jira/browse/LUCENE-7847
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-7847.patch, LUCENE-7847.patch
>
>
> RangeFieldQuery tries to detect based on the min/max values of the field 
> whether all values match. However this detection is broken and can sometimes 
> consider that all documents match when they actually don't.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7847) RangeFieldQuery optimization for "all docs match" is broken

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7847: Fix the all-docs-match optimization of range queries on range 
fields.


> RangeFieldQuery optimization for "all docs match" is broken
> ---
>
> Key: LUCENE-7847
> URL: https://issues.apache.org/jira/browse/LUCENE-7847
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-7847.patch, LUCENE-7847.patch
>
>
> RangeFieldQuery tries to detect based on the min/max values of the field 
> whether all values match. However this detection is broken and can sometimes 
> consider that all documents match when they actually don't.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7847) RangeFieldQuery optimization for "all docs match" is broken

[ASF subversion and git services (JIRA)]

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

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

Commit 5de10a64b1e6e584640e6a7fdb1bbd1ba7e766d7 in lucene-solr's branch 
refs/heads/branch_6_6 from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5de10a6 ]

LUCENE-7847: Fix the all-docs-match optimization of range queries on range 
fields.


> RangeFieldQuery optimization for "all docs match" is broken
> ---
>
> Key: LUCENE-7847
> URL: https://issues.apache.org/jira/browse/LUCENE-7847
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-7847.patch, LUCENE-7847.patch
>
>
> RangeFieldQuery tries to detect based on the min/max values of the field 
> whether all values match. However this detection is broken and can sometimes 
> consider that all documents match when they actually don't.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-6.6 - Build # 11 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.6/11/

4 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

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([5C433B21B2A05C44]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestIndexSorting

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

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


FAILED:  org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly

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

Stack Trace:
java.lang.AssertionError: Unexpected number of elements in the group for 
intGSF: 6
at 
__randomizedtesting.SeedInfo.seed([99AAE6E509AE062F:21188BD44F63471]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:376)
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.

[jira] [Commented] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-7810:
--

Should we backport to branch_6_6 since we are re-spinning?

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Release planning for 7.0

[Erick Erickson]

Adrien:

Right, thus my "if it's easy" clause ;)

I'm not suggesting at all that we go very far down this road, more "if
it merges cleanly and makes sense, backport. Maybe. If you feel like
it".

And I'm _really_ not suggesting that we try to back-port anything that
would make our lives harder, more "let's make 6x as complete as we can
without making development too much more difficult".


Erick



On Tue, May 23, 2017 at 8:47 AM, Adrien Grand  wrote:
> Le mar. 23 mai 2017 à 17:15, Erick Erickson  a
> écrit :
>>
>> Do others expect there to be a 6.7 release? I'm guessing there'll be a
>> 6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
>> we want to put a bow on the 6x code line.
>
>
> Once 7.0 is out, releasing 6.x becomes trickier since we need to make sure
> not only that it can read all previous versions, but also that new versions
> (7.x) can read it. I'm not suggesting we do not do any release at all: we
> should still do bugfix releases when important bugs are discovered. Since
> bugfix releases tend to have contained change logs, it is easier to reason
> about what could go wrong so we just need to be a bit more careful. However
> I think we should avoid releasing new 6.x minor releases once 7.0 is out.

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

Re: Release planning for 7.0

[Joel Bernstein]

I would like to have a 6.7 release if possible, to wrap up some features
for users in the 6x branch.

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, May 23, 2017 at 11:47 AM, Adrien Grand  wrote:

> Le mar. 23 mai 2017 à 17:15, Erick Erickson  a
> écrit :
>
>> Do others expect there to be a 6.7 release? I'm guessing there'll be a
>> 6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
>> we want to put a bow on the 6x code line.
>>
>
> Once 7.0 is out, releasing 6.x becomes trickier since we need to make sure
> not only that it can read all previous versions, but also that new versions
> (7.x) can read it. I'm not suggesting we do not do any release at all: we
> should still do bugfix releases when important bugs are discovered. Since
> bugfix releases tend to have contained change logs, it is easier to reason
> about what could go wrong so we just need to be a bit more careful. However
> I think we should avoid releasing new 6.x minor releases once 7.0 is out.
>

[jira] [Commented] (LUCENE-7810) false positive equality: distinctly diff join queries return equals()==true

[Hoss Man (JIRA)]

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

Hoss Man commented on LUCENE-7810:
--

Looks like jira-bot missed the 6x backport commit...

http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/e30fbd68

> false positive equality: distinctly diff join queries return equals()==true
> ---
>
> Key: LUCENE-7810
> URL: https://issues.apache.org/jira/browse/LUCENE-7810
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Hoss Man
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE_7810.patch, LUCENE_7810.patch, LUCENE-7810.patch
>
>
> While working on SOLR-10583 I was getting some odd test failures that seemed 
> to suggest we were getting false cache hits for Join queries that should have 
> been unique.
> tracing thorugh the code, the problem seems to be the way {{TermsQuery}} 
> implements {{equals(Object)}}.  This class takes in the {{fromQuery}} (used 
> to identify set of documents we "join from") and uses it in the equals 
> calculation -- but the information about the join _field_ is never passed 
> directly to {{TermsQuery}} and the BytesRefs that are passed in can't be 
> compared efficiently (AFAICT), so 2 completely diff calls to 
> {{JoinUtils.createJoinQuery(...)}} can result in Query objects that think 
> they are {{equal()}} even when they most certainly are not.
> At a brief glance, it appears that similar bugs exist in 
> {{TermsIncludingScoreQuery}} (and possibly {{GlobalOrdinalsWithScoreQuery}}, 
> but i didn't look into that class at all)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7847) RangeFieldQuery optimization for "all docs match" is broken

[Nicholas Knize (JIRA)]

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

Nicholas Knize commented on LUCENE-7847:


+1 
Love the simplicity of the scorer and thanks for making the test more evil!

> RangeFieldQuery optimization for "all docs match" is broken
> ---
>
> Key: LUCENE-7847
> URL: https://issues.apache.org/jira/browse/LUCENE-7847
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-7847.patch, LUCENE-7847.patch
>
>
> RangeFieldQuery tries to detect based on the min/max values of the field 
> whether all values match. However this detection is broken and can sometimes 
> consider that all documents match when they actually don't.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9530) Add an Atomic Update Processor

[ASF subversion and git services (JIRA)]

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

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

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

Ref Guide: fix note for atomic updates after SOLR-9530


> Add an Atomic Update Processor 
> ---
>
> Key: SOLR-9530
> URL: https://issues.apache.org/jira/browse/SOLR-9530
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Assignee: Noble Paul
> Fix For: 6.6, master (7.0)
>
> Attachments: assertU(...)-works.png, commit()-doesn't-work.png, 
> SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, 
> SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, 
> SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, SOLR-9530.patch, 
> SOLR-9530.patch, SOLR-9530.patch
>
>
> I'd like to explore the idea of adding a new update processor to help ingest 
> partial updates.
> Example use-case - There are two datasets with a common id field. How can I 
> merge both of them at index time?
> So the first JSON dump could be ingested against 
> {{http://localhost:8983/solr/gettingstarted/update/json}}
> And then the second JSON could be ingested against
> {{http://localhost:8983/solr/gettingstarted/update/json?processor=atomic}}
> The Atomic Update Processor could support all the atomic update operations 
> currently supported.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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