[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-10-ea+29) - Build # 20854 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20854/ Java: 64bit/jdk-10-ea+29 -XX:+UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Error from server at http://127.0.0.1:33309/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:33309/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([A8A3A6945CED8FA6]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.TestCloudRecovery.setupCluster(TestCloudRecovery.java:68) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamingTest Error Message: Error from server at http://127.0.0.1:35459/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:35459/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([E93600AAECA1C3E3]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.ap
[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first
[ https://issues.apache.org/jira/browse/SOLR-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241638#comment-16241638 ] ASF subversion and git services commented on SOLR-11380: Commit b48d87cde07c94e28e3940d52cbd7491ca1427b2 in lucene-solr's branch refs/heads/branch_7x from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b48d87c ] SOLR-11380: deprecated getContentStreams() > SolrJ must stream docs to server instead of writing to a byte[] first > -- > > Key: SOLR-11380 > URL: https://issues.apache.org/jira/browse/SOLR-11380 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11380.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1518 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1518/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream Error Message: expected:<5> but was:<2> Stack Trace: java.lang.AssertionError: expected:<5> but was:<2> at __randomizedtesting.SeedInfo.seed([D9FE25D19D36D025:F91447D101773D69]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream(StreamExpressionTest.java:4594) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 14896 lines...] [junit4] Suite: org.apache.
[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first
[ https://issues.apache.org/jira/browse/SOLR-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241613#comment-16241613 ] ASF subversion and git services commented on SOLR-11380: Commit a03d6bc8c27d3d97011bc5bdc2aeb94c4820628c in lucene-solr's branch refs/heads/master from [~noble.paul] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a03d6bc ] SOLR-11380: deprecated getContentStreams() > SolrJ must stream docs to server instead of writing to a byte[] first > -- > > Key: SOLR-11380 > URL: https://issues.apache.org/jira/browse/SOLR-11380 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11380.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11601) solr.LatLonPointSpatialField : sorting by geodist fails
[
https://issues.apache.org/jira/browse/SOLR-11601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clemens Wyss updated SOLR-11601:
Priority: Blocker (was: Major)
> solr.LatLonPointSpatialField : sorting by geodist fails
> ---
>
> Key: SOLR-11601
> URL: https://issues.apache.org/jira/browse/SOLR-11601
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 6.6
>Reporter: Clemens Wyss
>Priority: Blocker
>
> Im switching my schemas from derprecated solr.LatLonType to
> solr.LatLonPointSpatialField.
> Now my sortquery (which used to work with solr.LatLonType):
> *sort=geodist(b4_location__geo_si,47.36667,8.55) asc*
> raises the error
> {color:red}*"sort param could not be parsed as a query, and is not a field
> that exists in the index: geodist(b4_location__geo_si,47.36667,8.55)"*{color}
> Invoking sort using syntax
> {color:#14892c}sfield=b4_location__geo_si&pt=47.36667,8.55&sort=geodist() asc
> works as expected though...{color}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241563#comment-16241563 ] bidorbuy commented on SOLR-11078: - Thanks for the detailed responses [~dsmiley]. We have switched 7.1.0 into production about 24 hours ago with full production load and although resource utilisation (compare zasolrm03=7.1.0 vs zasolrm02=6.4.0) is higher, response time on queries and QPS is generally faster/higher: !screenshot-3.png! The above is based on using the 6.4.0 schema with Trie* fields on a 7.1.0 installation. The next step is to rebuild a server running 7.1.0, but then switching to StrFields and *Point-fields as mentioned. This will probably take at least a week before we have results, but I will feed back once I have them. > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > screenshot-3.png, solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, > solr-7-1-0-managed-schema, solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, > solr-sample-warning-log.txt, solr.in.sh, solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bidorbuy updated SOLR-11078: Attachment: screenshot-3.png > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > screenshot-3.png, solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, > solr-7-1-0-managed-schema, solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, > solr-sample-warning-log.txt, solr.in.sh, solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11380) SolrJ must stream docs to server instead of writing to a byte[] first
[
https://issues.apache.org/jira/browse/SOLR-11380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241486#comment-16241486
]
David Smiley commented on SOLR-11380:
-
[~noble.paul] it's confusing to me that SolrRequest now has a
{{getContentWriter}} method which now seems to compete with
{{getContentStreams}}. I think it will be confusing to our users too --
SolrRequest is a visible part of SolrJ. Perhaps you could add some
documentation to these methods to deconflict when they are used, and what the
"expectedType" param is?
BTW the CHANGES.txt entry appears in "Other" yet isn't "Optimizations" fitting?
> SolrJ must stream docs to server instead of writing to a byte[] first
> --
>
> Key: SOLR-11380
> URL: https://issues.apache.org/jira/browse/SOLR-11380
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11380.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_144) - Build # 20853 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20853/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 5 tests failed. FAILED: org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI Error Message: Error from server at https://127.0.0.1:39819/solr: Timed out waiting to see all replicas: [implicitcoll_x_replica_n37] in cluster state. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:39819/solr: Timed out waiting to see all replicas: [implicitcoll_x_replica_n37] in cluster state. at __randomizedtesting.SeedInfo.seed([D38DC0043B19FCF:67D9526B7E2B29B7]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementA
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241467#comment-16241467 ] David Smiley commented on SOLR-11078: - Minor correction: Some Point fields can be uninverted to the FieldCache when docValues isn't enabled and even then, not always. Essentially single value ones can, multi-valued ones can't. Oddly however, even then it may only work for sorting but not faceting; I'm not certain. Any way, we recommend docValues=true for these features so it kinda doesn't matter too much when you can get away without it. > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps > -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime > -Xloggc:/home/prodza/solrserver/../logs/solr_gc.log -XX:+UseGCLogFileRotation > -XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20M > -Dsolr.log.dir=/home/prodza/solrserver/../logs -Djetty.port=8983 > -DSTOP.PORT=7983 -DSTOP.KEY=solrrocks -Duser.timezone=SAST > -Djetty.home=/home/prodza/solrserver/server > -Dsolr.solr.home=/home/prodza/solrserver/../solr > -Dsolr.install.dir=/home/prodza/solrserver > -Dlog4j.configuration=file:/home/prodza/solrserver/../config/log4j.properties > -Xss256k -Xss256k -Dsolr.log.muteconsole > -XX:OnOutOfMemoryError=/home/prodza/solrserver/bin/oom_solr.sh 8983 > /home/prodza/solrserver/../logs -jar start.jar --module=http >Reporter: bidorbuy > Attachments: compare-6.4.2-6.6.0.png, core-admin-tradesearch.png, > jvm-stats.png, schema.xml, screenshot-1.png, screenshot-2.png, > solr-6-4-2-schema.xml, solr-6-4-2-solrconfig.xml, solr-7-1-0-managed-schema, > solr-7-1-0-solrconfig.xml, solr-71-vs-64.png, solr-sample-warning-log.txt, > solr.in.sh, solrconfig.xml > > > We are currently running 2 separate Solr servers - refer to screenshots: > * zasolrm02 is running on Solr 6.4.2 > * zasolrm03 is running on Solr 6.6.0 > Both servers have the same OS / JVM configuration and are using their own > indexes. We round-robin load-balance through our Tomcats and notice that > Since Solr 6.4.2 performance has dropped. We have two indices per server > "searchsuggestions" and "tradesearch". There is a noticeable drop in > performance since Solr 6.4.2. > I am not sure if this is perhaps related to metric collation or other > underlying changes. I am not sure if other high transaction users have > noticed similar issues. > *1) zasolrm03 (6.6.0) is almost twice as slow on the tradesearch index:* > !compare-6.4.2-6.6.0.png! > *2) This is also visible in the searchsuggestion index:* > !screenshot-1.png! > *3) The Tradesearch index shows the biggest difference:* > !screenshot-2.png! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4275 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4275/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC 22 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.analysis.TestLuceneMatchVersion Error Message: org.apache.solr.analysis.TestLuceneMatchVersion Stack Trace: java.lang.ClassNotFoundException: org.apache.solr.analysis.TestLuceneMatchVersion at java.net.URLClassLoader$1.run(URLClassLoader.java:370) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.instantiate(SlaveMain.java:280) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:240) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:368) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13) Caused by: java.io.FileNotFoundException: /Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build/solr-core/classes/test/org/apache/solr/analysis/TestLuceneMatchVersion.class (Too many open files) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.(FileInputStream.java:138) at sun.misc.URLClassPath$FileLoader$1.getInputStream(URLClassPath.java:1288) at sun.misc.Resource.cachedInputStream(Resource.java:77) at sun.misc.Resource.getByteBuffer(Resource.java:160) at java.net.URLClassLoader.defineClass(URLClassLoader.java:454) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) ... 12 more FAILED: org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection Error Message: Error from server at https://127.0.0.1:57709/solr: Could not find collection : collection1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:57709/solr: Could not find collection : collection1 at __randomizedtesting.SeedInfo.seed([DDD34B72AEA5A207:83E7863CEDDA3EE0]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.LeaderElectionIntegrationTest.createCollection(LeaderElectionIntegrationTest.java:57) at org.apache.solr.cloud.LeaderElectionIntegrationTest.testSimpleSliceLeaderElection(LeaderElectionIntegrationTest.java:65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestR
[JENKINS] Lucene-Solr-Tests-7.x - Build # 228 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/228/ 5 tests failed. FAILED: org.apache.solr.cloud.CleanupOldIndexTest.test Error Message: Stack Trace: java.util.concurrent.TimeoutException at __randomizedtesting.SeedInfo.seed([6466D98E0BF79769:EC32E654A50BFA91]:0) at org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1325) at org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:440) at org.apache.solr.cloud.CleanupOldIndexTest.test(CleanupOldIndexTest.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.test Error Message: Could not load collection from ZK: customcollreplicadeletion Stack Trace: org.apache.solr.common.SolrException: Could not load collection from ZK: customcollreplicadeletion at __randomizedtesting.SeedInfo.seed([6466D98E0BF79769:EC32E654A50BFA91]:0)
[JENKINS] Lucene-Solr-Tests-master - Build # 2164 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2164/ 7 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:40278/pn_riv/xa Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:40278/pn_riv/xa at __randomizedtesting.SeedInfo.seed([4431FBB8A2913440:CC65C4620C6D59B8]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createJettys(AbstractFullDistribZkTestBase.java:409) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:334) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.Te
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.1) - Build # 292 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/292/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 3 tests failed. FAILED: org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testRecreateTaxonomy Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_48F67ADE228BD32E-001\replicationClientTest-003\2: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_48F67ADE228BD32E-001\replicationClientTest-003\2 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_48F67ADE228BD32E-001\replicationClientTest-003\2: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\replicator\test\J0\temp\lucene.replicator.IndexAndTaxonomyReplicationClientTest_48F67ADE228BD32E-001\replicationClientTest-003\2 at __randomizedtesting.SeedInfo.seed([48F67ADE228BD32E:740592BF494A052F]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.replicator.PerSessionDirectoryFactory.cleanupSession(PerSessionDirectoryFactory.java:58) at org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:259) at org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:401) at org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testRecreateTaxonomy(IndexAndTaxonomyReplicationClientTest.java:287) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
[jira] [Commented] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls
[
https://issues.apache.org/jira/browse/SOLR-11551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241387#comment-16241387
]
Jason Gerlowski commented on SOLR-11551:
I do like the 404 idea. Though if no other Solr APIs make use of the 404
status code, then introducing 404 here for CoreAdmin is a strike against the
standardization this Issue was created to work towards.
Maybe it's best deferred to a separate JIRA specifically focused on introducing
404 for all relevant APIs? (CoreAdmin, CollectionAdmin, ConfigSet, etc. could
all ostensibly benefit from a 404 status code differentiation). Whether that
other JIRA gets voted up or down, at least the APIs would stay consistent that
way.
> Standardize response codes and success/failure determination for core-admin
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
> Attachments: SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core
> admin api's first.
> If we are relying on response codes I think we should make the following
> change and fix all the APIs
> {code}
> interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
> }
> {code}
> To
> {code}
> interface CoreAdminOp {
> /**
> *
> * @param it request/response object
> *
> * If the request is invalid throw a SolrException with
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
> * If the execution of the command fails throw a SolrException with
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
> * Add a "error-message" key to the response object with the exception (
> this part should be done at the caller of this method so that each operation
> doesn't need to do the same thing )
> */
> void execute(CallInfo it);
> }
> {code}
> cc [~gerlowskija]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 20852 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20852/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly Error Message: Unexpected number of elements in the group for intGSF: 6 Stack Trace: java.lang.AssertionError: Unexpected number of elements in the group for intGSF: 6 at __randomizedtesting.SeedInfo.seed([292C0839CDF98E88:B297666180A1BCD6]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingDVOnly(DocValuesNotIndexedTest.java:377) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 11568 lines...] [junit4] Suite: org.apache.solr.cloud.DocValuesNotIndexedTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J2/temp/solr.cloud.DocValuesNotIndexedTest_292C0839CDF98E88-001/init-core-data-001 [jun
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-9.0.1) - Build # 7004 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7004/ Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseParallelGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.store.TestSimpleFSDirectory Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001\testThreadSafety-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001\testThreadSafety-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001\testThreadSafety-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001\testThreadSafety-001 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.store.TestSimpleFSDirectory_783EBF3BD535D456-001 at __randomizedtesting.SeedInfo.seed([783EBF3BD535D456]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.ltr.feature.TestExternalFeatures Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores\core\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores\core\data C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores\core: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores\core C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003\cores C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077CDB-001\tempDir-003 C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\solr\build\contrib\solr-ltr\test\J1\temp\solr.ltr.feature.TestExternalFeatures_8FB3CDB807077C
[jira] [Updated] (SOLR-11611) Starting Solr using solr.cmd fails in Windows, when the path contains a parenthesis
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Furrer updated SOLR-11611:
Description:
Starting Solr using solr.cli fails in Windows, when the path contains spaces.
Use the following example to reproduce the error:
{quote}C:\>c:
C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 8207-3B8B
Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
06.11.2017 15:52 .
06.11.2017 15:52 ..
06.11.2017 15:39 init.d
03.11.2017 17:32 8 209 post
03.11.2017 17:3275 963 solr
06.11.2017 14:2469 407 solr.cmd
3 Datei(en),153 579 Bytes
3 Verzeichnis(se), 51 191 619 584 Bytes frei
C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
*"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
was:
Starting Solr using solr.cli fails in Windows, when the path contains spaces.
Use the following example to reproduce the error:
{{C:\>c:
C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 8207-3B8B
Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
06.11.2017 15:52 .
06.11.2017 15:52 ..
06.11.2017 15:39 init.d
03.11.2017 17:32 8 209 post
03.11.2017 17:3275 963 solr
06.11.2017 14:2469 407 solr.cmd
3 Datei(en),153 579 Bytes
3 Verzeichnis(se), 51 191 619 584 Bytes frei
C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
*"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
Summary: Starting Solr using solr.cmd fails in Windows, when the path
contains a parenthesis (was: Starting Solr using solr.cli fails in Windows,
when the path contains spaces.)
> Starting Solr using solr.cmd fails in Windows, when the path contains a
> parenthesis
> ---
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {quote}C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-7.x-Linux (64bit/jdk-10-ea+29) - Build # 760 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/760/ Java: 64bit/jdk-10-ea+29 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestReplicaProperties Error Message: 63 threads leaked from SUITE scope at org.apache.solr.cloud.TestReplicaProperties: 1) Thread[id=12496, name=qtp780972431-12496, state=RUNNABLE, group=TGRP-TestReplicaProperties] at java.base@10-ea/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at java.base@10-ea/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265) at java.base@10-ea/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92) at java.base@10-ea/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:89) at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:100) at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:104) at app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:243) at app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:191) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:249) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) at app//org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) at app//org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)2) Thread[id=12515, name=searcherExecutor-4609-thread-1, state=WAITING, group=TGRP-TestReplicaProperties] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@10-ea/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2074) at java.base@10-ea/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1061) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)3) Thread[id=12596, name=zkCallback-1878-thread-6, state=TIMED_WAITING, group=TGRP-TestReplicaProperties] at java.base@10-ea/jdk.internal.misc.Unsafe.park(Native Method) at java.base@10-ea/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234) at java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:462) at java.base@10-ea/java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:361) at java.base@10-ea/java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:937) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1060) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) at java.base@10-ea/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base@10-ea/java.lang.Thread.run(Thread.java:844)4) Thread[id=12491, name=qtp780972431-12491, state=RUNNABLE, group=TGRP-TestReplicaProperties] at java.base@10-ea/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at java.base@10-ea/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265) at java.base@10-ea/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92) at java.base@10-ea/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:89) at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:100) at java.base@10-ea/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:104) at app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.select(ManagedSelector.java:243) at app//org.eclipse.jetty.io.ManagedSelector$SelectorProducer.produce(ManagedSelector.java:191) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:249) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) at app//org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.execute(ExecuteProduceConsume.java:100) at app//org.eclipse.jetty.io.ManagedSelector.r
[jira] [Commented] (SOLR-11597) Implement RankNet.
[
https://issues.apache.org/jira/browse/SOLR-11597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241197#comment-16241197
]
Michael A. Alcorn commented on SOLR-11597:
--
Thanks for the feedback, [~cpoerschke].
bq. Let's also add the new class to the table in the Solr Reference Guide
Will do.
bq. String vs. list of lists representation
I agree the list representation is more intuitive, but I'm having trouble
figuring out how to set that in Solr. The only thing I could make work was:
{code:java}
final List>> matrixList = (List>>) weights;
{code}
which is pretty ugly.
{code:java}
final List matrixList = (List) weights;
{code}
and:
{code:java}
final List matrixList = (List) weights;
{code}
didn't seem to work for me, and I'm not sure why.
bq. How about implementing/overriding the {{validate}} method?
Sounds good.
bq. test coverage of some sort
I can take a look at that.
bq. I'm pretty sure the {{String.format("...", ...);}} in the explain method
will be flagged up by the forbidden-apis
I'll fix that.
> Implement RankNet.
> --
>
> Key: SOLR-11597
> URL: https://issues.apache.org/jira/browse/SOLR-11597
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Reporter: Michael A. Alcorn
>
> Implement RankNet as described in [this
> tutorial|https://github.com/airalcorn2/Solr-LTR].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11613) Improve error in admin UI "Sorry, no dataimport-handler defined"
[ https://issues.apache.org/jira/browse/SOLR-11613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shawn Heisey updated SOLR-11613: Labels: newdev (was: ) > Improve error in admin UI "Sorry, no dataimport-handler defined" > > > Key: SOLR-11613 > URL: https://issues.apache.org/jira/browse/SOLR-11613 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1 >Reporter: Shawn Heisey >Priority: Minor > Labels: newdev > > When the config has no working dataimport handlers, clicking on the > "dataimport" tab for a core/collection shows an error message that states > "Sorry, no dataimport-handler defined". This is a little bit vague. > One idea for an improved message: "The solrconfig.xml file for this index > does not have an operational dataimport handler defined." -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 882 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/882/ No tests ran. Build Log: [...truncated 28006 lines...] prepare-release-no-sign: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist [copy] Copying 476 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/lucene [copy] Copying 215 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/solr [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8 [smoker] NOTE: output encoding is UTF-8 [smoker] [smoker] Load release URL "file:/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/dist/"... [smoker] [smoker] Test Lucene... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.01 sec (17.8 MB/sec) [smoker] check changes HTML... [smoker] download lucene-8.0.0-src.tgz... [smoker] 29.8 MB in 0.09 sec (346.2 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.tgz... [smoker] 70.9 MB in 0.20 sec (348.5 MB/sec) [smoker] verify md5/sha1 digests [smoker] download lucene-8.0.0.zip... [smoker] 81.3 MB in 0.23 sec (350.9 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack lucene-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6188 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0.zip... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] test demo with 1.8... [smoker] got 6188 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] check Lucene's javadoc JAR [smoker] unpack lucene-8.0.0-src.tgz... [smoker] make sure no JARs/WARs in src dist... [smoker] run "ant validate" [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'... [smoker] test demo with 1.8... [smoker] got 220 hits for query "lucene" [smoker] checkindex with 1.8... [smoker] generate javadocs w/ Java 8... [smoker] [smoker] Crawl/parse... [smoker] [smoker] Verify... [smoker] confirm all releases have coverage in TestBackwardsCompatibility [smoker] find all past Lucene releases... [smoker] run TestBackwardsCompatibility.. [smoker] success! [smoker] [smoker] Test Solr... [smoker] test basics... [smoker] get KEYS [smoker] 0.2 MB in 0.02 sec (13.8 MB/sec) [smoker] check changes HTML... [smoker] download solr-8.0.0-src.tgz... [smoker] 51.6 MB in 0.16 sec (314.3 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.tgz... [smoker] 145.9 MB in 0.44 sec (334.6 MB/sec) [smoker] verify md5/sha1 digests [smoker] download solr-8.0.0.zip... [smoker] 146.9 MB in 0.45 sec (328.4 MB/sec) [smoker] verify md5/sha1 digests [smoker] unpack solr-8.0.0.tgz... [smoker] verify JAR metadata/identity/no javax.* or java.* classes... [smoker] unpack lucene-8.0.0.tgz... [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar: it has javax.* classes [smoker] **WARNING**: skipping check of /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar: it has javax.* classes [smoker] copying unpacked distribution for Java 8 ... [smoker] test solr example w/ Java 8... [smoker] start Solr instance (log=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/solr-example.log)... [smoker] No process found for Solr node running on port 8983 [smoker] Running techproducts example on port 8983 from /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8 [smoker] Creating Solr home directory /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/build/smokeTestRelease/tmp/unpack/solr-8.0.0-java8/example/techproducts/solr [smoker] [smoker] Starting up Solr on port 8983 using command: [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr" [smoker] [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|] [/] [-] [\] [|] [/] [-] [\] [|] [/
[jira] [Created] (SOLR-11613) Improve error in admin UI "Sorry, no dataimport-handler defined"
Shawn Heisey created SOLR-11613: --- Summary: Improve error in admin UI "Sorry, no dataimport-handler defined" Key: SOLR-11613 URL: https://issues.apache.org/jira/browse/SOLR-11613 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 7.1 Reporter: Shawn Heisey Priority: Minor When the config has no working dataimport handlers, clicking on the "dataimport" tab for a core/collection shows an error message that states "Sorry, no dataimport-handler defined". This is a little bit vague. One idea for an improved message: "The solrconfig.xml file for this index does not have an operational dataimport handler defined." -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 286 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/286/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 3 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=27367, name=jetty-launcher-4207-thread-2-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=27366, name=jetty-launcher-4207-thread-2-SendThread(127.0.0.1:40360), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 3) Thread[id=27303, name=jetty-launcher-4207-thread-1-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323) at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105) at org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279) at org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41) at org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244) at org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44) at org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61) at org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=27367, name=jetty-launcher-4207-thread-2-EventThread, state=WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:501) 2) Thread[id=27366, name=jetty-launcher-4207-thread-2-SendThread(127.0.0.1:40360), state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at java.lang.Thread.sleep(Native Method) at org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:101) at org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:997) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1060) 3) Thread[id=27303, name=jetty-launcher-4207-thread-1-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) at org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323
[jira] [Commented] (SOLR-11472) Leader election bug
[ https://issues.apache.org/jira/browse/SOLR-11472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241146#comment-16241146 ] Varun Thacker commented on SOLR-11472: -- Is there any notes on how this bug manifests? > Leader election bug > --- > > Key: SOLR-11472 > URL: https://issues.apache.org/jira/browse/SOLR-11472 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.1, master (8.0) >Reporter: Andrzej Bialecki >Assignee: Shalin Shekhar Mangar > Attachments: > Console_output_of_AutoscalingHistoryHandlerTest_failure.txt > > > SOLR-11407 uncovered a bug in leader election, where the same failing node is > retried indefinitely. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11612) new_core: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load conf for core new_core: Error loading solr config from /home/madguy02
[ https://issues.apache.org/jira/browse/SOLR-11612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11612. --- Resolution: Incomplete This is not an appropriate use of Solr's JIRA, we try to reserve the JIRA system for code issues rather than usage questions. Please ask the question here: solr-u...@lucene.apache.org, see: http://lucene.apache.org/solr/community.html#mailing-lists-irc When you raise question on the user's list, include pertinent details, including the stack trace from Solr's log. Likely in this case you have some syntax error in your solrconfig file. Again, the log will show you additional details. > new_core: > org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: > Could not load conf for core new_core: Error loading solr config from > /home/madguy02/solr/server/solr/new_core/conf/solrconfig.xml > --- > > Key: SOLR-11612 > URL: https://issues.apache.org/jira/browse/SOLR-11612 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Manish Kakoti >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-9.0.1) - Build # 20851 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20851/
Java: 64bit/jdk-9.0.1 -XX:-UseCompressedOops -XX:+UseSerialGC
2 tests failed.
FAILED:
junit.framework.TestSuite.org.apache.solr.client.solrj.impl.ConnectionReuseTest
Error Message:
Stack Trace:
java.util.concurrent.TimeoutException
at __randomizedtesting.SeedInfo.seed([F3444E69BED2F4F]:0)
at
org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1325)
at
org.apache.solr.client.solrj.impl.CloudSolrClient.waitForState(CloudSolrClient.java:440)
at
org.apache.solr.client.solrj.impl.ConnectionReuseTest.setupCluster(ConnectionReuseTest.java:67)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
FAILED: org.apache.solr.cloud.AssignBackwardCompatibilityTest.test
Error Message:
Expected 8 active replicas null Live Nodes: [127.0.0.1:33289_solr,
127.0.0.1:37343_solr, 127.0.0.1:43803_solr, 127.0.0.1:44347_solr] Last
available state:
DocCollection(collection1//collections/collection1/state.json/55)={
"pullReplicas":"0", "replicationFactor":"4", "shards":{"shard1":{
"range":"8000-7fff", "state":"active", "replicas":{
"core_node5":{ "core":"collection1_shard1_replica_n2",
"base_url":"https://127.0.0.1:44347/solr";,
"node_name":"127.0.0.1:44347_solr", "state":"active",
"type":"NRT"}, "core_node7":{
"core":"collection1_shard1_replica_n4",
"base_url":"https://127.0.0.1:33289/solr";,
"node_name":"127.0.0.1:33289_solr", "state":"active",
"type":"NRT", "leader":"true"}, "core_node14":{
"core":"collection1_shard1_replica_n13",
"base_url":"https://127.0.0.1:43803/solr";,
"node_name":"127.0.0.1:43803_solr", "state":"active",
"type":"NRT"}, "core_node16":{
"core":"collection1_shard1_replica_n15",
"base_url":"https://127.0.0.1:33289/solr";,
"node_name":"127.0.0.1:33289_solr", "state":"active",
"type":"NRT"}, "core_node18":{
"core":"collection1_shard1_replica_n17",
"base_url":"https://127.0.0.1:44347/solr";,
"node_name":"127.0.0.1:44347_solr", "state":"active",
"type":"NRT"}, "core_node146":{
"core":"collection1_shard1_replica_n145",
"base_url":"https://127.0.0.1:37343/solr";,
"node_name":"127.0.0.1:37343_solr", "state":"active",
"type":"NRT"},
[jira] [Updated] (SOLR-11409) A ref guide page on setting up solr on aws
[ https://issues.apache.org/jira/browse/SOLR-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11409: - Attachment: SOLR-11409_followup_minor.patch The guide looks great!! I uploaded a patch with two minor edits. If it looks fine I can commit it One question for which I don't have an answer to: While editing the zoo.cfg file should we be recommending any particular heap settings? Maybe we could add an example of how to enable log rotation ( if the default doesn't already ) and GC logging? > A ref guide page on setting up solr on aws > -- > > Key: SOLR-11409 > URL: https://issues.apache.org/jira/browse/SOLR-11409 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Cassandra Targett >Priority: Minor > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11409.patch, SOLR-11409_followup_minor.patch, > quick-start-aws-key.png, quick-start-aws-security-1.png, > quick-start-aws-security-2.png > > > It will be nice if we have a dedicated page on installing solr on aws . > At the end we could even link to > http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8041) All Fields.terms(fld) impls should be O(N) not O(log(N))
[ https://issues.apache.org/jira/browse/LUCENE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240977#comment-16240977 ] Robert Muir commented on LUCENE-8041: - It doesn't need to be all *all* fields.terms impls. It is enough to optimize the default codec. TreeMap is a good simple default, all the various alternative terms dicts can continue to use it. But the default codec should optimize for the access behavior that matters: accessing a field randomly. I don't think we should remove field iteration/Fields unless we remove the ability to change term vectors "per-doc". It is currently needed (e.g. by CheckIndex) to know what fields were truly indexed for a specific document with vectors, since that may disagree with FieldInfos. If we fixed that, then it would truly be unnecessary and FieldInfos would be all we need. > All Fields.terms(fld) impls should be O(N) not O(log(N)) > > > Key: LUCENE-8041 > URL: https://issues.apache.org/jira/browse/LUCENE-8041 > Project: Lucene - Core > Issue Type: Improvement >Reporter: David Smiley > > I've seen apps that have a good number of fields -- hundreds. The O(log(N)) > of TreeMap definitely shows up in a profiler; sometimes 20% of search time, > if I recall. There are many Field implementations that are impacted... in > part because Fields is the base class of FieldsProducer. > As an aside, I hope Fields to go away some day; FieldsProducer should be > TermsProducer and not have an iterator of fields. If DocValuesProducer > doesn't have this then why should the terms index part of our API have it? > If we did this then the issue here would be a simple transition to a HashMap. > Or maybe we can switch to HashMap and relax the definition of Fields.iterator > to not necessarily be sorted? > Perhaps the fix can be a relatively simple conversion over to LinkedHashMap > in many cases if we can assume when we initialize these internal maps that we > consume them in sorted order to begin with. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 1517 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1517/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.lucene.search.similarities.TestBasicModelIn.testRandomScoring Error Message: score(0.9994)=1.5E-44 > score(1.0)=1.4E-44 Stack Trace: java.lang.AssertionError: score(0.9994)=1.5E-44 > score(1.0)=1.4E-44 at __randomizedtesting.SeedInfo.seed([925DE6ABD8E635F3:19C2BF19C291D3F9]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.lucene.search.similarities.BaseSimilarityTestCase.doTestScoring(BaseSimilarityTestCase.java:403) at org.apache.lucene.search.similarities.BaseSimilarityTestCase.testRandomScoring(BaseSimilarityTestCase.java:355) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation Error Message: 2 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithSecureImpersonation: 1) Thread[id=29662, name=jetty-launcher-5174-thread-2-EventThread, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithSecureImpersonation] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.Abstr
[jira] [Created] (LUCENE-8041) All Fields.terms(fld) impls should be O(N) not O(log(N))
David Smiley created LUCENE-8041: Summary: All Fields.terms(fld) impls should be O(N) not O(log(N)) Key: LUCENE-8041 URL: https://issues.apache.org/jira/browse/LUCENE-8041 Project: Lucene - Core Issue Type: Improvement Reporter: David Smiley I've seen apps that have a good number of fields -- hundreds. The O(log(N)) of TreeMap definitely shows up in a profiler; sometimes 20% of search time, if I recall. There are many Field implementations that are impacted... in part because Fields is the base class of FieldsProducer. As an aside, I hope Fields to go away some day; FieldsProducer should be TermsProducer and not have an iterator of fields. If DocValuesProducer doesn't have this then why should the terms index part of our API have it? If we did this then the issue here would be a simple transition to a HashMap. Or maybe we can switch to HashMap and relax the definition of Fields.iterator to not necessarily be sorted? Perhaps the fix can be a relatively simple conversion over to LinkedHashMap in many cases if we can assume when we initialize these internal maps that we consume them in sorted order to begin with. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
[
https://issues.apache.org/jira/browse/LUCENE-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240965#comment-16240965
]
Robert Muir commented on LUCENE-8040:
-
I don't really see it as a separate issue. collectionStatistics() is just
looking up the stats from blocktree's maps and summing them up. so if its too
slow, then blocktree is the place to fix it.
> Optimize IndexSearcher.collectionStatistics
> ---
>
> Key: LUCENE-8040
> URL: https://issues.apache.org/jira/browse/LUCENE-8040
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: lucenecollectionStatisticsbench.zip
>
>
> {{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
> because with each invocation it will call {{MultiFields.getTerms(...)}}. The
> effects of this are aggravated for queries with many fields since each field
> will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11409) A ref guide page on setting up solr on aws
[ https://issues.apache.org/jira/browse/SOLR-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240948#comment-16240948 ] Cassandra Targett commented on SOLR-11409: -- Thanks [~sarkaramr...@gmail.com]! This is now committed to master & branch_7x. I ended up changing a few things from your last patch - the title of the page as the biggest one. I thought positioning it a bit more as a tutorial was better, and I clarified some of the things you need for production also. I also shortened the Appendix a little to make it a bit more clear that the setup was mostly the same except for a couple of parameters. If you see anything that looks wrong, let me know and I'll fix it. > A ref guide page on setting up solr on aws > -- > > Key: SOLR-11409 > URL: https://issues.apache.org/jira/browse/SOLR-11409 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11409.patch, quick-start-aws-key.png, > quick-start-aws-security-1.png, quick-start-aws-security-2.png > > > It will be nice if we have a dedicated page on installing solr on aws . > At the end we could even link to > http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11409) A ref guide page on setting up solr on aws
[ https://issues.apache.org/jira/browse/SOLR-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-11409. -- Resolution: Fixed Assignee: Cassandra Targett Fix Version/s: master (8.0) 7.2 > A ref guide page on setting up solr on aws > -- > > Key: SOLR-11409 > URL: https://issues.apache.org/jira/browse/SOLR-11409 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Cassandra Targett >Priority: Minor > Fix For: 7.2, master (8.0) > > Attachments: SOLR-11409.patch, quick-start-aws-key.png, > quick-start-aws-security-1.png, quick-start-aws-security-2.png > > > It will be nice if we have a dedicated page on installing solr on aws . > At the end we could even link to > http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11409) A ref guide page on setting up solr on aws
[ https://issues.apache.org/jira/browse/SOLR-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240942#comment-16240942 ] ASF subversion and git services commented on SOLR-11409: Commit 118c6f5f7b1e751cb191fece3a30d80aa797221b in lucene-solr's branch refs/heads/master from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=118c6f5 ] SOLR-11409: Add tutorial for deploying Solr on EC2 > A ref guide page on setting up solr on aws > -- > > Key: SOLR-11409 > URL: https://issues.apache.org/jira/browse/SOLR-11409 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-11409.patch, quick-start-aws-key.png, > quick-start-aws-security-1.png, quick-start-aws-security-2.png > > > It will be nice if we have a dedicated page on installing solr on aws . > At the end we could even link to > http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11409) A ref guide page on setting up solr on aws
[ https://issues.apache.org/jira/browse/SOLR-11409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240943#comment-16240943 ] ASF subversion and git services commented on SOLR-11409: Commit 0400fc86ca2fab5fea33fcdafb4a9f58af21ad84 in lucene-solr's branch refs/heads/branch_7x from [~ctargett] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0400fc8 ] SOLR-11409: Add tutorial for deploying Solr on EC2 > A ref guide page on setting up solr on aws > -- > > Key: SOLR-11409 > URL: https://issues.apache.org/jira/browse/SOLR-11409 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Priority: Minor > Attachments: SOLR-11409.patch, quick-start-aws-key.png, > quick-start-aws-security-1.png, quick-start-aws-security-2.png > > > It will be nice if we have a dedicated page on installing solr on aws . > At the end we could even link to > http://lucene.apache.org/solr/guide/6_6/taking-solr-to-production.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 227 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/227/ 16 tests failed. FAILED: org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin Error Message: expected:<0> but was:<2> Stack Trace: java.lang.AssertionError: expected:<0> but was:<2> at __randomizedtesting.SeedInfo.seed([E652F1EA981F2225:5C809E921B31CC30]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.DistribCursorPagingTest.test Error Message: Error from server at http://127.0.0.1:55433/ydn/b/collection1_shard1_re
[jira] [Commented] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
[
https://issues.apache.org/jira/browse/LUCENE-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240926#comment-16240926
]
David Smiley commented on LUCENE-8040:
--
RE switching away from TreeMap to HashMap: absolutely! I've been working on a
client project where this was already profiled and optimized to a HashMap in a
fork. Definitely a separate issue, though I can see how the results of that
will impact the results here. I'll file an issue.
> Optimize IndexSearcher.collectionStatistics
> ---
>
> Key: LUCENE-8040
> URL: https://issues.apache.org/jira/browse/LUCENE-8040
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: lucenecollectionStatisticsbench.zip
>
>
> {{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
> because with each invocation it will call {{MultiFields.getTerms(...)}}. The
> effects of this are aggravated for queries with many fields since each field
> will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow
[
https://issues.apache.org/jira/browse/LUCENE-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Menon updated LUCENE-8034:
---
Attachment: LUCENE-8034.patch
Updated to remove the asserts on score as it was misleading. We only need to
verify that the results were picked.
> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
> Labels: newbie, patch
> Attachments: LUCENE-8034.patch
>
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`.
> I have a fix for this which I am working on. Basically I am flipping the add
> to a subtract.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow
[
https://issues.apache.org/jira/browse/LUCENE-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hari Menon updated LUCENE-8034:
---
Attachment: (was: LUCENE-8034.patch)
> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
> Labels: newbie, patch
> Attachments: LUCENE-8034.patch
>
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`.
> I have a fix for this which I am working on. Basically I am flipping the add
> to a subtract.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11608) V2 Core-Rename API fails to parse new core name
[
https://issues.apache.org/jira/browse/SOLR-11608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240900#comment-16240900
]
Anshum Gupta commented on SOLR-11608:
-
[~gerlowskija] thanks for the patch, I'll take a look at it and commit but can
you add a JUnit test for this too so we don't regress in future?
> V2 Core-Rename API fails to parse new core name
> ---
>
> Key: SOLR-11608
> URL: https://issues.apache.org/jira/browse/SOLR-11608
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
>Affects Versions: 7.1, master (8.0)
>Reporter: Jason Gerlowski
>Priority: Minor
> Attachments: SOLR-11608.patch, repro.sh
>
>
> I noticed recently that the v2 Solr API's rename-core command fails to parse
> out the provided "to" parameter (which contains the desired new core name).
> {{_introspect}} shows the following documentation for the API:
> {code}
> "rename":{
> "type":"object",
>
> "documentation":"https://lucene.apache.org/solr/guide/coreadmin-api.html#coreadmin-rename";,
> "description":"Change the name of a core.",
> "properties":{
> "to":{
> "type":"string",
> "description":"The new name for the core."},
> "async":{
> "type":"string",
> "description":"Defines a request ID that can be used to track
> this action after it's submitted. The action will be processed asynchronously
> when this is defined."}},
> "required":["to"]},
> {code}
> but it appears that the underlying code fails to parse out the "to" parameter:
> {code}
> ➜ solr git:(master) ✗ curl -ilk -X POST "$SOLR_HOST/api/cores/foo" -d
> '{"rename": {"to":"bar"}}'
> HTTP/1.1 400 Bad Request
> Content-Type: application/json;charset=utf-8
> Content-Length: 381
> {
> "responseHeader":{
> "status":400,
> "QTime":0},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Invalid core: [null]. core names must consist entirely of periods,
> underscores, hyphens, and alphanumerics as well not start with a hyphen",
> "code":400}}
> {code}
> I'm not super familiar with the V2<->V1 API mapping code, but it looks like
> the underlying implementation in {{CoreAdminOperation}} is expecting a
> parameter named "other", but there's no mapping from "to" -> "other" for this
> particular API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11608) V2 Core-Rename API fails to parse new core name
[
https://issues.apache.org/jira/browse/SOLR-11608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta reassigned SOLR-11608:
---
Assignee: Anshum Gupta
> V2 Core-Rename API fails to parse new core name
> ---
>
> Key: SOLR-11608
> URL: https://issues.apache.org/jira/browse/SOLR-11608
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
>Affects Versions: 7.1, master (8.0)
>Reporter: Jason Gerlowski
>Assignee: Anshum Gupta
>Priority: Minor
> Attachments: SOLR-11608.patch, repro.sh
>
>
> I noticed recently that the v2 Solr API's rename-core command fails to parse
> out the provided "to" parameter (which contains the desired new core name).
> {{_introspect}} shows the following documentation for the API:
> {code}
> "rename":{
> "type":"object",
>
> "documentation":"https://lucene.apache.org/solr/guide/coreadmin-api.html#coreadmin-rename";,
> "description":"Change the name of a core.",
> "properties":{
> "to":{
> "type":"string",
> "description":"The new name for the core."},
> "async":{
> "type":"string",
> "description":"Defines a request ID that can be used to track
> this action after it's submitted. The action will be processed asynchronously
> when this is defined."}},
> "required":["to"]},
> {code}
> but it appears that the underlying code fails to parse out the "to" parameter:
> {code}
> ➜ solr git:(master) ✗ curl -ilk -X POST "$SOLR_HOST/api/cores/foo" -d
> '{"rename": {"to":"bar"}}'
> HTTP/1.1 400 Bad Request
> Content-Type: application/json;charset=utf-8
> Content-Length: 381
> {
> "responseHeader":{
> "status":400,
> "QTime":0},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Invalid core: [null]. core names must consist entirely of periods,
> underscores, hyphens, and alphanumerics as well not start with a hyphen",
> "code":400}}
> {code}
> I'm not super familiar with the V2<->V1 API mapping code, but it looks like
> the underlying implementation in {{CoreAdminOperation}} is expecting a
> parameter named "other", but there's no mapping from "to" -> "other" for this
> particular API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: SPLITSHARD and MIGRATE Collection API Response
Hi Jason,
The history behind responses looking like this is that when collections APIs
were added, the top level response to the request but nothing but a list of all
the responses from the core level admin requests that were made internally in
order to process the request. That is the reason why you see responses with
multiple headers.
It certainly wasn’t an oversight and while I think we still should have the
responses from internal calls (optionally) returned, it would be much better to
clean up the responses to be something that are easy to read and understand.
-Anshum
> On Oct 29, 2017, at 12:49 PM, Jason Gerlowski wrote:
>
> Hey all,
>
> I was testing some Collections APIs the other day, and noticed a
> curious response format for the SPLITSHARD and MIGRATE commands.
>
> Both have a large number of near-duplicate responseHeader sections
> with different QTimes. Is there a reason all these sections are being
> returned back to the user? Is there some meaning that I should be
> able to parse out of these sections, but am overlooking? Examples
> below:
>
> $ curl -ilk -X GET
> 'http://localhost:8984/solr/admin/collections?action=MIGRATE&collection=techproducts_restore_collection&split.key=!&target.collection=techproducts_migration'
> HTTP/1.1 200 OK
> Content-Type: application/json;charset=utf-8
> Content-Length: 1318
>
> {
>"responseHeader":{
> "status":0,
> "QTime":9355},
>"success":{
> "127.0.1.1:8984_solr":{
>"responseHeader":{
> "status":0,
> "QTime":0},
>"core":"techproducts_migration_shard1_replica_n1",
>"status":"BUFFERING"},
> "127.0.1.1:8985_solr":{
>"responseHeader":{
> "status":0,
> "QTime":1766},
>"core":"split_shard1_temp_shard1_shard1_replica_n1"},
> "127.0.1.1:8985_solr":{
>"responseHeader":{
> "status":0,
> "QTime":1001}},
> "127.0.1.1:8985_solr":{
>"responseHeader":{
> "status":0,
> "QTime":78}},
> "127.0.1.1:8984_solr":{
>"responseHeader":{
> "status":0,
> "QTime":407},
>"core":"split_shard1_temp_shard1_shard1_replica_n3"},
> "127.0.1.1:8985_solr":{
>"responseHeader":{
> "status":0,
> "QTime":4014}},
> "127.0.1.1:8984_solr":{
>"responseHeader":{
> "status":0,
> "QTime":4}},
> "127.0.1.1:8984_solr":{
>"responseHeader":{
> "status":0,
> "QTime":0},
>"core":"techproducts_migration_shard1_replica_n1",
>"status":"EMPTY_BUFFER"},
> "127.0.1.1:8984_solr":{
>"responseHeader":{
> "status":0,
> "QTime":70}},
> "127.0.1.1:8985_solr":{
>"responseHeader":{
> "status":0,
> "QTime":82
>
> SPLITSHARD has an almost identical output. Thanks for any
> clarification anyone can offer, just curious.
>
> Best,
>
> Jason
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
[jira] [Updated] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only
[
https://issues.apache.org/jira/browse/SOLR-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11600:
-
Fix Version/s: (was: 6.6.1)
(was: 7.0)
> Add Constructor to SelectStream which takes StreamEvaluators as argument.
> Current schema forces one to enter a stream expression string only
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
> Labels: easyfix
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup
> stream in the following manner, but with instead with Strongly typed objects
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields)
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11600) Add Constructor to SelectStream which takes StreamEvaluators as argument. Current schema forces one to enter a stream expression string only
[
https://issues.apache.org/jira/browse/SOLR-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amrit Sarkar updated SOLR-11600:
Attachment: SOLR-11600.patch
Uploaded first draft patch without tests. It can be coded better. The thing to
notice is: we have to pass our own StreamFactory everytime we make request from
SolrJ.
Pretty sure Joel will have better solution than this.
> Add Constructor to SelectStream which takes StreamEvaluators as argument.
> Current schema forces one to enter a stream expression string only
> -
>
> Key: SOLR-11600
> URL: https://issues.apache.org/jira/browse/SOLR-11600
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ, streaming expressions
>Affects Versions: 6.6.1, 7.1
>Reporter: Aroop
>Priority: Trivial
> Labels: easyfix
> Fix For: 6.6.1, 7.0
>
> Attachments: SOLR-11600.patch
>
>
> The use case is to be able able to supply stream evaluators over a rollup
> stream in the following manner, but with instead with Strongly typed objects
> and not steaming-expression strings.
> {code:bash}
> curl --data-urlencode 'expr=select(
> id,
> div(sum(cat1_i),sum(cat2_i)) as metric1,
> coalesce(div(sum(cat1_i),if(eq(sum(cat2_i),0),null,sum(cat2_i))),0) as
> metric2,
> rollup(
> search(col1, q=*:*, fl="id,cat1_i,cat2_i,cat_s", qt="/export", sort="cat_s
> asc"),
> over="cat_s",sum(cat1_i),sum(cat2_i)
> ))' http://localhost:8983/solr/col1/stream
> {code}
> the current code base does not allow one to provide selectedEvaluators in a
> constructor, so one cannot prepare their select stream via java code:
> {code:java}
> public class SelectStream extends TupleStream implements Expressible {
> private static final long serialVersionUID = 1L;
> private TupleStream stream;
> private StreamContext streamContext;
> private Map selectedFields;
> private Map selectedEvaluators;
> private List operations;
> public SelectStream(TupleStream stream, List selectedFields)
> throws IOException {
> this.stream = stream;
> this.selectedFields = new HashMap();
> Iterator var3 = selectedFields.iterator();
> while(var3.hasNext()) {
> String selectedField = (String)var3.next();
> this.selectedFields.put(selectedField, selectedField);
> }
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> public SelectStream(TupleStream stream, Map
> selectedFields) throws IOException {
> this.stream = stream;
> this.selectedFields = selectedFields;
> this.operations = new ArrayList();
> this.selectedEvaluators = new HashMap();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 759 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/759/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=10624, name=searcherExecutor-4633-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=10624, name=searcherExecutor-4633-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([D40F5C84D8662D85]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=10624, name=searcherExecutor-4633-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=10624, name=searcherExecutor-4633-thread-1, state=WAITING, group=TGRP-TestLazyCores] at java.base@9.0.1/jdk.internal.misc.Unsafe.park(Native Method) at java.base@9.0.1/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@9.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2062) at java.base@9.0.1/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:435) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1092) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.base@9.0.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.base@9.0.1/java.lang.Thread.run(Thread.java:844) at __randomizedtesting.SeedInfo.seed([D40F5C84D8662D85]:0) FAILED: org.apache.solr.cloud.TestPullReplicaErrorHandling.testCantConnectToLeader Error Message: Error from server at http://127.0.0.1:43483/solr: Could not fully create collection: pull_replica_error_handling_test_cant_connect_to_leader Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43483/solr: Could not fully create collection: pull_replica_error_handling_test_cant_connect_to_leader at __randomizedtesting.SeedInfo.seed([D40F5C8
[jira] [Commented] (SOLR-11078) Solr query performance degradation since Solr 6.4.2
[ https://issues.apache.org/jira/browse/SOLR-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240871#comment-16240871 ] David Smiley commented on SOLR-11078: - bq. Is there more documentation available about *Point-types? I'm not sure. I'll update the ref guide after you take the changes for a whirl to confirm what I expect will happen. bq. I am unsure what it means from a performance perspective that Point-types do not support FieldCache and as such we need to use doc-values for faceting to be supported. Curious; can you provide a reference to where you've read that about the FieldCache? It's right but just wanted to see where that advise is; I didn't notice it in the ref guide. Any way... I suspect you've _already_ (in 6.x) been using docValues=true on appropriate fields since you didn't mention to the contrary. So there's no change for you in this respect. Basically, know that Solr needs fast access to values on a doc/field basis for certain non-search features. Generally, the ideal way to make that available is to set docValues=true on the field. Alternatively if you don't, and if the field type supports "uninversion" (Trie fields & StrField do, Point fields don't) then Solr will use it's so-called FieldCache which un-inverts the index=true data into memory. Lets say you weren't using docValues at all and now you do. The net perceived change is * smaller java heap requirements; this data is accessed off-heap in memory mapped IO instead. So you still need same RAM roughly but Java GC can have an easier time. * better realtime search. The warmup queries (generally user-configured to run after commit in solrconfig) should be faster to complete if they use faceting, sorting etc. since they won't need to trigger the uninversion of index structures into memory. If you don't have warmup, then the first user's search query to come along after a commit used to be hit with the uninversion penalty and now it won't (so faster queries at this 99 percentile). * larger disk requirements to hold the docValues data General access performance isn't necessarily better though; in some cases it has been shown to be worse :-/ bq. One idea we had is to change all non-range fields to StrField (one by one) and measure performance impact and then start switching *Point-fields. I am not sure if there is a better/scientific way to go about this (analysing the query performance is difficult as queries are typically some text-search with filtering/faceting - so not many unique queries where it is easy to show some trends). Benchmarking/analysis can be a real time sink; I suppose what you should do depends on what you hope to get out of it. Assuming you hope to not use deprecated Trie fields... then yes moving away from them is one goal. And getting equal or better performance is another goal. I doubt you need to get any more precise than that unless you are digging deeper to discover why one of those goals isn't met (gets slower). As you've indicated switching the "non-range" usages to StrField is one step. My expectation of the result is that it'll be a non-event. StrField loses the typed ergonomics of Trie but otherwise should be very similar for non-range use. I wouldn't bother changing one field at a time and measuring in-between... that seems like a lot of time; although if you discover some unexpected bad results then you could do this to help deduce which field & query exhibits the problem. RE the range fields, yep, them from TrieFields to PointFields (all at once) is the next step. This one may be interesting; hopefully nothing gets worse. If it's better than declare success and move on! > Solr query performance degradation since Solr 6.4.2 > --- > > Key: SOLR-11078 > URL: https://issues.apache.org/jira/browse/SOLR-11078 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: search, Server >Affects Versions: 6.6, 7.1 > Environment: * CentOS 7.3 (Linux zasolrm03 3.10.0-514.26.2.el7.x86_64 > #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux) > * Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) > * 4 CPU, 10GB RAM > Running Solr 6.6.0 with the following JVM settings: > java -server -Xms4G -Xmx4G -XX:NewRatio=3 -XX:SurvivorRatio=4 > -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=8 -XX:+UseConcMarkSweepGC > -XX:+UseParNewGC -XX:ConcGCThreads=4 -XX:ParallelGCThreads=4 > -XX:+CMSScavengeBeforeRemark -XX:PretenureSizeThreshold=64m > -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50 > -XX:CMSMaxAbortablePrecleanTime=6000 -XX:+CMSParallelRemarkEnabled > -XX:+ParallelRefProcEnabled -verbose:gc -XX:+PrintHeapAtGC > -XX:+Prin
[jira] [Commented] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
[
https://issues.apache.org/jira/browse/LUCENE-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240867#comment-16240867
]
Robert Muir commented on LUCENE-8040:
-
Also I think as far as lowering the overhead to getting to a field, the better
fix is probably in BlockTreeTermsReader. Today getting to a specific field is
log N (TreeMap). Maybe it should be HashMap instead.
Either linkedhashmap or separate sorted array can be used for the "iterator"
functionality, but I think it currently optimizes for the wrong case (iterating
fields in order, versus getting to a particular field).
> Optimize IndexSearcher.collectionStatistics
> ---
>
> Key: LUCENE-8040
> URL: https://issues.apache.org/jira/browse/LUCENE-8040
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: lucenecollectionStatisticsbench.zip
>
>
> {{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
> because with each invocation it will call {{MultiFields.getTerms(...)}}. The
> effects of this are aggravated for queries with many fields since each field
> will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240864#comment-16240864
]
Shawn Heisey commented on SOLR-11611:
-
This is the actual error I'm getting when I am in the right directory:
{noformat}
C:\Users\sheisey\Downloads\solr stuff mine)\solr-7.1.0>bin\solr start
\solr-7.1.0\server\logs\solr_gc.log" -XX:+UseGCLogFileRotation -XX:NumberOfGCLog
Files=9 -XX:GCLogFileSize=20M -Xss256k !SSL_PORT_PROP!" was unexpected at this
time.
{noformat}
I've tried a few things to isolate where the problem is, but I don't have a
deep enough knowledge of Microsoft's batch language.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11612) new_core: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load conf for core new_core: Error loading solr config from /home/madguy02/
Manish Kakoti created SOLR-11612: Summary: new_core: org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: Could not load conf for core new_core: Error loading solr config from /home/madguy02/solr/server/solr/new_core/conf/solrconfig.xml Key: SOLR-11612 URL: https://issues.apache.org/jira/browse/SOLR-11612 Project: Solr Issue Type: Test Security Level: Public (Default Security Level. Issues are Public) Components: Admin UI Reporter: Manish Kakoti Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240853#comment-16240853
]
Shawn Heisey commented on SOLR-11611:
-
Ooops, I discovered taht I was in the wrong directory when I did that command,
so the error I got is not what happens. But I think there's still a problem,
just a different one.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240851#comment-16240851
]
Shawn Heisey commented on SOLR-11611:
-
It fails with either a left or right parenthesis in the path name, doesn't need
both.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240848#comment-16240848
]
Shawn Heisey commented on SOLR-11611:
-
bq. Maybe the problem is the bracket around x86! Will try this
I think we have a culprit! Will try some variations.
{noformat}
C:\Users\sheisey\Downloads\solr stuff (mine!)>bin\solr start
The system cannot find the path specified.
{noformat}
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-11412) Documentation changes for SOLR-11003: Bi-directional CDCR support
[ https://issues.apache.org/jira/browse/SOLR-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker reassigned SOLR-11412: Assignee: Varun Thacker > Documentation changes for SOLR-11003: Bi-directional CDCR support > - > > Key: SOLR-11412 > URL: https://issues.apache.org/jira/browse/SOLR-11412 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR, documentation >Reporter: Amrit Sarkar >Assignee: Varun Thacker > Attachments: CDCR-bidir.png, SOLR-11412.patch, SOLR-11412.patch, > SOLR-11412.patch > > > Since SOLR-11003: Bi-directional CDCR scenario support, is reaching its > conclusion. The relevant changes in documentation needs to be done. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_144) - Build # 20850 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20850/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.DistributedVersionInfoTest.testReplicaVersionHandling Error Message: Stack Trace: java.util.concurrent.TimeoutException at __randomizedtesting.SeedInfo.seed([EEA24FAEACB29F5C:325B98540EC9551D]:0) at org.apache.solr.common.cloud.ZkStateReader.waitForState(ZkStateReader.java:1325) at org.apache.solr.cloud.DistributedVersionInfoTest.testReplicaVersionHandling(DistributedVersionInfoTest.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 12473 lines...] [junit4] Suite: org.apache.solr.cloud.DistributedVersionInfoTest [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-core/test/J1/temp/solr.cloud.DistributedVersionInfoTest_EEA24FAEACB29F5C-001/init-core-data-001 [juni
[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 290 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/290/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudDeleteByQuery Error Message: Could not find collection:test_col Stack Trace: java.lang.AssertionError: Could not find collection:test_col at __randomizedtesting.SeedInfo.seed([BAC81BD627CE0B7E]: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:155) at org.apache.solr.cloud.TestCloudDeleteByQuery.createMiniSolrCloudCluster(TestCloudDeleteByQuery.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudDeleteByQuery Error Message: Stack Trace: java.lang.NullPointerException at __randomizedtesting.SeedInfo.seed([BAC81BD627CE0B7E]:0) at org.apache.solr.cloud.TestCloudDeleteByQuery.afterClass(TestCloudDeleteByQuery.java:88) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) 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
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240780#comment-16240780
]
Uwe Schindler commented on SOLR-11611:
--
Maybe the problem is the bracket around x86! Will try this later.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240778#comment-16240778
]
Uwe Schindler commented on SOLR-11611:
--
Windows 10 also German like the reporter also worked. I also test this before
every release.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8034) SpanNotWeight returns wrong results due to integer overflow
[
https://issues.apache.org/jira/browse/LUCENE-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240759#comment-16240759
]
Hari Menon commented on LUCENE-8034:
[~rcmuir] That makes sense. I'll make that change. I'll actually remove the
asserts, as all we need to verify that the hit was returned. So `checkHits()`
should be enough.
> SpanNotWeight returns wrong results due to integer overflow
> ---
>
> Key: LUCENE-8034
> URL: https://issues.apache.org/jira/browse/LUCENE-8034
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/query/scoring, core/search
>Reporter: Hari Menon
>Priority: Minor
> Labels: newbie, patch
> Attachments: LUCENE-8034.patch
>
>
> In SpanNotQuery, there is an acceptance condition:
> {code:java}
> if (candidate.endPosition() + post <= excludeSpans.startPosition()) {
> return AcceptStatus.YES;
> }
> {code}
> This overflows in case `candidate.endPosition() + post > Integer.MAX_VALUE`.
> I have a fix for this which I am working on. Basically I am flipping the add
> to a subtract.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240747#comment-16240747
]
Shawn Heisey commented on SOLR-11611:
-
bq. Is this powershell again or cmd?
When I did it for the info pasted above, I was in a Command Prompt. But if I
do the same thing in powershell, it also works.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11578) Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a more accurate representation of the cluster
[ https://issues.apache.org/jira/browse/SOLR-11578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit updated SOLR-11578: - Attachment: SOLR-11578.patch NRT_Tooltip.png OnFirefox.png OnSafari.png TLOG_Tooltip.png jquery-ui.min.css jquery-ui.min.js jquery-ui.structure.min.css [~erickerickson] Added a tooltip in addition to the replica types which will be indicated besides the replicas. Details which will be indicated on the tooltip (screenshot attached): 1. CoreNodeName 2. Core 3. BaseURL, 4. Node_name 5. State 6. Replica types Tested on browsers (OS: mac OSSierra 10.12.6 ) a. Chrome (Version 62.0.3202.75 (Official Build) (64-bit)) b. Firefox (56.0.2 64 bit) c. Safari (Version 11.0.1 (12604.3.5.1.1)) Un-versioned components (http://jqueryui.com/download/) Added additional JS library (jQuery-ui JS and corresponding jQuery UI and UI Structure CSS components minified version: Path for jQueryUI CSS: a. solr/webapp/web/css/angular/jquery-ui.min.css b. solr/webapp/web/css/angular/jquery-ui.min.css Path for jQueryUI JS: a. solr/webapp/web/css/angular/jquery-ui.min.css Suggestions and review are welcomed. > Solr 7 Admin UI (Cloud > Graph) should reflect the Replica type to give a > more accurate representation of the cluster > - > > Key: SOLR-11578 > URL: https://issues.apache.org/jira/browse/SOLR-11578 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.0, 7.1 >Reporter: Rohit >Priority: Minor > Attachments: NRT_Tooltip.png, OnFirefox.png, OnSafari.png, > SOLR-11578.patch, SOLR-11578.patch, TLOG_Tooltip.png, Updated Graph.png, > Updated Legend.png, Updated Radial Graph.png, jquery-ui.min.css, > jquery-ui.min.js, jquery-ui.structure.min.css > > > New replica types were introduced in Solr 7. > 1. The Solr Admin UI --> Cloud --> Graph mode should be updated to reflect > the new replica types (NRT, TLOG, PULL) > 2. It will give a better overview of the cluster as well as help in > troubleshooting and diagnosing issues. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
[
https://issues.apache.org/jira/browse/LUCENE-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240728#comment-16240728
]
Robert Muir commented on LUCENE-8040:
-
I don't think we should add caching to the indexsearcher, as it is supposed to
remain lightweight. Instead of using MultiFields, we should just sum up the
stats per segment as a start. This is easier now that the statistics can no
longer be -1.
> Optimize IndexSearcher.collectionStatistics
> ---
>
> Key: LUCENE-8040
> URL: https://issues.apache.org/jira/browse/LUCENE-8040
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: lucenecollectionStatisticsbench.zip
>
>
> {{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
> because with each invocation it will call {{MultiFields.getTerms(...)}}. The
> effects of this are aggravated for queries with many fields since each field
> will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 2163 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2163/
3 tests failed.
FAILED: org.apache.solr.cloud.AddReplicaTest.test
Error Message:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:37363/solr","node_name":"127.0.0.1:37363_solr","state":"active","type":"NRT"}
Stack Trace:
java.lang.AssertionError:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:37363/solr","node_name":"127.0.0.1:37363_solr","state":"active","type":"NRT"}
at
__randomizedtesting.SeedInfo.seed([2CFC9153E32D2E19:A4A8AE894DD143E1]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi
Error Message:
expected:<1> but was:<0>
Stack Tra
[jira] [Updated] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
[
https://issues.apache.org/jira/browse/LUCENE-8040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-8040:
-
Attachment: lucenecollectionStatisticsbench.zip
I considered a few alternatives to this today using JMH:
* Cache MultiFields on the IndexSearcher
* Compute the CollectionStatics raw, immediately (don't lookup or cache)
* Add a ConcurrentHashMap on the IndexSearcher and
compute on demand.
Attached is the JMH benchmark program. Between runs I would change line 78 to
call out to the impl I wanted to try. JMH Main method is
"org.openjdk.jmh.Main" and I used args "-wi 5 -i 5 -f 1"
My annotated results are:
{noformat}
Result "dsmiley.MyBenchmark.bench":IndexSearcher
1146.739 ±(99.9%) 280.645 us/op [Average]
(min, avg, max) = (1034.410, 1146.739, 1238.123), stdev = 72.883
CI (99.9%): [866.094, 1427.385] (assumes normal distribution)
Result "dsmiley.MyBenchmark.bench":cached MultiFields
29.556 ±(99.9%) 8.929 us/op [Average]
(min, avg, max) = (27.409, 29.556, 33.424), stdev = 2.319
CI (99.9%): [20.626, 38.485] (assumes normal distribution)
Result "dsmiley.MyBenchmark.bench":raw compute
951.494 ±(99.9%) 182.555 us/op [Average]
(min, avg, max) = (904.328, 951.494, 1024.473), stdev = 47.409
CI (99.9%): [768.940, 1134.049] (assumes normal distribution)
Result "dsmiley.MyBenchmark.bench": ConcurrentHashMap
4.448 ±(99.9%) 1.268 us/op [Average]
(min, avg, max) = (4.090, 4.448, 4.860), stdev = 0.329
CI (99.9%): [3.180, 5.717] (assumes normal distribution)
For 5 fields:
raw: 10.716
ConcurrentHashMap: 0.155 us/op
{noformat}
I think the results are pretty clear that we should go with the
ConcurrentHashMap.
I'm aware my benchmark implementation of this needs some more work. If an
IOException is thrown it should pass through without RuntimeException wrapper.
And if the field doesn't exist, we want to return null.
> Optimize IndexSearcher.collectionStatistics
> ---
>
> Key: LUCENE-8040
> URL: https://issues.apache.org/jira/browse/LUCENE-8040
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/search
>Reporter: David Smiley
>Assignee: David Smiley
> Fix For: 7.2
>
> Attachments: lucenecollectionStatisticsbench.zip
>
>
> {{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
> because with each invocation it will call {{MultiFields.getTerms(...)}}. The
> effects of this are aggravated for queries with many fields since each field
> will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8040) Optimize IndexSearcher.collectionStatistics
David Smiley created LUCENE-8040:
Summary: Optimize IndexSearcher.collectionStatistics
Key: LUCENE-8040
URL: https://issues.apache.org/jira/browse/LUCENE-8040
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Reporter: David Smiley
Assignee: David Smiley
Fix For: 7.2
{{IndexSearcher.collectionStatistics(field)}} can do a fair amount of work
because with each invocation it will call {{MultiFields.getTerms(...)}}. The
effects of this are aggravated for queries with many fields since each field
will want statistics, and also aggravated when there are many segments.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8039) Geo3d: Need a "distance delta" distance metric for paths and circles
Karl Wright created LUCENE-8039: --- Summary: Geo3d: Need a "distance delta" distance metric for paths and circles Key: LUCENE-8039 URL: https://issues.apache.org/jira/browse/LUCENE-8039 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial3d Affects Versions: 7.1 Reporter: Karl Wright Assignee: Karl Wright The current "distance" method for a path returns a distance computed along the path and then perpendicular to the path. But, at least in the case of paths, it is often preferable to compute a "delta" distance, which would be the minimum straight-line distance assuming a diversion to reach the provided point. A similar "distance delta" for a circle would be defined as returning a number exactly the same as is currently returned, with the understanding that the point given would be the destination and not a new waypoint. Similarly, the distance beyond the end of a path to the provided point would be counted only once, while the distance before the beginning of the path would be counted twice (one leg to the point, and the other leg back from that point to the start point (or nearest path point, if closer). This obviously must be implemented in a backwards-compatible fashion. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11584) Ref Guide: support Bootstrap components like tabs and pills
[
https://issues.apache.org/jira/browse/SOLR-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240652#comment-16240652
]
Hoss Man commented on SOLR-11584:
-
I forgot to mention...
{quote}
bq. I also noticed that when the content on the tabs are very different sizes,
switching between tabs can be a little jarring, as the reset of the page shifts
up/down to accommodate the size of the newly-chosen tab.
A panel that expands on the user click might be a better way for that
particular content - then the user would expect the page to shift up or down -
but that requires even more nested div elements, and I have to think a little
bit more on how to do that with Asciidoctor's current limitations ...
{quote}
...i briefly looked into some of bootstraps "transition" options and i suspsect
there should be a way to combine the "expand/collapse" transition that
gradually resizes a div with the pill+tab show/hide logic -- i just haven't
figured out what hte magic combination of css+javascript is.
If we need new/extra/special divs/markup to make this work, we can almost
certainly make the custom javascript add this markup (just like it currently
generates the pills)
> Ref Guide: support Bootstrap components like tabs and pills
> ---
>
> Key: SOLR-11584
> URL: https://issues.apache.org/jira/browse/SOLR-11584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Cassandra Targett
>Assignee: Cassandra Targett
>Priority: Minor
> Fix For: 7.2
>
> Attachments: SOLR-11584.patch, SOLR-11584_customjs.patch,
> refguide-tabs.png, tabbed_api_output_example.png
>
>
> The theme I initially copied as the basis for the new Ref Guide included a
> Bootstrap integration, which has the potential to provide us with a number of
> options, such as organizing some content on a page into tabs (to present the
> same information in multiple ways - such as Windows vs Unix commands, or
> hand-editing schema.xml/managed-schema vs Schema API examples).
> However, the way AsciiDoctor content is inserted into a Jekyll template made
> it difficult to know how to use some of Bootstrap's features. Particularly
> since we have to make sure whatever we put into the content comes out right
> in the PDF.
> I had a bit of a breakthrough on this, and feel confident we can make
> straightforward instructions for anyone who might want to add this feature to
> their content. A patch will follow shortly with more details but the summary
> is:
> * Add an AsciiDoctor passthrough block that includes the Bootstrap HTML code
> to create the tabs.
> ** This has an {{ifdef::backend-html5[]}} rule on it, so it will only be used
> if the output format is HTML. The PDF will ignore this section entirely.
> * Use AsciiDoctor's "role" support to name the proper class names, which
> AsciiDoctor will convert into the right {{}} elements in the HTML.
> ** These will take multiple class names and a section ID, which is perfect
> for our needs.
> ** One caveat is the divs need to be properly nested, and must be defined on
> blocks so all the content is inserted into the tab boxes appropriately. This
> gets a little complicated because you can't nest blocks of the same type
> (yet), but I found two block types we aren't using otherwise.
> ** The PDF similarly ignores these classes and IDs because it doesn't know
> what to do with custom classes (but in the future these may be supported and
> we could define these in a special way if we want).
> * Modify some of the CSS to display the way we want since AsciiDoctor inserts
> some of its own classes between the defined classes and the inheritance needs
> to be set up right. Also the default styling for the blocks needs to be
> changed so it doesn't look strange.
> I'll include a patch with a sample file that has this working, plus detailed
> instructions in the metadocs. In the meantime, I've attached a screenshot
> that shows a small snippet from my testing.
> While the focus here is using tabs & pills, we will be able to use the same
> principles to support collapsing sections if that's preferred for
> presentation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3191) field exclusion from fl
[ https://issues.apache.org/jira/browse/SOLR-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240649#comment-16240649 ] ASF GitHub Bot commented on SOLR-3191: -- GitHub user sstults opened a pull request: https://github.com/apache/lucene-solr/pull/271 SOLR-3191: Fixes earlier issues with the patch, namely CSVWriter and … …streaming errors You can merge this pull request into a Git repository by running: $ git pull https://github.com/sstults/lucene-solr jira/solr-3191 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/271.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #271 commit a1b4c8f5307cf533a2abe2557b35fd105a12022a Author: Scott Stults Date: 2017-11-06T18:15:05Z SOLR-3191: Fixes earlier issues with the patch, namely CSVWriter and streaming errors > field exclusion from fl > --- > > Key: SOLR-3191 > URL: https://issues.apache.org/jira/browse/SOLR-3191 > Project: Solr > Issue Type: Improvement >Reporter: Luca Cavanna >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch, > SOLR-3191.patch, SOLR-3191.patch, SOLR-3191.patch > > > I think it would be useful to add a way to exclude field from the Solr > response. If I have for example 100 stored fields and I want to return all of > them but one, it would be handy to list just the field I want to exclude > instead of the 99 fields for inclusion through fl. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #271: SOLR-3191: Fixes earlier issues with the patc...
GitHub user sstults opened a pull request: https://github.com/apache/lucene-solr/pull/271 SOLR-3191: Fixes earlier issues with the patch, namely CSVWriter and ⦠â¦streaming errors You can merge this pull request into a Git repository by running: $ git pull https://github.com/sstults/lucene-solr jira/solr-3191 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/271.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #271 commit a1b4c8f5307cf533a2abe2557b35fd105a12022a Author: Scott Stults Date: 2017-11-06T18:15:05Z SOLR-3191: Fixes earlier issues with the patch, namely CSVWriter and streaming errors --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11584) Ref Guide: support Bootstrap components like tabs and pills
[
https://issues.apache.org/jira/browse/SOLR-11584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-11584:
Attachment: SOLR-11584_customjs.patch
bq. ... Since most people don't run the HTML conversion locally before
committing, they may not know if they got it wrong until after it's published.
...
As of SOLR-10934, we now have a tool box to help us reduce the risk of these
types of "structural" mistakes, because "build-pdf" now also builds a barebones
HTML5 version (w/o jekyll) that we can run anchor+link checking against. We
could also use it to run other forms of structural validation in the future
(see more comments on this below) and ultimately hook it in to precommit if we
don't trust people to run "ant build-pdf" after changing the ref-guide pages.
bq. IOW, it's fiddly, as they say - if someone doesn't get all the parts
exactly right, we could end up with a mess. ... I chatted with Hoss Man
offline about it, and he promised to take a look to see if there is a way to do
this via a macro, or some other way that's less easy to mess up.
There's definitely some options for making these less error-prone.
When cassandra first showed me what she had in mind, and her POC, my initial
impression was that an asciidoctor macro of some kind would be the way to go --
but the more i looked at the diff asciidoctor "block types" that already exist,
and the way asciidoctor's html5 output will directly map user defined "roles"
to CSS classes, i started realizing that the problem isn't really asciidoctor
-- it's bootstrap's lack of "bootstrapping" tabs/pills/buttons based on content.
So instead what i did was write some javascript to "bootstrap bootstrap" --
automatically generating the pills we want based on the tab-panes and a new
"tab-label" we define. If/when we decide we want to take advantage of other
dynamic bootstrap page features, similar custom javascript will be easy.
In a nutshell, instead of something like this...
{code}
ifdef::backend-html5[]
XXX Label
YYY Label
endif::[]
[.tab-content]
--
[example.tab-pane.active#fooXXX]
*XXX Label*
blah blah blah blah blah blah blah blah ...
[example.tab-pane#fooYYY]
*YYY Label*
[source,text]
blah blah blah blah blah blah blah blah ...
--
{code}
All we have to do is write this...
{code}
[.dynamic-tabs]
--
[example.tab-pane#fooXXX]
[.tab-label]*XXX Label*
blah blah blah blah blah blah blah blah ...
[example.tab-pane#fooYYY]
[.tab-label]*YYY Label*
[source,text]
blah blah blah blah blah blah blah blah ...
--
{code}
...and custom javascript takes care of building up the "pill" links and giving
everything the CSS classes and data-\* attributes that bootstrap expects.
Since this all runs in javascript, it means that if javascript is disabled, the
html never includes the useless pill links.
A few things to note about this javascript that are all easily tweakable based
on the conventions we want:
* I used {{dynamic-tabs}} as the special CSS class the custom javascript looks
for, and when it finds it it adds the {{tab-content}} class that bootstrap
requires -- 2 reasons for this:
** this way there's less risk that our custom javascript accidently breaks
{{tab-content}} that exists in our jekyll header/footer
** this means we could (if we want) style this stuff differently depending on
wether javascript is disabled
* the code currently assumes we always want the force the *first* {{tab-pane}}
to be the active tab pane/pill
** i feel like as a matter of convention this is just a blanket good idea
** this code could be tweaked so it checks if any tab pane has a user specified
{{active}} class, then it automatically sets the corrisponding pill as active
(to meet bootstraps preconditions)
*** but if we want to do this we have to decide what the rules should be if a
user copy/pasts a tab-pane and there are 2 active ones (pick the first? pick
the last?)
*** the custom html validation code we have could always fail if it detects
this ... just a matter of writting that validation code
* the custom javascript assumes that every tab-pane have a custom id defined
** no real way to avoid that in order for the pills to work -- but we could
make the HTML hide any tab that's missing it to draw attention to it
** again: our custom html anchor+link checking code could start failing the
build if a {{tab-pane}} exists w/o an id
* the {{tab-label}} class is how the custom java code decides what text to put
in the auto-generated pill
** currently the code _removes_ the tab label from the tab-pane itself -- so
the text doesn't appear redundently when a tab is visible -- but there's no
reason we can't leave it in if people think it looks better
** the code also currently uses the _inner_ html of the label -- so in the case
if {{\*Some \_stuff\_\*}} the pill text won't be bol
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_144) - Build # 758 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/758/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.cloud.TestStressInPlaceUpdates.stressTest Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:42407 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:42407 at __randomizedtesting.SeedInfo.seed([3553EFFD77B28740:5E353050496753BA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) a
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240576#comment-16240576
]
Dawid Weiss commented on SOLR-11611:
Is this powershell again or cmd?
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10934) create a link+anchor checker for the ref-guide that only depends on ivy resources
[ https://issues.apache.org/jira/browse/SOLR-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-10934. - Resolution: Fixed Fix Version/s: master (8.0) 7.2 > create a link+anchor checker for the ref-guide that only depends on ivy > resources > - > > Key: SOLR-10934 > URL: https://issues.apache.org/jira/browse/SOLR-10934 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 7.2, master (8.0) > > Attachments: SOLR-10934.patch, SOLR-10934.patch > > > We currently have CheckLinksAndAnchors.java which is automatically run > against the ref-guide HTML as part of the build to use JSoup to find bad > links/anchors that asciidoctor doesn't complain about -- but not everyone > does/can build the HTML version of the ref-guide sincif we can e it requires > manually installing jekyll. > This issue initially focused on trying to use PDFBox to do link+anchor > checking directly against the "final" PDF, but by that point a lot of > information that indicates problems (dup anchors, links pointing to the wrong > place in the document, etc...) is already lost. > The current focus is on a way to catch all of the same types of problems we > can currently catch today, in a way that anyone can run purely from ant -- > w/o any manually instaled tools like jekyll. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240543#comment-16240543
]
Shawn Heisey commented on SOLR-11611:
-
Running "winver" shows Windows 7 Enterprise. Version info is "Version 6.1
(Build 7601: Service Pack 1)".
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 291 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/291/ Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.asserting.TestAssertingPostingsFormat Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001\testPostingsFormat.testExact-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001\testPostingsFormat.testExact-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001\testPostingsFormat.testExact-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001\testPostingsFormat.testExact-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\lucene\build\test-framework\test\J1\temp\lucene.codecs.asserting.TestAssertingPostingsFormat_370308D264E2E32F-001 at __randomizedtesting.SeedInfo.seed([370308D264E2E32F]:0) at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329) at org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216) at com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: junit.framework.TestSuite.org.apache.solr.analytics.function.mapping.GTEFunctionTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001 Stack Trace: java.io.IOException: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001\init-core-data-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001\init-core-data-001 C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\contrib\solr-analytics\test\J1\temp\solr.analytics.function.mapping.GTEFunctionTest_7A5007A99C58F15C-001: ja
[jira] [Updated] (SOLR-11590) Synchronize ZK connect/disconnect handling
[
https://issues.apache.org/jira/browse/SOLR-11590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-11590:
-
Attachment: SOLR-11590.patch
Small update to the patch. I took the previous patch and added an additional
logging statement to ConnectionManager
> Synchronize ZK connect/disconnect handling
> --
>
> Key: SOLR-11590
> URL: https://issues.apache.org/jira/browse/SOLR-11590
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Noble Paul
> Attachments: SOLR-11590.patch, SOLR-11590.patch
>
>
> Here is a sequence of 2 disconnects and re-connects
> {code}
> 1. 2017-10-31T08:34:23.106-0700 Watcher
> org.apache.solr.common.cloud.ConnectionManager@1579ca20
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:34:23.106-0700 zkClient has disconnected
> 3. 2017-10-31T08:34:23.107-0700 Watcher
> org.apache.solr.common.cloud.ConnectionManager@1579ca20
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent
> state:SyncConnected type:None path:null path:null type:None
> {code}
> {code}
> 1. 2017-10-31T08:36:46.541-0700 Watcher
> org.apache.solr.common.cloud.ConnectionManager@1579ca20
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent
> state:Disconnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.549-0700 Watcher
> org.apache.solr.common.cloud.ConnectionManager@1579ca20
> name:ZooKeeperConnection Watcher:host:port got event WatchedEvent
> state:SyncConnected type:None path:null path:null type:None
> 2. 2017-10-31T08:36:46.563-0700 zkClient has disconnected
> {code}
> In the first disconnect the sequence is - get disconnect watcher, execute
> disconnect code, execute connect code
> In the second disconnect the sequence is - get disconnect watcher, execute
> connect code, execute disconnect code
> In the second sequence of events, if the JVM has leader replicas then all
> updates start failing with "Cannot talk to ZooKeeper - Updates are disabled."
> . This starts happening exactly after 27 seconds ( zk client timeout is 30s ,
> 90% of 30 = 27 - when the code thinks the session is likely expired). No
> leadership changes since there was no session expiry. Unless you restart the
> node all updates to the system continue to fail.
> These log lines correspond are from Solr 5.3 hence where the WatchedEvent was
> still being logged as INFO
> We process the connect code and then process the disconnect code out of order
> based on the log ordering. The connection is active but the flag is not set
> and hence after 27 seconds {{zkCheck}} starts complaining that the connection
> is likely expired
> A related Jira is SOLR-5721
> ZK gives us ordered watch events (
> https://zookeeper.apache.org/doc/r3.4.8/zookeeperProgrammers.html#sc_WatchGuarantees
> ) but from what I understand Solr can still process them out of order. We
> could take a lock and synchronize {{ConnectionManager#connected}} and
> {{ConnectionManager#disconnected}} .
> Would that be the right approach to take?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover
[ https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker resolved SOLR-11003. -- Resolution: Fixed Fix Version/s: 7.2 Thanks Amrit ! > Enabling bi-directional CDCR on cluster for better failover > --- > > Key: SOLR-11003 > URL: https://issues.apache.org/jira/browse/SOLR-11003 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker > Fix For: 7.2 > > Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > sample-configs.zip > > > The latest version of Solr CDCR across collections / clusters is in > active-passive format, where we can index into source collection and the > updates gets forwarded to the passive one and vice-versa is not supported. > https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html > https://issues.apache.org/jira/browse/SOLR-6273 > We are try to get a design ready to index in both collections and the > updates gets reflected across the collections in real-time (given the backlog > of replicating updates to other data center). ClusterACollectionA => > ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA. > The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which > forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets > down, we point the indexer and searcher application to ClusterBCollectionB. > Once ClusterACollectionA is up, depending on updates count, they will be > bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and > keep indexing on the ClusterBCollectionB. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover
[ https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240499#comment-16240499 ] ASF subversion and git services commented on SOLR-11003: Commit fdff8deabdffe6a840fc1cbb5eb249aaed3fed63 in lucene-solr's branch refs/heads/master from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fdff8de ] SOLR-11003: Improve description of the feature in the CHANGES file > Enabling bi-directional CDCR on cluster for better failover > --- > > Key: SOLR-11003 > URL: https://issues.apache.org/jira/browse/SOLR-11003 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker > Fix For: 7.2 > > Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > sample-configs.zip > > > The latest version of Solr CDCR across collections / clusters is in > active-passive format, where we can index into source collection and the > updates gets forwarded to the passive one and vice-versa is not supported. > https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html > https://issues.apache.org/jira/browse/SOLR-6273 > We are try to get a design ready to index in both collections and the > updates gets reflected across the collections in real-time (given the backlog > of replicating updates to other data center). ClusterACollectionA => > ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA. > The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which > forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets > down, we point the indexer and searcher application to ClusterBCollectionB. > Once ClusterACollectionA is up, depending on updates count, they will be > bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and > keep indexing on the ClusterBCollectionB. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover
[ https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240498#comment-16240498 ] ASF subversion and git services commented on SOLR-11003: Commit a0163232edfaa3068c6240a352781e0637f53b1c in lucene-solr's branch refs/heads/branch_7x from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a016323 ] SOLR-11003: Improve description of the feature in the CHANGES file > Enabling bi-directional CDCR on cluster for better failover > --- > > Key: SOLR-11003 > URL: https://issues.apache.org/jira/browse/SOLR-11003 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker > Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > sample-configs.zip > > > The latest version of Solr CDCR across collections / clusters is in > active-passive format, where we can index into source collection and the > updates gets forwarded to the passive one and vice-versa is not supported. > https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html > https://issues.apache.org/jira/browse/SOLR-6273 > We are try to get a design ready to index in both collections and the > updates gets reflected across the collections in real-time (given the backlog > of replicating updates to other data center). ClusterACollectionA => > ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA. > The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which > forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets > down, we point the indexer and searcher application to ClusterBCollectionB. > Once ClusterACollectionA is up, depending on updates count, they will be > bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and > keep indexing on the ClusterBCollectionB. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11003) Enabling bi-directional CDCR on cluster for better failover
[ https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240493#comment-16240493 ] ASF subversion and git services commented on SOLR-11003: Commit a30c92a79cd75d3c4fe21829e70292f8314afd4f in lucene-solr's branch refs/heads/branch_7x from [~varunthacker] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a30c92a ] SOLR-11003: Support bi-directional syncing of cdcr clusters. We still only support actively into one cluster cluster, but have the ability to switch indexing clusters and cdcr will replicate correctly > Enabling bi-directional CDCR on cluster for better failover > --- > > Key: SOLR-11003 > URL: https://issues.apache.org/jira/browse/SOLR-11003 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker > Attachments: SOLR-11003-tlogutils.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, > sample-configs.zip > > > The latest version of Solr CDCR across collections / clusters is in > active-passive format, where we can index into source collection and the > updates gets forwarded to the passive one and vice-versa is not supported. > https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html > https://issues.apache.org/jira/browse/SOLR-6273 > We are try to get a design ready to index in both collections and the > updates gets reflected across the collections in real-time (given the backlog > of replicating updates to other data center). ClusterACollectionA => > ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA. > The STRONG RECOMMENDED way to keep indexing in ClusterACollectionA which > forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets > down, we point the indexer and searcher application to ClusterBCollectionB. > Once ClusterACollectionA is up, depending on updates count, they will be > bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and > keep indexing on the ClusterBCollectionB. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240484#comment-16240484
]
Shawn Heisey commented on SOLR-11611:
-
I tried it exactly how the initial description showed it -- sitting in the
"bin" directory and running the script from there. That also worked.
{noformat}
C:\Users\sheisey\Downloads\solr stuff\solr-7.1.0\bin>solr.cmd start
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!
{noformat}
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20849 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20849/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestRandomFlRTGCloud Error Message: Error from server at http://127.0.0.1:39153/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:39153/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([829337E132891BBA]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.TestRandomFlRTGCloud.createMiniSolrCloudCluster(TestRandomFlRTGCloud.java:144) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.AutoScalingHandlerTest.testReadApi Error Message: Error from server at http://127.0.0.1:42487/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:42487/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([829337E132891BBA:D5BACC54E97BF9A1]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LB
[jira] [Commented] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
[
https://issues.apache.org/jira/browse/SOLR-11611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240476#comment-16240476
]
Shawn Heisey commented on SOLR-11611:
-
I cannot reproduce this. I created a directory with a space in it, put the
extracted solr 7.1.0 download in that directory, then started Solr and created
a core.
{noformat}
C:\Users\sheisey\Downloads\solr stuff\solr-7.1.0>bin\solr start
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!
C:\Users\sheisey\Downloads\solr stuff\solr-7.1.0>bin\solr create -c bar
WARNING: Using _default configset. Data driven schema functionality is enabled b
y default, which is
NOT RECOMMENDED for production use.
To turn it off:
curl http://localhost:8983/solr/bar/config -d '{"set-user-property":
{"update.autoCreateFields":"false"}}'
Created new core 'bar'
{noformat}
The admin UI is fully functional when I do this.
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> -
>
> Key: SOLR-11611
> URL: https://issues.apache.org/jira/browse/SOLR-11611
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCLI
>Affects Versions: 7.1
> Environment: Microsoft Windows [Version 10.0.15063]
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
>Reporter: Jakob Furrer
> Fix For: 7.2
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Starting Solr using solr.cli fails in Windows, when the path contains spaces.
> Use the following example to reproduce the error:
> {{C:\>c:
> C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
> Volume in Laufwerk C: hat keine Bezeichnung.
> Volumeseriennummer: 8207-3B8B
> Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
> 06.11.2017 15:52 .
> 06.11.2017 15:52 ..
> 06.11.2017 15:39 init.d
> 03.11.2017 17:32 8 209 post
> 03.11.2017 17:3275 963 solr
> 06.11.2017 14:2469 407 solr.cmd
>3 Datei(en),153 579 Bytes
>3 Verzeichnis(se), 51 191 619 584 Bytes frei
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
> *"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
> C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8014) Remove SimScorer.computeSlopFactor and SimScorer.computePayloadFactor
[ https://issues.apache.org/jira/browse/LUCENE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240425#comment-16240425 ] Alan Woodward edited comment on LUCENE-8014 at 11/6/17 3:15 PM: Should we do the hardcoding of computeSlopFactor directly in 7.2, or just deprecate it and defer to 8.0? was (Author: romseygeek): Should we do the hardcoding of computeSlopFactor directly in 7.2, just deprecate it and defer to 8.0? > Remove SimScorer.computeSlopFactor and SimScorer.computePayloadFactor > - > > Key: LUCENE-8014 > URL: https://issues.apache.org/jira/browse/LUCENE-8014 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > > This supersedes LUCENE-8013. > We should hardcode computeSlopFactor to 1/(N+1) in SloppyPhraseScorer and > move computePayloadFactor to PayloadFunction so that all the payload scoring > logic is in a single place. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8014) Remove SimScorer.computeSlopFactor and SimScorer.computePayloadFactor
[ https://issues.apache.org/jira/browse/LUCENE-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240425#comment-16240425 ] Alan Woodward commented on LUCENE-8014: --- Should we do the hardcoding of computeSlopFactor directly in 7.2, just deprecate it and defer to 8.0? > Remove SimScorer.computeSlopFactor and SimScorer.computePayloadFactor > - > > Key: LUCENE-8014 > URL: https://issues.apache.org/jira/browse/LUCENE-8014 > Project: Lucene - Core > Issue Type: Task >Reporter: Adrien Grand >Priority: Minor > > This supersedes LUCENE-8013. > We should hardcode computeSlopFactor to 1/(N+1) in SloppyPhraseScorer and > move computePayloadFactor to PayloadFunction so that all the payload scoring > logic is in a single place. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11487) Collection Alias metadata for time partitioned collections
[
https://issues.apache.org/jira/browse/SOLR-11487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240417#comment-16240417
]
David Smiley commented on SOLR-11487:
-
Aliases
* constructor is confusing to me; you save aliasMap to a field and *then* swap
with EMPTY_MAP if you can? Why not before? And maybe we can simply not bother
with initializing the metadata map here... worry about that when we
get/populate it. It'll probably simplify seeing that the get/set code for it in
other methods will be correct since won't require assumptions about being
initialized.
* in general... these changes invoke "convertMapOfCommaDelimitedToMapOfList"
way more than before. It used to be only at Alias construction, now it's at
every call to resolveAliases (!) and getCollectionAliasListMap. Sorry but can
we avoid that? I think it's not a big deal to lazy split the value for the
particular collection being requested, but doing so for all collections seems
excessive to me.
* convertMapOfCommaDelimitedToMapOfList: you've converted this to Java 8
streams which is fine. However you've wrapped the result in new LinkedHashMap
which actually doesn't retain the original order of the input since
Collectors.toMap is going to use a HashMap inbetween. toMap is overloaded with
a Supplier; you can call that one suppling the LinkedHashMap.
* The introduced use of a field priorChange Function seems really hokey; I
sorta see what you're doing with it but I think we need to go about this in
some other way. It feels like too much of a wart on Aliases. Maybe we can chat
about this on IRC.
*From a Solr API perspective, it seems we've forgotten to expose the read/write
of metadata; no? (!)* I feel badly I didn't recognize this earlier; it's
obvious in retrospect. When in Solr tests we can work directly with ZooKeeper
and Solr's internals, it's easy to forget the need for a public API.
ZkStateReader
* exportAliasToZk computes a new Aliases instance at the first line
(Aliases.cloneWithCollectionAlias) before calling exportAllAlias then
checkForAlias, both of which have loops to do their jobs with retries /
re-checking. It's hard for me to see how this is correct... shouldn't
Aliases.cloneWithCollectionAlias be called _within_ a loop?
* nice use of aliasLock with wait & notifyAll
* minor: aliasWatcher & aliasLock fields should probably be adjacent to aliases.
> Collection Alias metadata for time partitioned collections
> --
>
> Key: SOLR-11487
> URL: https://issues.apache.org/jira/browse/SOLR-11487
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: David Smiley
> Attachments: SOLR_11487.patch, SOLR_11487.patch, SOLR_11487.patch,
> SOLR_11487.patch
>
>
> SOLR-11299 outlines an approach to using a collection Alias to refer to a
> series of collections of a time series. We'll need to store some metadata
> about these time series collections, such as which field of the document
> contains the timestamp to route on.
> The current {{/aliases.json}} is a Map with a key {{collection}} which is in
> turn a Map of alias name strings to a comma delimited list of the collections.
> _If we change the comma delimited list to be another Map to hold the existing
> list and more stuff, older CloudSolrClient (configured to talk to ZooKeeper)
> will break_. Although if it's configured with an HTTP Solr URL then it would
> not break. There's also some read/write hassle to worry about -- we may need
> to continue to read an aliases.json in the older format.
> Alternatively, we could add a new map entry to aliases.json, say,
> {{collection_metadata}} keyed by alias name?
> Perhaps another very different approach is to attach metadata to the
> configset in use?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11611) Starting Solr using solr.cli fails in Windows, when the path contains spaces.
Jakob Furrer created SOLR-11611:
---
Summary: Starting Solr using solr.cli fails in Windows, when the
path contains spaces.
Key: SOLR-11611
URL: https://issues.apache.org/jira/browse/SOLR-11611
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCLI
Affects Versions: 7.1
Environment: Microsoft Windows [Version 10.0.15063]
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)
Reporter: Jakob Furrer
Fix For: 7.2
Starting Solr using solr.cli fails in Windows, when the path contains spaces.
Use the following example to reproduce the error:
{{C:\>c:
C:\>cd "C:\Program Files (x86)\Company Name\ProductName Solr\bin"
C:\Program Files (x86)\Company Name\ProductName Solr\bin>dir
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 8207-3B8B
Verzeichnis von C:\Program Files (x86)\Company Name\ProductName Solr\bin
06.11.2017 15:52 .
06.11.2017 15:52 ..
06.11.2017 15:39 init.d
03.11.2017 17:32 8 209 post
03.11.2017 17:3275 963 solr
06.11.2017 14:2469 407 solr.cmd
3 Datei(en),153 579 Bytes
3 Verzeichnis(se), 51 191 619 584 Bytes frei
C:\Program Files (x86)\Company Name\ProductName Solr\bin>solr.cmd start
*"\Company" kann syntaktisch an dieser Stelle nicht verarbeitet werden.*
C:\Program Files (x86)\Company Name\ProductName Solr\bin>}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.1) - Build # 757 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/757/ Java: 64bit/jdk-9.0.1 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.TestCryptoKeys.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:41383/x/p Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:41383/x/p at __randomizedtesting.SeedInfo.seed([2A24C520C1A73CA8:A270FAFA6F5B5150]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:654) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createServers(AbstractFullDistribZkTestBase.java:315) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:991) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at 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
Re: Debugging JVM security manager issues with Lucene's tests
Thanks Rob and Dawid; indeed -Dargs="-Djava.security.debug=access,failure" and -Dargs="-Djava.security.debug=all work! Mike McCandless http://blog.mikemccandless.com On Mon, Nov 6, 2017 at 5:07 AM, Dawid Weiss wrote: > I can reproduce this, Mike. There is something wrong in emitting the > Json event log -- invalid event nesting inside and > everything collapses after that. This works, as Robert pointed out: > > ant test -Dargs="-Djava.security.debug=access,failure" > -Dtestcase=TestIndexWriter -Dtests.verbose=true > > I've filed an issue and will look into it. [1] > > Dawid > > [1] https://github.com/randomizedtesting/randomizedtesting/issues/255 > > On Mon, Nov 6, 2017 at 9:00 AM, Dawid Weiss wrote: > >> messed up the communications between the test runner and ant, or > something? > > > > Looks like the json file from the forked JVM is screwed up, weird. > > I'll look into this. > > > > D. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Commented] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls
[
https://issues.apache.org/jira/browse/SOLR-11551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240310#comment-16240310
]
Shawn Heisey commented on SOLR-11551:
-
On returning 404 errors for specific conditions: I think the 400 response is a
result of consistency in another direction -- I'm not sure that Solr ever
actually returns a 404 response. When the URL is valid but information in the
parameters isn't, I think I've only ever seen 400 (request problem) and 500
(server problem) -- and not just from CoreAdmin. When a 404 response happens
(like what happens with http://host:port/solr/corename base URLs), I believe
it's typically the container that returns that error -- because the URL is
incomplete or invalid, and doesn't get mapped to Solr.
If the error message returned with the 404 is clear enough to indicate the
problem (core not found is one specific scenario) then I am completely on board
with the change. If the only actual information that Solr sends is the HTTP
code, then the change may cause more confusion than clarity. There definitely
should be a specific note made in the "upgrading" section of CHANGES.txt
indicating that HTTP response codes are changing in some circumstances -- not
just a "SOLR-11551" note about the issue being included.
> Standardize response codes and success/failure determination for core-admin
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
> Attachments: SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core
> admin api's first.
> If we are relying on response codes I think we should make the following
> change and fix all the APIs
> {code}
> interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
> }
> {code}
> To
> {code}
> interface CoreAdminOp {
> /**
> *
> * @param it request/response object
> *
> * If the request is invalid throw a SolrException with
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
> * If the execution of the command fails throw a SolrException with
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
> * Add a "error-message" key to the response object with the exception (
> this part should be done at the caller of this method so that each operation
> doesn't need to do the same thing )
> */
> void execute(CallInfo it);
> }
> {code}
> cc [~gerlowskija]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11610) Use PayloadDecoder instead of PayloadScoringSimilarityWrapper
[ https://issues.apache.org/jira/browse/SOLR-11610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated SOLR-11610: - Attachment: SOLR-11610.patch Here's a patch cutting things over to using PayloadScoreQuery's PayloadDecoder. It removes PayloadScoringSimilarityWrapper, and moves its FieldType to PayloadDecoder cache onto the IndexSchema. cc [~ehatcher] > Use PayloadDecoder instead of PayloadScoringSimilarityWrapper > - > > Key: SOLR-11610 > URL: https://issues.apache.org/jira/browse/SOLR-11610 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: SOLR-11610.patch > > > Follow up to LUCENE-8038, we should move Solr's payload handling to be in > line with the new PayloadScoreQuery methods. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-11610) Use PayloadDecoder instead of PayloadScoringSimilarityWrapper
Alan Woodward created SOLR-11610: Summary: Use PayloadDecoder instead of PayloadScoringSimilarityWrapper Key: SOLR-11610 URL: https://issues.apache.org/jira/browse/SOLR-11610 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Alan Woodward Assignee: Alan Woodward Follow up to LUCENE-8038, we should move Solr's payload handling to be in line with the new PayloadScoreQuery methods. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8038) Decouple payload decoding from Similarity
[ https://issues.apache.org/jira/browse/LUCENE-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240276#comment-16240276 ] Alan Woodward commented on LUCENE-8038: --- I think the extra flexibility could be limited to just PayloadScoreQuery, but I agree, let's just fix the API on this issue. > Decouple payload decoding from Similarity > - > > Key: LUCENE-8038 > URL: https://issues.apache.org/jira/browse/LUCENE-8038 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: LUCENE-8038-master.patch, LUCENE-8038.patch > > > PayloadScoreQuery is the only place that currently uses > SimScorer.computePayloadFactor(), and as discussed on LUCENE-8014, this seems > like the wrong place for it. We should instead add a PayloadDecoder > abstraction that is passed to PayloadScoreQuery. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20848 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20848/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testSearchRate Error Message: Error from server at https://127.0.0.1:35891/solr: create the collection time out:180s Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:35891/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([A4DCBC1D2714DF84:F994A294E8D279CB]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1096) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:875) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:808) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:183) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:200) at org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testSearchRate(TriggerIntegrationTest.java:1241) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rule
[jira] [Updated] (LUCENE-8031) DOCS_ONLY fields set incorrect length norms
[ https://issues.apache.org/jira/browse/LUCENE-8031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-8031: Attachment: LUCENE-8031.patch Here is a patch, i didn't yet improve tests and didn't address downgrading at all though. I ran omitTF experiments: mean average precision on 3 test collections, different languages, with/without stopwords, with different scoring systems. english: EnglishAnalyzer(CharArraySet.EMPTY_SET) ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.3363|0.1465|0.2080|+42.0%| |BM25|0.4492|0.2023|0.2746|+35.7%| |I(ne)B2|0.4553|0.2151|0.2801|+30.2%| |I(ne)B1|0.4231|0.1679|0.2539|+51.2%| |PL2|0.3624|0.2006|0.2656|+32.4%| |LM(dirichlet)|0.4408|0.2814|0.2851|+1.3%| |DFI(chisquare)|0.4236|0.2493|0.2819|+13.1%| EnglishAnalyzer() ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.3478|0.1651|0.2052|+24.3%| |BM25|0.4505|0.2269|0.2720|+19.9%| |I(ne)B2|0.4563|0.2401|0.2785|+16.0%| |I(ne)B1|0.4285|0.1992|0.2516|+26.3%| |PL2|0.4438|0.2182|0.2617|+19.9%| |LM(dirichlet)|0.4372|0.2827|0.2851|+0.8%| |DFI(chisquare)|0.4380|0.2637|0.2858|+8.4%| bengali: BengaliAnalyzer(CharArraySet.EMPTY_SET) ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.2326|0.1211|0.1371|+13.2%| |BM25|0.2989|0.1367|0.1673|+22.4%| |I(ne)B2|0.3111|0.1469|0.1738|+18.3%| |I(ne)B1|0.2886|0.1237|0.1520|+22.9%| |PL2|0.2906|0.1372|0.1636|+19.2%| |LM(dirichlet)|0.3007|0.1805|0.1829|+1.3%| |DFI(chisquare)|0.2938|0.1678|0.1790|+6.7%| BengaliAnalyzer() ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.2266|0.1231|0.1360|+10.5%| |BM25|0.2947|0.1390|0.1649|+18.6%| |I(ne)B2|0.3074|0.1485|0.1723|+16.0%| |I(ne)B1|0.2848|0.1248|0.1486|+19.1%| |PL2|0.2856|0.1377|0.1608|+16.8%| |LM(dirichlet)|0.2982|0.1803|0.1836|+1.8%| |DFI(chisquare)|0.2887|0.1703|0.1810|+6.3%| kurdish: SoraniAnalyzer(CharArraySet.EMPTY_SET) ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.2957|0.1625|0.1811|+11.4%| |BM25|0.3207|0.1871|0.2087|+11.5%| |I(ne)B2|0.3354|0.1937|0.2113|+9.1%| |I(ne)B1|0.3263|0.1762|0.1992|+13.1%| |PL2|0.3134|0.1738|0.2002|+15.2%| |LM(dirichlet)|0.2877|0.2130|0.2149|+0.9%| |DFI(chisquare)|0.3157|0.2014|0.2129|+5.7%| SoraniAnalyzer() ||Sim||DOCS_AND_FREQS||DOCS (master)||DOCS (patch)||diff|| |Classic|0.2977|0.1654|0.1781|+7.7%| |BM25|0.3205|0.1918|0.2077|+8.3%| |I(ne)B2|0.3345|0.1979|0.2107|+6.5%| |I(ne)B1|0.3266|0.1798|0.1970|+9.6%| |PL2|0.3115|0.1761|0.1998|+13.5%| |LM(dirichlet)|0.2815|0.2116|0.2144|+1.3%| |DFI(chisquare)|0.3143|0.2022|0.2115|+4.6%| > DOCS_ONLY fields set incorrect length norms > --- > > Key: LUCENE-8031 > URL: https://issues.apache.org/jira/browse/LUCENE-8031 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-8031.patch > > > Term frequencies are discarded in the DOCS_ONLY case from the postings list > but they still count against the length normalization, which looks like it > may screw stuff up. > I ran some quick experiments on LUCENE-8025, by encoding > fieldInvertState.getUniqueTermCount() and it seemed worth fixing (e.g. 20% or > 30% improvement potentially). Happy to do testing for real, if we want to fix. > But this seems tricky, today you can downgrade to DOCS_ONLY on the fly, and > its hard for me to think about that case (i think its generally screwed up > besides this, but still). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 226 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/226/ No tests ran. Build Log: [...truncated 11777 lines...] [junit4] Suite: org.apache.solr.cloud.ShardSplitTest [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/build/solr-core/test/J1/temp/solr.cloud.ShardSplitTest_2D27D509B36ECE00-001/init-core-data-001 [junit4] 2> 266515 WARN (SUITE-ShardSplitTest-seed#[2D27D509B36ECE00]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=61 numCloses=61 [junit4] 2> 266516 INFO (SUITE-ShardSplitTest-seed#[2D27D509B36ECE00]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 266517 INFO (SUITE-ShardSplitTest-seed#[2D27D509B36ECE00]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776) [junit4] 2> 266517 INFO (SUITE-ShardSplitTest-seed#[2D27D509B36ECE00]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 266530 INFO (SUITE-ShardSplitTest-seed#[2D27D509B36ECE00]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /j/n [junit4] 2> 266550 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 266550 INFO (Thread-139) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 266550 INFO (Thread-139) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 266552 ERROR (Thread-139) [] o.a.z.s.ZooKeeperServer ZKShutdownHandler is not registered, so ZooKeeper server won't take any action on ERROR or SHUTDOWN server state changes [junit4] 2> 266659 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.ZkTestServer start zk server on port:34914 [junit4] 2> 266883 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 266916 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/schema15.xml to /configs/conf1/schema.xml [junit4] 2> 266917 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 266918 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 266919 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/protwords.txt to /configs/conf1/protwords.txt [junit4] 2> 266952 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/currency.xml to /configs/conf1/currency.xml [junit4] 2> 266954 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/enumsConfig.xml to /configs/conf1/enumsConfig.xml [junit4] 2> 266955 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/open-exchange-rates.json to /configs/conf1/open-exchange-rates.json [junit4] 2> 266956 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-7.x/solr/core/src/test-files/solr/collection1/conf/mapping-ISOLatin1Accent.txt to /configs/conf1/mapping-ISOLatin1Accent.txt [junit4] 2> 266970 INFO (TEST-ShardSplitTest.testSplitShardWithRule-seed#[2D27D509B36ECE00]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/je
[jira] [Commented] (LUCENE-8038) Decouple payload decoding from Similarity
[ https://issues.apache.org/jira/browse/LUCENE-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240220#comment-16240220 ] Robert Muir commented on LUCENE-8038: - I want to urge caution about adding more flexibility. There is a huge benefit in restricting what this can do: it can allow us to potentially implement stuff like LUCENE-4100 and LUCENE-7993 for span queries. But if we make them "ultra-flexible crap" with no rules or constraints then these queries will just remain slow compared to e.g. phrase queries. Can we just fix the API to be better on this issue without messing around with any scoring of null or flexibility or anything else? > Decouple payload decoding from Similarity > - > > Key: LUCENE-8038 > URL: https://issues.apache.org/jira/browse/LUCENE-8038 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward > Attachments: LUCENE-8038-master.patch, LUCENE-8038.patch > > > PayloadScoreQuery is the only place that currently uses > SimScorer.computePayloadFactor(), and as discussed on LUCENE-8014, this seems > like the wrong place for it. We should instead add a PayloadDecoder > abstraction that is passed to PayloadScoreQuery. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 74 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/74/ No tests ran. Build Log: [...truncated 4697 lines...] ERROR: command execution failed. common.test: -check-git-state: ERROR: Step ‘Archive the artifacts’ failed: no workspace for Lucene-Solr-NightlyTests-7.x #74 -git-cleanroot: -copy-git-state: ERROR: Step ‘Publish JUnit test result report’ failed: no workspace for Lucene-Solr-NightlyTests-7.x #74 git-autoclean: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml resolve: common.init: compile-lucene-core: -check-git-state: -git-cleanroot: -copy-git-state: git-autoclean: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml resolve: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: init: test: -clover.disable: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml -clover.load: -clover.classpath: -clover.setup: clover: -check-git-state: -git-cleanroot: -copy-git-state: git-autoclean: resolve: common.init: compile-lucene-core: init: compile-test: check-analyzers-common-uptodate: jar-analyzers-common: -check-git-state: -git-cleanroot: -copy-git-state: git-autoclean: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/java [javac] Compiling 8 source files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/java [javac] Creating empty /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/java/org/apache/lucene/analysis/uk/package-info.class [javac] Creating empty /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/java/org/apache/lucene/analysis/morfologik/package-info.class [copy] Copying 3 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/java compile-core: compile-test-framework: -check-git-state: -git-cleanroot: -copy-git-state: git-autoclean: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: -check-git-state: -git-cleanroot: -copy-git-state: git-autoclean: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/top-level-ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: common.compile-test: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/test [javac] Compiling 3 source files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/classes/test install-junit4-taskdef: validate: resolve-groovy: -init-totals: -test: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/test [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/checkout/lucene/build/analysis/morfologik/test/temp [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.x/chec
[jira] [Comment Edited] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls
[
https://issues.apache.org/jira/browse/SOLR-11551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240187#comment-16240187
]
Jason Gerlowski edited comment on SOLR-11551 at 11/6/17 12:06 PM:
--
I also noticed that anytime a core-API takes in a "core" parameter, but that
core doesn't exist, we throw a SolrException with a 400 status-code. This
might be better represented as a 404 (NOT FOUND). I don't have a strong
opinion whether we implement that, but it does fit things a little maybe.
I left the behavior as-is in the initial patch, since it wasn't in the
interface you laid out in the issue description. Just wanted to mention it in
case anyone liked the idea...
was (Author: gerlowskija):
I also noticed that anytime a core-API takes in a "core" parameter, but that
core doesn't exist, we throw a SolrException with a 400 status-code. This
might be better represented as a 404 (NOT FOUND). I don't have a strong
opinion whether we implement that, but it does fit things a little maybe.
> Standardize response codes and success/failure determination for core-admin
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
> Attachments: SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core
> admin api's first.
> If we are relying on response codes I think we should make the following
> change and fix all the APIs
> {code}
> interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
> }
> {code}
> To
> {code}
> interface CoreAdminOp {
> /**
> *
> * @param it request/response object
> *
> * If the request is invalid throw a SolrException with
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
> * If the execution of the command fails throw a SolrException with
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
> * Add a "error-message" key to the response object with the exception (
> this part should be done at the caller of this method so that each operation
> doesn't need to do the same thing )
> */
> void execute(CallInfo it);
> }
> {code}
> cc [~gerlowskija]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11551) Standardize response codes and success/failure determination for core-admin api calls
[
https://issues.apache.org/jira/browse/SOLR-11551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240187#comment-16240187
]
Jason Gerlowski commented on SOLR-11551:
I also noticed that anytime a core-API takes in a "core" parameter, but that
core doesn't exist, we throw a SolrException with a 400 status-code. This
might be better represented as a 404 (NOT FOUND). I don't have a strong
opinion whether we implement that, but it does fit things a little maybe.
> Standardize response codes and success/failure determination for core-admin
> api calls
> -
>
> Key: SOLR-11551
> URL: https://issues.apache.org/jira/browse/SOLR-11551
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
> Attachments: SOLR-11551.patch
>
>
> If we were to tackle SOLR-11526 I think we need to start fixing the core
> admin api's first.
> If we are relying on response codes I think we should make the following
> change and fix all the APIs
> {code}
> interface CoreAdminOp {
> void execute(CallInfo it) throws Exception;
> }
> {code}
> To
> {code}
> interface CoreAdminOp {
> /**
> *
> * @param it request/response object
> *
> * If the request is invalid throw a SolrException with
> SolrException.ErrorCode.BAD_REQUEST ( 400 )
> * If the execution of the command fails throw a SolrException with
> SolrException.ErrorCode.SERVER_ERROR ( 500 )
> * Add a "error-message" key to the response object with the exception (
> this part should be done at the caller of this method so that each operation
> doesn't need to do the same thing )
> */
> void execute(CallInfo it);
> }
> {code}
> cc [~gerlowskija]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
