[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1133 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1133/ No tests ran. Build Log: [...truncated 23269 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2430 links (1982 relative) to 3172 anchors in 246 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-8.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: 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-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail:
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628265#comment-16628265 ] Noble Paul commented on SOLR-12798: --- bq. here are two problems with using UpdateRequest. First, as you point out, the entire document has to hit memory. this no longer is the case. The reason why I changed the interface is to ensure that we don't write everything to memory .You can provide a request that creates documents on the fly and the memory consumption is trivial. bq.Yes, of course it can, but the way SolrJ is constructed it makes no use of this. In fact, it currently doesn't use multipart post at all, unless I override much functionality in order to force it to do so. I have fixed this problem in the current SolrJ > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5004) Allow a shard to be split into 'n' sub-shards
[ https://issues.apache.org/jira/browse/SOLR-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5004: --- Attachment: SOLR-5004.01.patch > Allow a shard to be split into 'n' sub-shards > - > > Key: SOLR-5004 > URL: https://issues.apache.org/jira/browse/SOLR-5004 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.3, 4.3.1 >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Major > Attachments: SOLR-5004.01.patch, SOLR-5004.patch, SOLR-5004.patch > > > As of now, a SPLITSHARD call is hardcoded to create 2 sub-shards from the > parent one. Accept a parameter to split into n sub-shards. > Default it to 2 and perhaps also have an upper bound to it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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 # 2076 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/2076/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir
Error Message:
Captured an uncaught exception in thread: Thread[id=29945,
name=cdcr-replicator-10753-thread-1, state=RUNNABLE,
group=TGRP-CdcrBidirectionalTest]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=29945, name=cdcr-replicator-10753-thread-1,
state=RUNNABLE, group=TGRP-CdcrBidirectionalTest]
at
__randomizedtesting.SeedInfo.seed([68EC0CA6EBAB91B4:2D37FC44F385DDF6]:0)
Caused by: java.lang.AssertionError: 1612641849563938816 != 1612641849436012544
at __randomizedtesting.SeedInfo.seed([68EC0CA6EBAB91B4]:0)
at
org.apache.solr.update.CdcrUpdateLog$CdcrLogReader.forwardSeek(CdcrUpdateLog.java:611)
at org.apache.solr.handler.CdcrReplicator.run(CdcrReplicator.java:125)
at
org.apache.solr.handler.CdcrReplicatorScheduler.lambda$null$0(CdcrReplicatorScheduler.java:81)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Build Log:
[...truncated 14298 lines...]
[junit4] Suite: org.apache.solr.cloud.cdcr.CdcrBidirectionalTest
[junit4] 2> 3820347 INFO
(SUITE-CdcrBidirectionalTest-seed#[68EC0CA6EBAB91B4]-worker) []
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
[junit4] 2> Creating dataDir:
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.cdcr.CdcrBidirectionalTest_68EC0CA6EBAB91B4-001/init-core-data-001
[junit4] 2> 3820348 INFO
(SUITE-CdcrBidirectionalTest-seed#[68EC0CA6EBAB91B4]-worker) []
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true)
w/NUMERIC_DOCVALUES_SYSPROP=false
[junit4] 2> 3820349 INFO
(SUITE-CdcrBidirectionalTest-seed#[68EC0CA6EBAB91B4]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via:
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
[junit4] 2> 3820354 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[68EC0CA6EBAB91B4]) []
o.a.s.SolrTestCaseJ4 ###Starting testBiDir
[junit4] 2> 3820355 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[68EC0CA6EBAB91B4]) []
o.a.s.c.MiniSolrCloudCluster Starting cluster of 1 servers in
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J1/temp/solr.cloud.cdcr.CdcrBidirectionalTest_68EC0CA6EBAB91B4-001/cdcr-cluster2-001
[junit4] 2> 3820355 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[68EC0CA6EBAB91B4]) []
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
[junit4] 2> 3820355 INFO (Thread-5374) [] o.a.s.c.ZkTestServer client
port:0.0.0.0/0.0.0.0:0
[junit4] 2> 3820355 INFO (Thread-5374) [] o.a.s.c.ZkTestServer
Starting server
[junit4] 2> 3820360 ERROR (Thread-5374) [] 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> 3820455 INFO
(TEST-CdcrBidirectionalTest.testBiDir-seed#[68EC0CA6EBAB91B4]) []
o.a.s.c.ZkTestServer start zk server on port:39916
[junit4] 2> 3820460 INFO (zkConnectionManagerCallback-8412-thread-1) [
] o.a.s.c.c.ConnectionManager zkClient has connected
[junit4] 2> 3820471 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.Server jetty-9.4.11.v20180605; built: 2018-06-05T18:24:03.829Z; git:
d5fc0523cfa96bfebfbda19606cad384d772f04c; jvm 1.8.0_172-b11
[junit4] 2> 3820472 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.session DefaultSessionIdManager workerName=node0
[junit4] 2> 3820472 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.session No SessionScavenger set, using defaults
[junit4] 2> 3820472 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.session node0 Scavenging every 66ms
[junit4] 2> 3820472 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@47616c0{/solr,null,AVAILABLE}
[junit4] 2> 3820473 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.AbstractConnector Started
ServerConnector@312f13c9{HTTP/1.1,[http/1.1]}{127.0.0.1:60947}
[junit4] 2> 3820473 INFO (jetty-launcher-8409-thread-1) []
o.e.j.s.Server Started @3823110ms
[junit4] 2> 3820473 INFO (jetty-launcher-8409-thread-1) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=60947}
[junit4] 2> 3820473 ERROR
[JENKINS-EA] Lucene-Solr-BadApples-master-Linux (64bit/jdk-11-ea+28) - Build # 98 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/98/ Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 62 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 1) Thread[id=1512, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeBinaryJettyTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11/java.lang.Thread.run(Thread.java:834) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest: 1) Thread[id=1512, name=Connection evictor, state=TIMED_WAITING, group=TGRP-LargeVolumeBinaryJettyTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11/java.lang.Thread.run(Thread.java:834) at __randomizedtesting.SeedInfo.seed([B9F5D042CF3C66AA]:0) FAILED: junit.framework.TestSuite.org.apache.solr.client.solrj.io.stream.StreamDecoratorTest Error Message: 6 threads leaked from SUITE scope at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest: 1) Thread[id=1820, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11/java.lang.Thread.run(Thread.java:834)2) Thread[id=1821, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11/java.lang.Thread.run(Thread.java:834)3) Thread[id=1816, name=TEST-StreamDecoratorTest.testParallelExecutorStream-seed#[B9F5D042CF3C66AA]-EventThread, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:502)4) Thread[id=1814, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.http.impl.client.IdleConnectionEvictor$1.run(IdleConnectionEvictor.java:66) at java.base@11/java.lang.Thread.run(Thread.java:834)5) Thread[id=1817, name=zkConnectionManagerCallback-855-thread-1, state=WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at java.base@11/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054) at java.base@11/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114) at java.base@11/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base@11/java.lang.Thread.run(Thread.java:834)6) Thread[id=1815, name=TEST-StreamDecoratorTest.testParallelExecutorStream-seed#[B9F5D042CF3C66AA]-SendThread(127.0.0.1:43095), state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/java.lang.Thread.sleep(Native Method) at app//org.apache.zookeeper.client.StaticHostProvider.next(StaticHostProvider.java:105) at app//org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1000) at app//org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1063) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 6 threads leaked from SUITE scope at org.apache.solr.client.solrj.io.stream.StreamDecoratorTest: 1) Thread[id=1820, name=Connection evictor, state=TIMED_WAITING, group=TGRP-StreamDecoratorTest] at java.base@11/java.lang.Thread.sleep(Native Method) at
[jira] [Updated] (SOLR-12805) Store previous term (generation) of replica when start recovery process
[
https://issues.apache.org/jira/browse/SOLR-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat updated SOLR-12805:
Fix Version/s: master (8.0)
> Store previous term (generation) of replica when start recovery process
> ---
>
> Key: SOLR-12805
> URL: https://issues.apache.org/jira/browse/SOLR-12805
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (8.0)
>
>
> Right now the current implementation of ZkShardTerms.startRecovering(core2) is
> from \{"core1" : 4, "core2" : 2} to \{"core1" : 4, "core2" : 4,
> "core2_recovering" : 4}. If we change the behavior a little bit to \{"core1"
> : 4, "core2" : 4, "core_recovering" : 2}. We will have more information about
> the current generation of core2's index which is a very useful information
> for leader election.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12805) Store previous term (generation) of replica when start recovery process
[
https://issues.apache.org/jira/browse/SOLR-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cao Manh Dat resolved SOLR-12805.
-
Resolution: Fixed
> Store previous term (generation) of replica when start recovery process
> ---
>
> Key: SOLR-12805
> URL: https://issues.apache.org/jira/browse/SOLR-12805
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Right now the current implementation of ZkShardTerms.startRecovering(core2) is
> from \{"core1" : 4, "core2" : 2} to \{"core1" : 4, "core2" : 4,
> "core2_recovering" : 4}. If we change the behavior a little bit to \{"core1"
> : 4, "core2" : 4, "core_recovering" : 2}. We will have more information about
> the current generation of core2's index which is a very useful information
> for leader election.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12805) Store previous term (generation) of replica when start recovery process
[
https://issues.apache.org/jira/browse/SOLR-12805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628213#comment-16628213
]
ASF subversion and git services commented on SOLR-12805:
Commit 667b8299e69755abfef89b3beb44cacdd292d479 in lucene-solr's branch
refs/heads/master from [~caomanhdat]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=667b829 ]
SOLR-12805: Store previous term (generation) of replica when start recovery
process
> Store previous term (generation) of replica when start recovery process
> ---
>
> Key: SOLR-12805
> URL: https://issues.apache.org/jira/browse/SOLR-12805
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Cao Manh Dat
>Assignee: Cao Manh Dat
>Priority: Major
>
> Right now the current implementation of ZkShardTerms.startRecovering(core2) is
> from \{"core1" : 4, "core2" : 2} to \{"core1" : 4, "core2" : 4,
> "core2_recovering" : 4}. If we change the behavior a little bit to \{"core1"
> : 4, "core2" : 4, "core_recovering" : 2}. We will have more information about
> the current generation of core2's index which is a very useful information
> for leader election.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12805) Store previous term (generation) of replica when start recovery process
Cao Manh Dat created SOLR-12805:
---
Summary: Store previous term (generation) of replica when start
recovery process
Key: SOLR-12805
URL: https://issues.apache.org/jira/browse/SOLR-12805
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Cao Manh Dat
Assignee: Cao Manh Dat
Right now the current implementation of ZkShardTerms.startRecovering(core2) is
from \{"core1" : 4, "core2" : 2} to \{"core1" : 4, "core2" : 4,
"core2_recovering" : 4}. If we change the behavior a little bit to \{"core1" :
4, "core2" : 4, "core_recovering" : 2}. We will have more information about the
current generation of core2's index which is a very useful information for
leader election.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5163) edismax should throw exception when qf refers to nonexistent field
[
https://issues.apache.org/jira/browse/SOLR-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628186#comment-16628186
]
Lucene/Solr QA commented on SOLR-5163:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
24s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 15s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 55m 53s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 60m 39s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.MoveReplicaHDFSTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-5163 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12941205/SOLR-5163.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.4.0-130-generic #156~14.04.1-Ubuntu SMP Thu
Jun 14 13:51:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 5816766 |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on July 24 2018 |
| Default Java | 1.8.0_172 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/189/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/189/testReport/ |
| modules | C: solr solr/core U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/189/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> edismax should throw exception when qf refers to nonexistent field
> --
>
> Key: SOLR-5163
> URL: https://issues.apache.org/jira/browse/SOLR-5163
> Project: Solr
> Issue Type: Bug
> Components: query parsers, search
>Affects Versions: 4.10.4
>Reporter: Steven Bower
>Assignee: David Smiley
>Priority: Major
> Labels: newdev
> Attachments: SOLR-5163.patch, SOLR-5163.patch, SOLR-5163.patch
>
>
> query:
> q=foo AND bar
> qf=field1
> qf=field2
> defType=edismax
> Where field1 exists and field2 doesn't..
> will treat the AND as a term vs and operator
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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.4) - Build # 22924 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22924/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeAdded
Error Message:
ComputePlanAction should have computed exactly 1 operation, but was: [{
"class":"org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica",
"method":"GET", "params.action":"MOVEREPLICA",
"params.collection":"testNodeAdded",
"params.targetNode":"127.0.0.1:10004_solr", "params.inPlaceMove":"true",
"params.replica":"core_node1"}, {
"class":"org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica",
"method":"GET", "params.action":"MOVEREPLICA",
"params.collection":"testNodeAdded",
"params.targetNode":"127.0.0.1:10004_solr", "params.inPlaceMove":"true",
"params.replica":"core_node2"}] expected:<1> but was:<2>
Stack Trace:
java.lang.AssertionError: ComputePlanAction should have computed exactly 1
operation, but was: [{
"class":"org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica",
"method":"GET",
"params.action":"MOVEREPLICA",
"params.collection":"testNodeAdded",
"params.targetNode":"127.0.0.1:10004_solr",
"params.inPlaceMove":"true",
"params.replica":"core_node1"}, {
"class":"org.apache.solr.client.solrj.request.CollectionAdminRequest$MoveReplica",
"method":"GET",
"params.action":"MOVEREPLICA",
"params.collection":"testNodeAdded",
"params.targetNode":"127.0.0.1:10004_solr",
"params.inPlaceMove":"true",
"params.replica":"core_node2"}] expected:<1> but was:<2>
at
__randomizedtesting.SeedInfo.seed([506E8CDEC78E05C7:35ADDAA9652DADC4]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at
org.apache.solr.cloud.autoscaling.sim.TestSimComputePlanAction.testNodeAdded(TestSimComputePlanAction.java:314)
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:1742)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985)
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:944)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891)
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
[jira] [Commented] (SOLR-11985) Allow percentage in replica attribute in policy
[
https://issues.apache.org/jira/browse/SOLR-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628159#comment-16628159
]
Steve Rowe commented on SOLR-11985:
---
[~noble.paul], can this issue be resolved? It has a 7.5 CHANGES entry.
> Allow percentage in replica attribute in policy
> ---
>
> Key: SOLR-11985
> URL: https://issues.apache.org/jira/browse/SOLR-11985
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: SOLR-11985.patch, SOLR-11985.patch
>
>
> Today we can only specify an absolute number in the 'replica' attribute in
> the policy rules. It'd be useful to write a percentage value to make certain
> use-cases easier. For example:
> {code:java}
> // Keep a third of the the replicas of each shard in east region
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> // Keep two thirds of the the replicas of each shard in west region
> {"replica" : "<67%", "shard" : "#EACH", "sysprop:region": "west"}
> {code}
> Today the above must be represented by different rules for each collection if
> they have different replication factors. Also if the replication factor
> changes later, the absolute value has to be changed in tandem. So expressing
> a percentage removes both of these restrictions.
> This feature means that the value of the attribute {{"replica"}} is only
> available just in time. We call such values {{"computed values"}} . The
> computed value for this attribute depends on other attributes as well.
> Take the following 2 rules
> {code:java}
> //example 1
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> //example 2
> {"replica" : "<34%", "sysprop:region": "east"}
> {code}
> assume we have collection {{"A"}} with 2 shards and {{replicationFactor=3}}
> *example 1* would mean that the value of replica is computed as
> {{3 * 34 / 100 = 1.02}}
> Which means *_for each shard_* keep less than 1.02 replica in east
> availability zone
>
> *example 2* would mean that the value of replica is computed as
> {{3 * 2 * 34 / 100 = 2.04}}
>
> which means _*for each collection*_ keep less than 2.04 replicas on east
> availability zone
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-11985) Allow percentage in replica attribute in policy
[
https://issues.apache.org/jira/browse/SOLR-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-11985:
--
Fix Version/s: (was: 7.6)
7.5
> Allow percentage in replica attribute in policy
> ---
>
> Key: SOLR-11985
> URL: https://issues.apache.org/jira/browse/SOLR-11985
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling, SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Noble Paul
>Priority: Major
> Fix For: 7.5, master (8.0)
>
> Attachments: SOLR-11985.patch, SOLR-11985.patch
>
>
> Today we can only specify an absolute number in the 'replica' attribute in
> the policy rules. It'd be useful to write a percentage value to make certain
> use-cases easier. For example:
> {code:java}
> // Keep a third of the the replicas of each shard in east region
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> // Keep two thirds of the the replicas of each shard in west region
> {"replica" : "<67%", "shard" : "#EACH", "sysprop:region": "west"}
> {code}
> Today the above must be represented by different rules for each collection if
> they have different replication factors. Also if the replication factor
> changes later, the absolute value has to be changed in tandem. So expressing
> a percentage removes both of these restrictions.
> This feature means that the value of the attribute {{"replica"}} is only
> available just in time. We call such values {{"computed values"}} . The
> computed value for this attribute depends on other attributes as well.
> Take the following 2 rules
> {code:java}
> //example 1
> {"replica" : "<34%", "shard" : "#EACH", "sysprop:region": "east"}
> //example 2
> {"replica" : "<34%", "sysprop:region": "east"}
> {code}
> assume we have collection {{"A"}} with 2 shards and {{replicationFactor=3}}
> *example 1* would mean that the value of replica is computed as
> {{3 * 34 / 100 = 1.02}}
> Which means *_for each shard_* keep less than 1.02 replica in east
> availability zone
>
> *example 2* would mean that the value of replica is computed as
> {{3 * 2 * 34 / 100 = 2.04}}
>
> which means _*for each collection*_ keep less than 2.04 replicas on east
> availability zone
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628146#comment-16628146
]
Anshum Gupta commented on SOLR-12767:
-
I haven't looked at the patch but I like the idea. min_rf doesn't really do
anything as far as Solr is concerned other than tracking and returning the
value, plus avoiding nodes from getting into LIR - completely relying on users
doing the right thing i.e. retrying. +1 to the idea, and I'll take a look at
the patch but tomorrow.
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1531 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1531/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/161/consoleText [repro] Revision: 9bc4b8d4fe3bb220ca3a27fb252b703b39443a3c [repro] Repro line: ant test -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test -Dtests.seed=8A784DD479B0CBFE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-TW -Dtests.timezone=Africa/Bamako -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=MoveReplicaHDFSTest -Dtests.method=testFailedMove -Dtests.seed=8A784DD479B0CBFE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=Africa/Ndjamena -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=CloudSolrClientTest -Dtests.method=testNonRetryableRequests -Dtests.seed=DA0E611AF76BF179 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ja -Dtests.timezone=America/Creston -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 58167666c393c261982ecd7b3d17201a76afda17 [repro] git fetch [repro] git checkout 9bc4b8d4fe3bb220ca3a27fb252b703b39443a3c [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] MoveReplicaHDFSTest [repro] TestInPlaceUpdatesDistrib [repro]solr/solrj [repro] CloudSolrClientTest [repro] ant compile-test [...truncated 3424 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.MoveReplicaHDFSTest|*.TestInPlaceUpdatesDistrib" -Dtests.showOutput=onerror -Dtests.seed=8A784DD479B0CBFE -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ar-BH -Dtests.timezone=Africa/Ndjamena -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 27368 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 454 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.CloudSolrClientTest" -Dtests.showOutput=onerror -Dtests.seed=DA0E611AF76BF179 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=ja -Dtests.timezone=America/Creston -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 143 lines...] [repro] Failures: [repro] 0/5 failed: org.apache.solr.client.solrj.impl.CloudSolrClientTest [repro] 0/5 failed: org.apache.solr.update.TestInPlaceUpdatesDistrib [repro] 2/5 failed: org.apache.solr.cloud.MoveReplicaHDFSTest [repro] git checkout 58167666c393c261982ecd7b3d17201a76afda17 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - 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 # 2822 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2822/ 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage Error Message: SolrCore.getOpenCount()==2 Stack Trace: java.lang.RuntimeException: SolrCore.getOpenCount()==2 at __randomizedtesting.SeedInfo.seed([CE69CED49B2E6122]:0) at org.apache.solr.util.TestHarness.close(TestHarness.java:380) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:802) at org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:898) 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.rest.TestManagedResourceStorage Error Message: 4 threads leaked from SUITE scope at org.apache.solr.rest.TestManagedResourceStorage: 1) Thread[id=10054, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, group=TGRP-TestManagedResourceStorage] at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269) at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93) at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:196) at java.lang.Thread.run(Thread.java:748)2) Thread[id=10053, name=Thread-2224, state=WAITING, group=TGRP-TestManagedResourceStorage] at java.lang.Object.wait(Native Method) at java.lang.Thread.join(Thread.java:1252) at java.lang.Thread.join(Thread.java:1326) at org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313) at org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:313) at org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:496) 3) Thread[id=10055, name=SessionTracker, state=TIMED_WAITING, group=TGRP-TestManagedResourceStorage] at java.lang.Object.wait(Native Method) at org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147) 4) Thread[id=10057, name=ProcessThread(sid:0 cport:34593):, state=WAITING, group=TGRP-TestManagedResourceStorage] 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
[jira] [Created] (SOLR-12804) Remove static modifier from Overseer queue access.
Mark Miller created SOLR-12804: -- Summary: Remove static modifier from Overseer queue access. Key: SOLR-12804 URL: https://issues.apache.org/jira/browse/SOLR-12804 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Reporter: Mark Miller Assignee: Mark Miller This is kind of a lazy anti-pattern in general, but also does not go well with mocking. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12652) SolrMetricManager.overridableRegistryName should be removed; it doesn't work
[
https://issues.apache.org/jira/browse/SOLR-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628057#comment-16628057
]
Peter Somogyi commented on SOLR-12652:
--
The test failure was related to my change. Fixed it in second patchset.
> SolrMetricManager.overridableRegistryName should be removed; it doesn't work
>
>
> Key: SOLR-12652
> URL: https://issues.apache.org/jira/browse/SOLR-12652
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.1
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-12652.patch, SOLR-12652.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{SolrMetricManager.overridableRegistryName()}} method is a great idea
> but unfortunately in practice I've found it doesn't really work; it seems
> fundamentally flawed. +I wish it could work+. The main issue I think is
> that the callers of SMM.registerGauge/registerMetric assumes it can place a
> gauge/metric and have it be the only once there (force==true). But it won't
> be if it's shared.
> Another problem is in at least one of the reporters --
> {{JmxMetricsReporter.JmxListener#registerMBean}} will get in a race condition
> to remove an already-registered MBean but in the process of removing it,
> it'll already get removed concurrently by some other core working on the same
> name. This results in {{javax.management.InstanceNotFoundException}} logged
> as a warning; nothing serious. But I suspect conceptually there is a problem
> since which MBean should "win"? Shrug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12652) SolrMetricManager.overridableRegistryName should be removed; it doesn't work
[
https://issues.apache.org/jira/browse/SOLR-12652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated SOLR-12652:
-
Attachment: SOLR-12652.patch
> SolrMetricManager.overridableRegistryName should be removed; it doesn't work
>
>
> Key: SOLR-12652
> URL: https://issues.apache.org/jira/browse/SOLR-12652
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
>Affects Versions: 7.1
>Reporter: David Smiley
>Priority: Minor
> Attachments: SOLR-12652.patch, SOLR-12652.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{SolrMetricManager.overridableRegistryName()}} method is a great idea
> but unfortunately in practice I've found it doesn't really work; it seems
> fundamentally flawed. +I wish it could work+. The main issue I think is
> that the callers of SMM.registerGauge/registerMetric assumes it can place a
> gauge/metric and have it be the only once there (force==true). But it won't
> be if it's shared.
> Another problem is in at least one of the reporters --
> {{JmxMetricsReporter.JmxListener#registerMBean}} will get in a race condition
> to remove an already-registered MBean but in the process of removing it,
> it'll already get removed concurrently by some other core working on the same
> name. This results in {{javax.management.InstanceNotFoundException}} logged
> as a warning; nothing serious. But I suspect conceptually there is a problem
> since which MBean should "win"? Shrug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-12767:
-
Attachment: SOLR-12767.patch
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628055#comment-16628055
]
Mark Miller commented on SOLR-12767:
I had a vision for min_rf and it seems to me the current implementation chased
that vision without the right implementation. It's current impl never made
sense to me event without the broken recovery semantics. +1 to this change.
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16628051#comment-16628051
]
Tomás Fernández Löbbe commented on SOLR-12767:
--
The patch attached doesn't add much of a cleanup, changes are minor really.
I'll check and see if further improvements can be made without a huge refactor,
otherwise that will deserve it's own Jira. One thing I'm not sure I understand
is the reason behind {{getShardReplicationFactor(...)}}, It seems to address
the case of {{CloudSolrClient}} breaking update batches into multiple requests
(per shard), however, that response is being condensed in
{{CloudSolrClient.condenseResponse(...)}}, I'm not sure if this code was there
before or if there are edge cases that this code is supposed to handle.
In the patch, whenever the "min_rf" is explicitly set by the user, I'm
including it in the sub requests. This is only to support rolling upgrades and
can be removed in the future. If the user is not currently using "min_rf", and
they do a rolling upgrade, during the time of the upgrade they could receive a
MAX_INT as "achieved RF", but I think that's fine, since they won't be
consuming the value anyway, and it should be for a short period of time. I
don't think it's worth to add more code to handle this situation better, but
I'm open to suggestions.
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-12767:
-
Attachment: SOLR-12767.patch
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch, SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe reassigned SOLR-12767:
Assignee: Tomás Fernández Löbbe
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Assignee: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
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_172) - Build # 22923 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/22923/ Java: 64bit/jdk1.8.0_172 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.MoveReplicaHDFSTest.testFailedMove Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:36455/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:44853/solr/MoveReplicaHDFSTest_failed_coll_true] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:36455/solr/MoveReplicaHDFSTest_failed_coll_true, http://127.0.0.1:44853/solr/MoveReplicaHDFSTest_failed_coll_true] at __randomizedtesting.SeedInfo.seed([9B062B67E2124E55:31CBF89555C19B85]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:462) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:994) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942) at org.apache.solr.cloud.MoveReplicaTest.testFailedMove(MoveReplicaTest.java:301) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Updated] (SOLR-12767) Deprecate min_rf parameter and always include the achieved rf in the response
[
https://issues.apache.org/jira/browse/SOLR-12767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomás Fernández Löbbe updated SOLR-12767:
-
Attachment: SOLR-12767.patch
> Deprecate min_rf parameter and always include the achieved rf in the response
> -
>
> Key: SOLR-12767
> URL: https://issues.apache.org/jira/browse/SOLR-12767
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomás Fernández Löbbe
>Priority: Major
> Attachments: SOLR-12767.patch
>
>
> Currently the {{min_rf}} parameter does two things.
> 1. It tells Solr that the user wants to keep track of the achieved
> replication factor
> 2. (undocumented AFAICT) It prevents Solr from putting replicas in recovery
> if the achieved replication factor is lower than the {{min_rf}} specified
> #2 is intentional and I believe the reason behind it is to prevent replicas
> to go into recovery in cases of short hiccups (since the assumption is that
> the user is going to retry the request anyway). This is dangerous because if
> the user doesn’t retry (or retries a number of times but keeps failing) the
> replicas will be permanently inconsistent. Also, since we now retry updates
> from leaders to replicas, this behavior has less value, since short temporary
> blips should be recovered by those retries anyway.
> I think we should remove the behavior described in #2, #1 is still valuable,
> but there isn’t much point of making the parameter an integer, the user is
> just telling Solr that they want the achieved replication factor, so it could
> be a boolean, but I’m thinking we probably don’t even want to expose the
> parameter, and just always keep track of it, and include it in the response.
> It’s not costly to calculate, so why keep two separate code paths?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8515) Jenkins patch validation: upgrade Yetus to 0.8.0
Steve Rowe created LUCENE-8515:
--
Summary: Jenkins patch validation: upgrade Yetus to 0.8.0
Key: LUCENE-8515
URL: https://issues.apache.org/jira/browse/LUCENE-8515
Project: Lucene - Core
Issue Type: Task
Reporter: Steve Rowe
Assignee: Steve Rowe
Yetus 0.8.0 has been released. We should upgrade the scripts under
{{dev-tools/scripts/test-patch/}} to use it. Currently they use Yetus 0.7.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8479) QueryBuilder#analyzeGraphPhrase should respect max boolean clause
[
https://issues.apache.org/jira/browse/LUCENE-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627917#comment-16627917
]
Lucene/Solr QA commented on LUCENE-8479:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 1m 35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 30m
18s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 51s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-8479 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12941178/LUCENE-8479.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 5816766 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | 1.8.0_172 |
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/98/testReport/ |
| modules | C: lucene/core U: lucene/core |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/98/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> QueryBuilder#analyzeGraphPhrase should respect max boolean clause
> -
>
> Key: LUCENE-8479
> URL: https://issues.apache.org/jira/browse/LUCENE-8479
> Project: Lucene - Core
> Issue Type: Test
>Reporter: Jim Ferenczi
>Priority: Major
> Attachments: LUCENE-8479.patch, LUCENE-8479.patch
>
>
> Currently there is no limit in the number of span queries that can be mixed
> by QueryBuilder#analyzeGraphPhrase even if the input graph contains thousands
> of paths. We should apply the same limit than analyzeGraphBoolean which
> throws TooManyClauses exception when the number of expanded paths is greater
> than BooleanQuery#MAX_CLAUSE_COUNT.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+28) - Build # 7535 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7535/ Java: 64bit/jdk-11-ea+28 -XX:-UseCompressedOops -XX:+UseSerialGC 10 tests failed. FAILED: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple Error Message: Could not find collection : testSimple1 Stack Trace: org.apache.solr.common.SolrException: Could not find collection : testSimple1 at __randomizedtesting.SeedInfo.seed([F22B7D46D0019078:CA9859B8F7F244A9]:0) at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:118) at org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.getReplacedSharedFsReplicas(AutoAddReplicasIntegrationTest.java:173) at org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple(AutoAddReplicasIntegrationTest.java:90) 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:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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:834) FAILED: org.apache.solr.cloud.autoscaling.AutoAddReplicasIntegrationTest.testSimple Error Message: Could
[JENKINS] Lucene-Solr-repro - Build # 1530 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1530/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1132/consoleText [repro] Revision: 9bc4b8d4fe3bb220ca3a27fb252b703b39443a3c [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=TestSimTriggerIntegration -Dtests.method=testEventQueue -Dtests.seed=9E974CE50EAC657A -Dtests.multiplier=2 -Dtests.locale=de-CH -Dtests.timezone=Europe/Berlin -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 58167666c393c261982ecd7b3d17201a76afda17 [repro] git fetch [repro] git checkout 9bc4b8d4fe3bb220ca3a27fb252b703b39443a3c [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestSimTriggerIntegration [repro] ant compile-test [...truncated 3424 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestSimTriggerIntegration" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=9E974CE50EAC657A -Dtests.multiplier=2 -Dtests.locale=de-CH -Dtests.timezone=Europe/Berlin -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 9362 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.sim.TestSimTriggerIntegration [repro] git checkout 58167666c393c261982ecd7b3d17201a76afda17 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro - Build # 1529 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/1529/ [...truncated 30 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/324/consoleText [repro] Revision: eeaf6fc7d10a66ad1687a901882a89d987443c24 [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=TestSimLargeCluster -Dtests.method=testNodeLost -Dtests.seed=219A3BD0DF46933F -Dtests.multiplier=2 -Dtests.locale=hi-IN -Dtests.timezone=America/Kentucky/Louisville -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=TestPullReplicaErrorHandling -Dtests.method=testCantConnectToPullReplica -Dtests.seed=219A3BD0DF46933F -Dtests.multiplier=2 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Novosibirsk -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 58167666c393c261982ecd7b3d17201a76afda17 [repro] git fetch [repro] git checkout eeaf6fc7d10a66ad1687a901882a89d987443c24 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] TestPullReplicaErrorHandling [repro] TestSimLargeCluster [repro] ant compile-test [...truncated 3437 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestPullReplicaErrorHandling|*.TestSimLargeCluster" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=219A3BD0DF46933F -Dtests.multiplier=2 -Dtests.locale=sr-Latn-BA -Dtests.timezone=Asia/Novosibirsk -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 588299 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.TestPullReplicaErrorHandling [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster [repro] git checkout 58167666c393c261982ecd7b3d17201a76afda17 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - 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 # 327 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/327/ 2 tests failed. FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E991720725BE732A:61C54DDD8B421ED2]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.MultiThreadedOCPTest.testFillWorkQueue(MultiThreadedOCPTest.java:114) at org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:69) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1008) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:983) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627826#comment-16627826 ] Karl Wright commented on SOLR-12798: [~dsmiley], whereas it doesn't seem to have been appreciated, SolrJ did have reasonable support for multipart post some few major version ago but I appreciate the fact that this is no longer a priority. I'm happy to help get this back to a point that MCF needs. > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - 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 # 894 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/894/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLostTriggerWithDeleteNodePreferredOp Error Message: Error from server at http://127.0.0.1:33116/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:33116/solr: create the collection time out:180s at __randomizedtesting.SeedInfo.seed([D8DE3DD0028AFB5D:4771993375326234]: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:1107) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:884) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:817) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.cloud.autoscaling.ComputePlanActionTest.testNodeLostTriggerWithDeleteNodePreferredOp(ComputePlanActionTest.java:653) 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:1742) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:935) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:971) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:985) 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:944) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:830) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:880) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:891) 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
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627718#comment-16627718 ] David Smiley commented on SOLR-12798: - Okay I appreciate your points. It'd be nice if SolrJ could be enhanced to support multi-part to avoid long URL construction. Please help make this a first class supported feature if it matters to you/ManifoldCF. I don't think this is a bug though, and thus not a regression. Before 7.5 by your account you really had to go out of your way to make multi-part work with SolrJ. The internals changed which thwarted your efforts (a shame) but doesn't represent a bug. I appreciate it's a frustrating unexpected turn of events, nonetheless. > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[
https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627698#comment-16627698
]
Karl Wright edited comment on SOLR-12798 at 9/25/18 5:39 PM:
-
[~dsmiley], there are two problems with using UpdateRequest. First, as you
point out, the entire document has to hit memory. This is problematic because
sometimes these documents are massive and nevertheless Tika needs all of them
to extract stuff from them. So we allow two modes of operation:
(1) Via Solr Cell, in which case we use ContentStreamUpdateRequest, which
embeds a stream and forms the request without having the entire document hit
memory, and
(2) Via UpdateRequest, and SolrinputDocument, but only after Tika has been
invoked, and with a length limit. Even then we have problems with people
running out of memory unless they are very careful, given that there are
sometimes dozens of indexing requests active at any one time.
This information, by the way, has nothing to do with length limits on the URL,
since those are determined solely by metadata, which can be large and is
independent of the main content stream. URL limits get in the way just as
readily when we use mode (2) as when we use mode (1).
{quote}
Note the existence of UpdateRequest.setDocIterator(Iterator)
which can be helpful in streaming and materializing documents on the fly.
{quote}
Yes, of course it can, but the way SolrJ is constructed it makes no use of
this. In fact, it currently doesn't use multipart post at all, unless I
override much functionality in order to force it to do so.
was (Author: kwri...@metacarta.com):
[~dsmiley], there are two problems with using UpdateRequest. First, as you
point out, the entire document has to hit memory. This is problematic because
sometimes these documents are massive and nevertheless Tika needs all of them
to extract stuff from them. So we allow two modes of operation:
(1) Via Solr Cell, in which case we use ContentStreamUpdateRequest, which
embeds a stream and forms the request without having the entire document hit
memory, and
(2) Via UpdateRequest, and SolrinputDocument, but only after Tika has been
invoked, and with a length limit. Even then we have problems with people
running out of memory unless they are very careful, given that there are
sometimes dozens of indexing requests active at any one time.
This information, by the way, has nothing to do with length limits on the URL,
since those are determined solely by metadata, which can be large and is
independent of the main content stream. URL limits get in the way just as
readily when we use mode (2) as when we use mode (1).
> Structural changes in SolrJ since version 7.0.0 have effectively disabled
> multipart post
>
>
> Key: SOLR-12798
> URL: https://issues.apache.org/jira/browse/SOLR-12798
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.4
>Reporter: Karl Wright
>Priority: Major
>
> Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from
> SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to
> SolrJ's HttpSolrClient class that seemingly disable any use of multipart
> post. This is critical because ManifoldCF's documents often contain metadata
> in excess of 4K that therefore cannot be stuffed into a URL.
> The changes in question seem to have been performed by Paul Noble on
> 10/31/2017, with the introduction of the RequestWriter mechanism. Basically,
> if a request has a RequestWriter, it is used exclusively to write the
> request, and that overrides the stream mechanism completely. I haven't
> chased it back to a specific ticket.
> ManifoldCF's usage of SolrJ involves the creation of
> ContentStreamUpdateRequests for all posts meant for Solr Cell, and the
> creation of UpdateRequests for posts not meant for Solr Cell (as well as for
> delete and commit requests). For our release cycle that is taking place
> right now, we're shipping a modified version of HttpSolrClient that ignores
> the RequestWriter when dealing with ContentStreamUpdateRequests. We
> apparently cannot use multipart for all requests because on the Solr side we
> get "pfountz Should not get here!" errors on the Solr side when we do, which
> generate HTTP error code 500 responses. That should not happen either, in my
> opinion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[ https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627698#comment-16627698 ] Karl Wright commented on SOLR-12798: [~dsmiley], there are two problems with using UpdateRequest. First, as you point out, the entire document has to hit memory. This is problematic because sometimes these documents are massive and nevertheless Tika needs all of them to extract stuff from them. So we allow two modes of operation: (1) Via Solr Cell, in which case we use ContentStreamUpdateRequest, which embeds a stream and forms the request without having the entire document hit memory, and (2) Via UpdateRequest, and SolrinputDocument, but only after Tika has been invoked, and with a length limit. Even then we have problems with people running out of memory unless they are very careful, given that there are sometimes dozens of indexing requests active at any one time. This information, by the way, has nothing to do with length limits on the URL, since those are determined solely by metadata, which can be large and is independent of the main content stream. URL limits get in the way just as readily when we use mode (2) as when we use mode (1). > Structural changes in SolrJ since version 7.0.0 have effectively disabled > multipart post > > > Key: SOLR-12798 > URL: https://issues.apache.org/jira/browse/SOLR-12798 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Affects Versions: 7.4 >Reporter: Karl Wright >Priority: Major > > Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from > SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to > SolrJ's HttpSolrClient class that seemingly disable any use of multipart > post. This is critical because ManifoldCF's documents often contain metadata > in excess of 4K that therefore cannot be stuffed into a URL. > The changes in question seem to have been performed by Paul Noble on > 10/31/2017, with the introduction of the RequestWriter mechanism. Basically, > if a request has a RequestWriter, it is used exclusively to write the > request, and that overrides the stream mechanism completely. I haven't > chased it back to a specific ticket. > ManifoldCF's usage of SolrJ involves the creation of > ContentStreamUpdateRequests for all posts meant for Solr Cell, and the > creation of UpdateRequests for posts not meant for Solr Cell (as well as for > delete and commit requests). For our release cycle that is taking place > right now, we're shipping a modified version of HttpSolrClient that ignores > the RequestWriter when dealing with ContentStreamUpdateRequests. We > apparently cannot use multipart for all requests because on the Solr side we > get "pfountz Should not get here!" errors on the Solr side when we do, which > generate HTTP error code 500 responses. That should not happen either, in my > opinion. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12798) Structural changes in SolrJ since version 7.0.0 have effectively disabled multipart post
[
https://issues.apache.org/jira/browse/SOLR-12798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627674#comment-16627674
]
David Smiley commented on SOLR-12798:
-
[~arafalov] I believe this issue is about SolrJ (client-side), not the Solr
server.
[~kwri...@metacarta.com] why must ManifoldCF rely on HTTP Multipart in
particular – can't it compose a SolrInputDocument and just send it like
basically all Solr clients I've ever seen? Is the issue about the "infinite
length" content stream, which I presume maps to some sort of body text? Note
the existence of {{UpdateRequest.setDocIterator(Iterator)}}
which can be helpful in streaming and materializing documents on the fly.
> Structural changes in SolrJ since version 7.0.0 have effectively disabled
> multipart post
>
>
> Key: SOLR-12798
> URL: https://issues.apache.org/jira/browse/SOLR-12798
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 7.4
>Reporter: Karl Wright
>Priority: Major
>
> Project ManifoldCF uses SolrJ to post documents to Solr. When upgrading from
> SolrJ 7.0.x to SolrJ 7.4, we encountered significant structural changes to
> SolrJ's HttpSolrClient class that seemingly disable any use of multipart
> post. This is critical because ManifoldCF's documents often contain metadata
> in excess of 4K that therefore cannot be stuffed into a URL.
> The changes in question seem to have been performed by Paul Noble on
> 10/31/2017, with the introduction of the RequestWriter mechanism. Basically,
> if a request has a RequestWriter, it is used exclusively to write the
> request, and that overrides the stream mechanism completely. I haven't
> chased it back to a specific ticket.
> ManifoldCF's usage of SolrJ involves the creation of
> ContentStreamUpdateRequests for all posts meant for Solr Cell, and the
> creation of UpdateRequests for posts not meant for Solr Cell (as well as for
> delete and commit requests). For our release cycle that is taking place
> right now, we're shipping a modified version of HttpSolrClient that ignores
> the RequestWriter when dealing with ContentStreamUpdateRequests. We
> apparently cannot use multipart for all requests because on the Solr side we
> get "pfountz Should not get here!" errors on the Solr side when we do, which
> generate HTTP error code 500 responses. That should not happen either, in my
> opinion.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-10337) HTMLStripCharFilterFactory does not seem to handle
[
https://issues.apache.org/jira/browse/SOLR-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-10337.
---
Resolution: Cannot Reproduce
Assignee: Steve Rowe
Closing as cannot reproduce, since the issue is not about HTMLStripCharFilter.
I'm guessing that Tika can be configured to exclude {{...}}
content inside {{}} tags, e.g. Solr Cell has an XPath capability:
https://lucene.apache.org/solr/guide/6_6/uploading-data-with-solr-cell-using-apache-tika.html#UploadingDatawithSolrCellusingApacheTika-XPath
> HTMLStripCharFilterFactory does not seem to handle section inside a
> section
> ---
>
> Key: SOLR-10337
> URL: https://issues.apache.org/jira/browse/SOLR-10337
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - Solr Cell (Tika extraction)
>Affects Versions: 6.4.1
> Environment: WIndows 7 professional 64bit (current patch/release)
>Reporter: NW Brad
>Assignee: Steve Rowe
>Priority: Major
>
> HTMLStripCharFilterFactory does not remove