[JENKINS] Lucene-Solr-Tests-7.x - Build # 597 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/597/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode
Error Message:
unexpected DELETENODE status:
{responseHeader={status=0,QTime=14},status={state=notfound,msg=Did not find
[search_rate_trigger3/5bbecaa30e0ea2T1fx1pgna828yc0kt3kph9ozt1/0] in any tasks
queue}}
Stack Trace:
java.lang.AssertionError: unexpected DELETENODE status:
{responseHeader={status=0,QTime=14},status={state=notfound,msg=Did not find
[search_rate_trigger3/5bbecaa30e0ea2T1fx1pgna828yc0kt3kph9ozt1/0] in any tasks
queue}}
at
__randomizedtesting.SeedInfo.seed([1753AFF90ADB73E4:35C1617B3D11FC99]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.lambda$testDeleteNode$6(SearchRateTriggerIntegrationTest.java:668)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode(SearchRateTriggerIntegrationTest.java:660)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
[jira] [Commented] (SOLR-12238) Synonym Query Style Boost By Payload
[
https://issues.apache.org/jira/browse/SOLR-12238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464971#comment-16464971
]
Lucene/Solr QA commented on SOLR-12238:
---
| (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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
20s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 54s{color}
| {color:red} lucene_core generated 1 new + 0 unchanged - 0 fixed = 1 total
(was 0) {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 1m 54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 1m 54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 1m 54s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 41m
51s{color} | {color:green} core in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 69m 9s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}132m 56s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.rest.TestManagedResourceStorage |
| | solr.cloud.autoscaling.sim.TestLargeCluster |
| | solr.cloud.autoscaling.SearchRateTriggerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12238 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12921949/SOLR-12238.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns validaterefguide |
| 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-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 89fc02a |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_172 |
| javac |
https://builds.apache.org/job/PreCommit-SOLR-Build/79/artifact/out/diff-compile-javac-lucene_core.txt
|
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/79/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/79/testReport/ |
| modules | C: lucene/core solr/core solr/solr-ref-guide U: . |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/79/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Synonym Query Style Boost By Payload
>
>
> Key: SOLR-12238
> URL: https://issues.apache.org/jira/browse/SOLR-12238
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 7.2
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-12238.patch, SOLR-12238.patch, SOLR-12238.patch,
> SOLR-12238.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This improvement is built on top of the Synonym Query Style feature and
> brings the possibility of boosting synonym queries using the payload
> associated.
> It introduces two new modalities for the Synonym Query Style :
> PICK_BEST_BOOST_BY_PAYLOAD -> build a Disjunction query with the clauses
> boosted by payload
> AS_DISTINCT_TERMS_BOOST_BY_PAYLOAD -> build a Boolean query with the clauses
> boosted by payload
> This new synonym query styles will assume payloads are available so they must
> be used in conjunction with a token filter able to produce payloads.
> An synonym.txt example could be :
> # Synonyms used by Payload Boost
> tiger => tiger|1.0, Big_Cat|0.8, Shere_Khan|0.9
> leopard => leopard, Big_Cat|0.8, Bagheera|0.9
> lion => lion|1.0, panthera leo|0.99,
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464969#comment-16464969 ] Shawn Heisey commented on SOLR-8207: Thanks for looking into making improvements! There's some really good info being shown here. Some thoughts after looking at screenshots: * I think that perhaps "refresh" would be a better label than "reload". There is potential for confusion with the reload action on core/collection APIs. Having different buttons to reload the collections might be a nice addition. * What is the percentage on the disk column -- free or used? Unless the nodes being reported on the screenshots are extremely small VMs or containers, I think that the 91 or 92 percent shown there must be percent free. It is my opinion that without text indicating which one is displayed, it should be percent used, not percent free, as is the case for other columns like Heap. If consensus is that percent free is more useful for disk space, then it should say "free" somewhere. * I wasn't sure what the GC numbers meant until I read the comments more closely. If I'm reading the info correctly, it's number of collections for a five minute period, averaged over the whole JVM uptime. Unless request traffic is fairly uniform 24 hours per day, this does not seem like a very useful number to me. I do not know if the JVM can access GC data for a smaller timeframe. If not, it might not be possible to provide better information here. * If the table only includes one request rate, I think I would prefer to see the 15 minute rate rather than the 1 minute rate. Maybe that's just me. :) > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- 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-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464961#comment-16464961 ] Erick Erickson commented on SOLR-12297: --- FWIW, we did move change the minimum requirement for a point release at least once in the past (Lucene 4.8 was the first to require java 7). Not saying that's a precedent we should follow here, but at least it's been done before. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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 # 583 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/583/ [...truncated 43 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/596/consoleText [repro] Revision: 0e45b39476f287fe56ec4734c5c8695a99f8cb5d [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testTrigger -Dtests.seed=CC7CCC5920CAD934 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-NI -Dtests.timezone=Asia/Ulan_Bator -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration -Dtests.seed=CC7CCC5920CAD934 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-NI -Dtests.timezone=Asia/Ulan_Bator -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=TestCollectionStateWatchers -Dtests.method=testWaitForStateChecksCurrentState -Dtests.seed=DB7D798FB74F6A97 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=pt-BR -Dtests.timezone=Kwajalein -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=NoFacetTest -Dtests.seed=619C37EC84026E22 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ms -Dtests.timezone=America/Dawson_Creek -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: 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [repro] git fetch [repro] git checkout 0e45b39476f287fe56ec4734c5c8695a99f8cb5d [...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] IndexSizeTriggerTest [repro]solr/contrib/analytics [repro] NoFacetTest [repro]solr/solrj [repro] TestCollectionStateWatchers [repro] ant compile-test [...truncated 3316 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -Dtests.seed=CC7CCC5920CAD934 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=es-NI -Dtests.timezone=Asia/Ulan_Bator -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 5803 lines...] [repro] Setting last failure code to 256 [repro] ant compile-test [...truncated 576 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.NoFacetTest" -Dtests.showOutput=onerror -Dtests.seed=619C37EC84026E22 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ms -Dtests.timezone=America/Dawson_Creek -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 141 lines...] [repro] ant compile-test [...truncated 447 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.TestCollectionStateWatchers" -Dtests.showOutput=onerror -Dtests.seed=DB7D798FB74F6A97 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=pt-BR -Dtests.timezone=Kwajalein -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 2188 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.analytics.NoFacetTest [repro] 2/5 failed: org.apache.solr.common.cloud.TestCollectionStateWatchers [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [...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-Tests-7.3 - Build # 62 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.3/62/
4 tests failed.
FAILED: org.apache.solr.TestDistributedSearch.test
Error Message:
Expected to find shardAddress in the up shard info:
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException:
Time allowed to handle this request exceeded at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
java.util.concurrent.FutureTask.run(FutureTask.java:266) at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
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) ,time=32}
Stack Trace:
java.lang.AssertionError: Expected to find shardAddress in the up shard info:
{error=org.apache.solr.client.solrj.SolrServerException: Time allowed to handle
this request exceeded,trace=org.apache.solr.client.solrj.SolrServerException:
Time allowed to handle this request exceeded
at
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:460)
at
org.apache.solr.handler.component.HttpShardHandlerFactory.makeLoadBalancedRequest(HttpShardHandlerFactory.java:273)
at
org.apache.solr.handler.component.HttpShardHandler.lambda$submit$0(HttpShardHandler.java:175)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176)
at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:188)
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)
,time=32}
at
__randomizedtesting.SeedInfo.seed([4F7DA2896DA01EEC:C7299D53C35C7314]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.TestDistributedSearch.comparePartialResponses(TestDistributedSearch.java:1191)
at
org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:1132)
at
org.apache.solr.TestDistributedSearch.test(TestDistributedSearch.java:992)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019)
at
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
[jira] [Commented] (SOLR-12299) More Like This Params Refactor
[
https://issues.apache.org/jira/browse/SOLR-12299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464957#comment-16464957
]
Lucene/Solr QA commented on SOLR-12299:
---
| (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 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
28s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 0m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 0m 49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 0m 49s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
53s{color} | {color:green} classification in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
36s{color} | {color:green} queries in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 72m 0s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 84m 8s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.ZkControllerTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12299 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12921948/SOLR-12299.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8
21:10:42 UTC 2016 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 / 89fc02a |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_172 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/78/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/78/testReport/ |
| modules | C: lucene/classification lucene/queries solr/core U: . |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/78/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> More Like This Params Refactor
> --
>
> Key: SOLR-12299
> URL: https://issues.apache.org/jira/browse/SOLR-12299
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: MoreLikeThis
>Reporter: Alessandro Benedetti
>Priority: Major
> Attachments: SOLR-12299.patch, SOLR-12299.patch, SOLR-12299.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> More Like This ca be refactored to improve the code readability, test
> coverage and maintenance.
> Scope of this Jira issue is to start the More Like This refactor from the
> More Like This Params.
> This Jira will not improve the current More Like This but just keep the same
> functionality with a refactored code.
> Other Jira issues will follow improving the overall code readability, test
> coverage and maintenance.
--
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-7.3-Linux (64bit/jdk-10) - Build # 180 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-7.x - Build # 54 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-7.x/54/ 4 tests failed. FAILED: org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testBasic Error Message: there should be new MOVERPLICA ops Stack Trace: java.lang.AssertionError: there should be new MOVERPLICA ops at __randomizedtesting.SeedInfo.seed([1984A90B71BD0570:B27EB41EAE61835E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.sim.TestLargeCluster.testBasic(TestLargeCluster.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTriggerRestoreState Error Message: Two TriggerAction instances should have been created by now Stack Trace: java.lang.AssertionError: Two TriggerAction instances should have been created by now at
[JENKINS-EA] Lucene-Solr-master-Windows (64bit/jdk-11-ea+5) - Build # 7303 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7303/ Java: 64bit/jdk-11-ea+5 -XX:-UseCompressedOops -XX:+UseSerialGC 37 tests failed. FAILED: org.apache.solr.handler.TestReplicationHandler.doTestStressReplication Error Message: found:2[index.20180505165245111, index.20180505165309239, index.properties, replication.properties, snapshot_metadata] Stack Trace: java.lang.AssertionError: found:2[index.20180505165245111, index.20180505165309239, index.properties, replication.properties, snapshot_metadata] at __randomizedtesting.SeedInfo.seed([F232A634382482CE:2999A6F23D0CEB7D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:968) at org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:939) at org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:915) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Comment Edited] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464893#comment-16464893
]
Mikhail Khludnev edited comment on SOLR-12303 at 5/5/18 8:50 PM:
-
reworked [^SOLR-12303.patch].
* I definitely anxious regarding {{request.path}} I've never use it and can't
really understand the purpose that's why I use {{qt}}.
* it boils down to question about inheriting main query params in subquery. It
makes sense for {{qt}}, but not for {{fl}} that's how it's done explicitly
* I used existing config.
Also, I don't think tests like {{assertQEx(..."subq1.qt", "/bleh",..)}}
make sense at all, they should pass (request fails) now as is.
was (Author: mkhludnev):
reworked [^SOLR-12303.xml].
* I definitely anxious regarding {{request.path}} I've never use it and can't
really understand the purpose that's why I use {{qt}}.
* it boils down to question about inheriting main query params in subquery. It
makes sense for {{qt}}, but not for {{fl}} that's how it's done explicitly
* I used existing config.
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464893#comment-16464893
]
Mikhail Khludnev commented on SOLR-12303:
-
reworked [^SOLR-12303.xml].
* I definitely anxious regarding {{request.path}} I've never use it and can't
really understand the purpose that's why I use {{qt}}.
* it boils down to question about inheriting main query params in subquery. It
makes sense for {{qt}}, but not for {{fl}} that's how it's done explicitly
* I used existing config.
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.xml
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12303:
Attachment: SOLR-12303.patch
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12303:
Attachment: (was: SOLR-12303.xml)
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-12303:
Attachment: SOLR-12303.xml
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.xml
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-BadApples-NightlyTests-master - Build # 9 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/9/ 15 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.cdcr.CdcrReplicationDistributedZkTest Error Message: 18 threads leaked from SUITE scope at org.apache.solr.cloud.cdcr.CdcrReplicationDistributedZkTest: 1) Thread[id=7455, name=cdcr-replicator-1605-thread-5, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)2) Thread[id=7473, name=cdcr-replicator-1605-thread-6, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)3) Thread[id=12432, name=cdcr-replicator-2571-thread-3, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)4) Thread[id=12490, name=cdcr-replicator-2571-thread-8, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)5) Thread[id=7475, name=cdcr-replicator-1605-thread-7, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)6) Thread[id=7298, name=cdcr-replicator-1605-thread-1, state=WAITING, group=TGRP-CdcrReplicationDistributedZkTest] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[jira] [Comment Edited] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464863#comment-16464863 ] Mark Miller edited comment on SOLR-12297 at 5/5/18 7:11 PM: Keep in mind that most of what you will read or see regarding Http2 is related to standard web browser serving when we are looking to use it in the context of a client server application. The browsers say they will will require TLS with Http2 - that is a personal decision. We won't require TLS with Http2. If you hit Solr with a browser and no TLS, it will use Http1.1. We don't care about browser->solr and the Http protocol. Http2 also improves the performance of Http pipelining - this is the type of thing that can make a new Http2 capable client as nice as ConcurrenUpdateSolrClient but with actually good responses, especially when paired with async. The Jetty HttpClient even works in a similar manner as CUSC with per dentition queues and a thread pool and multiple connections (multiplexed with http2!). The bulk API that puts multiple updates in a single request will still be the fastest way to bulk load, but the responses can never be good for that. You have to consider the whole batch as good or bad depending on the response and even if we added fine grained responses, for you some failure cases you would still have to treat the bulk call as a single success/fail unit. So that is what is exciting to me and part of why this was titled making a good client for SolrCloud. This will let us make CloudSolrServer as good as it can be. Right now it's lackluster and the alternative of using CUSC is a bitter alternative. This will also let us improve the other clients when it comes to internal communication and connection breaks and efficiency and performance, etc, etc. One Http2SolrClient makes the whole world better - even without http2, there will be improvements. We also get better update streaming encoding than chunked and fewer connections pooled. We also get all these other little improvements. It's just a better server / client experience. was (Author: markrmil...@gmail.com): Keep in mind that most of what you will read or see regarding Http2 is related to standard web browser serving when we are looking to use it in the context of a client server application. The browsers say they will will require TLS with Http2 - that is a personal decision. We won't require TLS with Http2. If you hit Solr with a browser and no TLS, it will use Http1.1. We don't care about browser->solr and the Http protocol. Http2 also improves the performance of Http2 pipelining - this is the type of thing that can make a new Http2 capable client as nice as ConcurrenUpdateSolrClient but with actually good responses, especially when paired with async. Where we still won't compete with CUSC is with the bulk API, where you add multiple documents in a single request (you can't get good responses though). We also get better update streaming encoding than chunked and fewer connections pooled. We also get all these other little improvements. It's just a better server / client experience. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- This message was sent
[jira] [Commented] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464863#comment-16464863 ] Mark Miller commented on SOLR-12297: Keep in mind that most of what you will read or see regarding Http2 is related to standard web browser serving when we are looking to use it in the context of a client server application. The browsers say they will will require TLS with Http2 - that is a personal decision. We won't require TLS with Http2. If you hit Solr with a browser and no TLS, it will use Http1.1. We don't care about browser->solr and the Http protocol. Http2 also improves the performance of Http2 pipelining - this is the type of thing that can make a new Http2 capable client as nice as ConcurrenUpdateSolrClient but with actually good responses, especially when paired with async. Where we still won't compete with CUSC is with the bulk API, where you add multiple documents in a single request (you can't get good responses though). We also get better update streaming encoding than chunked and fewer connections pooled. We also get all these other little improvements. It's just a better server / client experience. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464860#comment-16464860 ] Varun Thacker commented on SOLR-11453: -- Quick patch , where we create a new solr_slow_requests.log file which logs slow requests . This is in addition to logging in the solr.log file ( we don't want to change this behaviour atleast in the 7.x code base ) > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, > SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-11453: - Attachment: SOLR-11453.patch > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch, > SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-12297: -- Assignee: Mark Miller > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464855#comment-16464855
]
Mark Miller commented on SOLR-12297:
{quote}I think we need to make things a lot easier than they are now before we
consider https out of the box.
{quote}
Defaulting to having TLS on out of the box is completely unrelated to this
issue.
{quote}On ALPN and Java 8/9:
{quote}
We don't really need to worry about it now that they don't require the ALPN
boot jar stuff pre 9.
{quote}http2 is not likely to achieve much of a performance boost compared to
http/1.1. TCP/HTTP negotiation is cheap on a LAN
{quote}
My motivation for http2 is not TCP/HTTP negotiation or general performance - we
count on connection pooling largely, we are not an html web server - it's for
things like fewer connections with multiplexing and connection stability /
reuse simplicity. Of course HPACK compression and stuff is also nice to be able
to use. And we may find other benefits we can take advantage of. Multiplexing
is what I want most and support for that is what gives us hardier connection
reuse.
{quote}I think it would be a mistake for us to consider requiring Java 9
{quote}
When we move to Java 9 is also a separate issue from this JIRA and http2
wouldn't really factor in even if we needed Java9 for it, which we don't
anymore.
> Create a good SolrClient for SolrCloud paving the way for async requests,
> HTTP2, multiplexing, and the latest & greatest Jetty features.
>
>
> Key: SOLR-12297
> URL: https://issues.apache.org/jira/browse/SOLR-12297
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
>Priority: Major
>
> Blocking or async support as well as HTTP2 compatible with multiplexing.
> Once it supports enough and is stable, replace internal usage, allowing
> async, and eventually move to HTTP2 connector and allow multiplexing. Could
> support HTTP1.1 and HTTP2 on different ports depending on state of the world
> then.
> The goal of the client itself is to work against HTTP1.1 or HTTP2 with
> minimal or no code path differences and the same for async requests (should
> initially work for both 1.1 and 2 and share majority of code).
> The client should also be able to replace HttpSolrClient and plug into the
> other clients the same way.
> I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually
> though.
> I evaluated some clients and while there are a few options, I went with
> Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5
> beta) and we would have to update to a new API for Apache HttpClient anyway.
> Meanwhile, the Jetty guys have been very supportive of helping Solr with any
> issues and I like having the client and server from the same project.
--
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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464852#comment-16464852 ] Ralph Goers edited comment on SOLR-11453 at 5/5/18 6:07 PM: Yes, as the implementation of those shows, it is entirely possible to dynamically create appenders. If those don't exactly meet your needs you could look at what they do and create something similar that does. You could either include that with Solr or provide a patch to Log4j to include it. For example, if you don't want to rely on a Script you could modify ScriptAppenderSelector to be SystemPropertyAppenderSelector where the build method would rely on the system property to choose which Appender to create. Or if you want to rely on some Solr configuration provide a hook to Solr's configuration to choose the Appender. was (Author: ralph.go...@dslextreme.com): Yes, as the implementation of those shows, it is entirely possible to dynamically create appenders. If those don't exactly meet your needs you could look at what they do and create something similar that does. You could either include that with Solr or provide a patch to Log4j to include it. For example, if you don't want to rely on a Script you could modify ScriptAppenderSelector to be SystemPropertyAppenderSelector where the build method would rely on the system property to choose which Appender to create. > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464852#comment-16464852 ] Ralph Goers commented on SOLR-11453: Yes, as the implementation of those shows, it is entirely possible to dynamically create appenders. If those don't exactly meet your needs you could look at what they do and create something similar that does. You could either include that with Solr or provide a patch to Log4j to include it. For example, if you don't want to rely on a Script you could modify ScriptAppenderSelector to be SystemPropertyAppenderSelector where the build method would rely on the system property to choose which Appender to create. > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-11741) Offline training mode for schema guessing
[
https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464841#comment-16464841
]
Abhishek Kumar Singh commented on SOLR-11741:
-
In order to use LearnSchemaUpdateRequestProcessorFactory, add just it to the
URP chain.
The new API details are :-
# *_Get A Training Id:_***
*_GET_*
*_//schema/train/start_*
Response:
{code:java}
{"schemaTrainingId" : ""}
{code}
*2. Start Training:*
This api is just like another update api, with documents to be trained with.
*POST*
*//update?schemaTrainingId=*
{code:java}
Body: (Same as update request)
[{}]
{code}
*3. Get the schema trained so far:-*
*GET*
*/schema/train/yield?schemaTrainingId=*
*Response:*
{code:java}
{
"schema":{
"add-field-type": [
{ "name":, "type":, "multivalued":},
{ "name":, "type":, "multivalued":},
...
]
}
}
{code}
**
> Offline training mode for schema guessing
> -
>
> Key: SOLR-11741
> URL: https://issues.apache.org/jira/browse/SOLR-11741
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch,
> SOLR-11741.patch, SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png,
> screenshot-3.png
>
>
> Our data driven schema guessing doesn't work under many situations. For
> example, if the first document has a field with value "0", it is guessed as
> Long and subsequent fields with "0.0" are rejected. Similarly, if the same
> field had alphanumeric contents for a latter document, those documents are
> rejected. Also, single vs. multi valued field guessing is not ideal.
> Proposing an offline training mode where Solr accepts bunch of documents and
> returns a guessed schema (without indexing). This schema can then be used for
> actual indexing. I think the original idea is from Hoss.
> I think initial implementation can be based on an UpdateRequestProcessor. We
> can hash out the API soon, as we go along.
--
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-7.x-Linux (64bit/jdk-10) - Build # 1853 - Unstable!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464835#comment-16464835 ] Shawn Heisey commented on SOLR-12297: - I'm generally on the "TLS everywhere" bandwagon for anything happening on the Internet. But for internal services, especially those running java software, I think h2c is a must-have, with an option to disable it. TLS configuration with most Java software (including Solr and Jetty) is a little messy. I think we need to make things a lot easier than they are now before we consider https out of the box. At the very least we need scripts to automate keystore creation and REALLY good documentation for using them. On switching to the jetty client: Sounds good to me, especially if we're going to continue to use Jetty on the server side for the foreseeable future. I agree that they've been a great community to work with. The apache client seems to be very good software, and although I haven't noticed any actual *problems* in dealing with the httpcomponents community, the project moves very slowly. That doesn't look like it's going to change anytime soon. On ALPN and Java 8/9: The docs I've read say that the conscrypt ALPN solution works in both Java 8 and Java 9, so we don't need to have different solutions for those versions. (what do we know about Java 10?) Side thought regarding http2: For installations on a LAN, http2 is not likely to achieve much of a performance boost compared to http/1.1. TCP/HTTP negotiation is cheap on a LAN, even when using speeds below gigabit. We shouldn't let that be a justification for not keeping up with the advance of technology. Another side thought: Java 8 hits the "end of public updates" milestone in January 2019. I think it would be a mistake for us to consider requiring Java 9 in any release that happens this year. And I think we should stick to major releases for Java upgrades. The upgrade to Java 7 in the 4.8 minor release did not generate the upheaval I thought it might, but that sort of change in a minor release doesn't strike me as a good idea in general. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464834#comment-16464834 ] Shawn Heisey commented on SOLR-11453: - Those appenders look very interesting. Sounds like we could use one or more system properties to control whether separate logfiles are created, all within the log4j2.xml config. > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Kumar Singh updated SOLR-11741: Attachment: SOLR-11741.patch > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png, > screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464831#comment-16464831 ] Abhishek Kumar Singh commented on SOLR-11741: - [^SOLR-11741.patch] Adding updated APIs. > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png, > screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464831#comment-16464831 ] Abhishek Kumar Singh edited comment on SOLR-11741 at 5/5/18 4:33 PM: - [^SOLR-11741.patch] Adding updated patch. was (Author: abhidemon): [^SOLR-11741.patch] Adding updated APIs. > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png, > screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Kumar Singh updated SOLR-11741: Attachment: SOLR-11741.patch > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, SOLR-11741.patch, screenshot-1.png, screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464830#comment-16464830 ] Abhishek Kumar Singh commented on SOLR-11741: - [^SOLR-11741.patch] > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, screenshot-1.png, screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464829#comment-16464829 ] Abhishek Kumar Singh edited comment on SOLR-11741 at 5/5/18 4:31 PM: - Uploading the updated patch, with following features:- A new URP LearnSchemaUpdateRequestProcessorFactory: It simply learns from the incoming data to check what the current data type looks like. Based on, it updates the metadata about each field. was (Author: abhidemon): Uploading the updated patch, with following features:- A new URP LearnSchemaUpdateRequestProcessorFactory: It simply learns from the incoming data to check what the current data type looks like. Based on, it updates the metadata about each field. APIs: > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, screenshot-1.png, screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11741) Offline training mode for schema guessing
[ https://issues.apache.org/jira/browse/SOLR-11741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464829#comment-16464829 ] Abhishek Kumar Singh commented on SOLR-11741: - Uploading the updated patch, with following features:- A new URP LearnSchemaUpdateRequestProcessorFactory: It simply learns from the incoming data to check what the current data type looks like. Based on, it updates the metadata about each field. APIs: > Offline training mode for schema guessing > - > > Key: SOLR-11741 > URL: https://issues.apache.org/jira/browse/SOLR-11741 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: RuleForMostAccomodatingField.png, SOLR-11741-temp.patch, > SOLR-11741.patch, screenshot-1.png, screenshot-3.png > > > Our data driven schema guessing doesn't work under many situations. For > example, if the first document has a field with value "0", it is guessed as > Long and subsequent fields with "0.0" are rejected. Similarly, if the same > field had alphanumeric contents for a latter document, those documents are > rejected. Also, single vs. multi valued field guessing is not ideal. > Proposing an offline training mode where Solr accepts bunch of documents and > returns a guessed schema (without indexing). This schema can then be used for > actual indexing. I think the original idea is from Hoss. > I think initial implementation can be based on an UpdateRequestProcessor. We > can hash out the API soon, as we go along. -- 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-11934) Visit Solr logging, it's too noisy.
[
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464824#comment-16464824
]
Shawn Heisey commented on SOLR-11934:
-
[~erickerickson], I like your ideas.
The query logging is also a significant contributor, *especially* on sharded
indexes. SOLR-11453 got me thinking in the background about the possibility of
sending query (technically, actually request, which includes query) logs to
their own file as well.
Updates do result in particularly verbose and numerous logs. I wonder if
there's any value to extending the 'separate logfile' paradigm for the detailed
information, with the summary info you suggested in the main log.
The only disadvantage I can think of with separate logfiles for primary logging
events, and the main notion that makes me *slightly* resistant to making that
config default, is that it is very difficult to reconstruct a narrative of
events that are logged at the same millisecond in those separate files. If
they're all in the same file, it's usually very easy to determine the order of
events. If we do make separate request/update logs a default config, the
documentation must explain how to turn those separate logs off. That would be
vital to troubleshooting issues that only show up under heavy load.
> Visit Solr logging, it's too noisy.
> ---
>
> Key: SOLR-11934
> URL: https://issues.apache.org/jira/browse/SOLR-11934
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I think we have way too much INFO level logging. Or, perhaps more correctly,
> Solr logging needs to be examined and messages logged at an appropriate level.
> We log every update at an INFO level for instance. But I think we log LIR at
> INFO as well. As a sysadmin I don't care to have my logs polluted with a
> message for every update, but if I'm trying to keep my system healthy I want
> to see LIR messages and try to understand why.
> Plus, in large installations logging at INFO level is creating a _LOT_ of
> files.
> What I want to discuss on this JIRA is
> 1> What kinds of messages do we want log at WARN, INFO, DEBUG, and TRACE
> levels?
> 2> Who's the audience at each level? For a running system that's functioning,
> sysops folks would really like WARN messages that mean something need
> attention for instance. If I'm troubleshooting should I turn on INFO? DEBUG?
> TRACE?
> So let's say we get some kind of agreement as to the above. Then I propose
> three things
> 1> Someone (and probably me but all help gratefully accepted) needs to go
> through our logging and assign appropriate levels. This will take quite a
> while, I intend to work on it in small chunks.
> 2> Actually answer whether unnecessary objects are created when something
> like log.info("whatever {}", someObjectOrMethodCall); is invoked. Is this
> independent on the logging implementation used? The SLF4J and log4j seem a
> bit contradictory.
> 3> Maybe regularize log, logger, LOG as variable names, but that's a nit.
> As a tactical approach, I suggest we tag each LoggerFactory.getLogger in
> files we work on with //SOLR-(whatever number is assigned when I create
> this). We can remove them all later, but since I expect to approach this
> piecemeal it'd be nice to keep track of which files have been done already.
> Finally, I really really really don't want to do this all at once. There are
> 5-6 thousand log messages. Even at 1,000 a week that's 6 weeks, even starting
> now it would probably span the 7.3 release.
> This will probably be an umbrella issue so we can keep all the commits
> straight and people can volunteer to "fix the files in core" as a separate
> piece of work (hint).
> There are several existing JIRAs about logging in general, let's link them in
> here as well.
> Let the discussion begin!
--
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-12315) the number of docs in each group depends on rows
[ https://issues.apache.org/jira/browse/SOLR-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464811#comment-16464811 ] Duo Chen commented on SOLR-12315: - I debugged the query and found that when the row is set to 2, there is no request to one same shard on "EXECUTE_QUERY" and "GET_FIELDS" stages. > the number of docs in each group depends on rows > > > Key: SOLR-12315 > URL: https://issues.apache.org/jira/browse/SOLR-12315 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Affects Versions: 7.1 >Reporter: Duo Chen >Priority: Critical > Attachments: difference.jpeg > > > Hi, > We used Solr Cloud 7.1.0(3 nodes, 3 shards with 2 replicas). When we used > group query, we found that the number of docs in each group depends on the > rows number(group number). > When the rows bigger then 5, the return docs are correct and stable, for the > rest, the number of docs is smaller than the actual result. > Could you please explain why and give me some suggestion about how to decide > the rows number? -- 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-12315) the number of docs in each group depends on rows
Duo Chen created SOLR-12315: --- Summary: the number of docs in each group depends on rows Key: SOLR-12315 URL: https://issues.apache.org/jira/browse/SOLR-12315 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: CDCR Affects Versions: 7.1 Reporter: Duo Chen Attachments: difference.jpeg Hi, We used Solr Cloud 7.1.0(3 nodes, 3 shards with 2 replicas). When we used group query, we found that the number of docs in each group depends on the rows number(group number). When the rows bigger then 5, the return docs are correct and stable, for the rest, the number of docs is smaller than the actual result. Could you please explain why and give me some suggestion about how to decide the rows number? -- 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-MacOSX (64bit/jdk1.8.0) - Build # 4607 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4607/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([1A1BA7A7895E9E7F:49A2E5176B4F0B85]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger Error Message: waitFor not elapsed but produced an event Stack Trace: java.lang.AssertionError: waitFor not elapsed but produced an event at
[jira] [Assigned] (SOLR-12307) Stop endless spin java.io.IOException: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /autoscaling.json
[
https://issues.apache.org/jira/browse/SOLR-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev reassigned SOLR-12307:
---
Assignee: Mikhail Khludnev
> Stop endless spin java.io.IOException:
> org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode
> = Session expired for /autoscaling.json
> -
>
> Key: SOLR-12307
> URL: https://issues.apache.org/jira/browse/SOLR-12307
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12307.patch
>
>
> When ZK expires one loop continue spinning pointlessly that hurts CI so often
> {code}
> [junit4] 2>at
> org.apache.solr.client.solrj.cloud.DistribStateManager.getAutoScalingConfig(DistribStateManager.java:83)
> ~[java/:?]
>[junit4] 2>at
> org.apache.solr.cloud.autoscaling.OverseerTriggerThread.run(OverseerTriggerThread.java:131)
> {code}
--
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-7.3-Windows (64bit/jdk1.8.0_144) - Build # 42 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/42/ Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudRecovery Error Message: Could not remove the following files (in the order of attempts): C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6\data C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard2_replica_n6 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog\tlog.001: The process cannot access the file because it is being used by another process. C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data\tlog C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2\data C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1\collection1_shard1_replica_n2 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node1 C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node2\collection1_shard2_replica_n4\data\tlog\tlog.001: java.nio.file.FileSystemException: C:\Users\jenkins\workspace\Lucene-Solr-7.3-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.TestCloudRecovery_96D8B5386A01C76D-001\tempDir-001\node2\collection1_shard2_replica_n4\data\tlog\tlog.001: The process cannot access the file because it is being used by another process.
[JENKINS] Lucene-Solr-repro - Build # 581 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/581/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1018/consoleText [repro] Revision: b617489638db4ddca63e5fbc45a58c5695a021d3 [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=TestMiniSolrCloudClusterSSL -Dtests.method=testNoSsl -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=de -Dtests.timezone=Chile/Continental -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testTrigger -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testMergeIntegration -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -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: 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [repro] git fetch [repro] git checkout b617489638db4ddca63e5fbc45a58c5695a021d3 [...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] IndexSizeTriggerTest [repro] TestMiniSolrCloudClusterSSL [repro] ant compile-test [...truncated 3298 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.IndexSizeTriggerTest|*.TestMiniSolrCloudClusterSSL" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 9870 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.TestMiniSolrCloudClusterSSL [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] Re-testing 100% failures at the tip of master [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3298 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=3D82BBFBED49BA11 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 8408 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of master: [repro] 5/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] Re-testing 100% failures at the tip of master without a seed [repro] ant clean [...truncated 8 lines...] [repro] Test suites by module: [repro]solr/core [repro] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3298 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.multiplier=2 -Dtests.locale=bg-BG -Dtests.timezone=Asia/Karachi -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 4074 lines...] [repro] Setting last failure code to 256 [repro] Failures at the tip of master without a seed: [repro] 3/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [...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
[jira] [Commented] (SOLR-9685) tag a query in JSON syntax
[
https://issues.apache.org/jira/browse/SOLR-9685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464747#comment-16464747
]
Dmitry Tikhonov commented on SOLR-9685:
---
Based on comment above:
https://github.com/apache/lucene-solr/pull/371
> tag a query in JSON syntax
> --
>
> Key: SOLR-9685
> URL: https://issues.apache.org/jira/browse/SOLR-9685
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module, JSON Request API
>Reporter: Yonik Seeley
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There should be a way to tag a query/filter in JSON syntax.
> Perhaps these two forms could be equivalent:
> {code}
> "{!tag=COLOR}color:blue"
> { tagged : { COLOR : "color:blue" }
> {code}
--
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
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
GitHub user squallsama opened a pull request:
https://github.com/apache/lucene-solr/pull/371
SOLR-9685 tag a query in JSON syntax
Support following structure: {"#RCOLOR": { "term": { "f": "color","v":
"blue"}}}
RCOLOR will be tag name
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/squallsama/lucene-solr 7_3_SOLR-9685
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/371.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #371
commit 732f11de1a4e8e10bbae8363f9cf511d65c91374
Author: Dmitry Tikhonov
Date: 2018-03-29T17:54:47Z
SOLR-9685 tag a query in JSON syntax
Support following structure: {"#RCOLOR": { "term": { "f": "color","v":
"blue"}}}
RCOLOR will be tag name
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #347: SOLR-9685 tag a query in JSON syntax
Github user squallsama closed the pull request at: https://github.com/apache/lucene-solr/pull/347 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_144) - Build # 7302 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7302/ Java: 32bit/jdk1.8.0_144 -client -XX:+UseSerialGC 65 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([F8A20A35B9DAD0E6:AB1B48855BCB451C]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1538 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1538/ 1 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.LeaderElectionContextKeyTest Error Message: Could not load collection from ZK: testCollection1 Stack Trace: org.apache.solr.common.SolrException: Could not load collection from ZK: testCollection1 at __randomizedtesting.SeedInfo.seed([B60225E5447CD6C7]:0) at org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1301) at org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:730) at org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:148) at org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:131) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:154) at org.apache.solr.cloud.LeaderElectionContextKeyTest.setupCluster(LeaderElectionContextKeyTest.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Caused by: org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = Session expired for /collections/testCollection1/state.json at org.apache.zookeeper.KeeperException.create(KeeperException.java:130) at org.apache.zookeeper.KeeperException.create(KeeperException.java:54) at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1215) at org.apache.solr.common.cloud.SolrZkClient.lambda$getData$5(SolrZkClient.java:340) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:60) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:340) at org.apache.solr.common.cloud.ZkStateReader.fetchCollectionState(ZkStateReader.java:1313) at org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1299) ... 29 more Build Log: [...truncated 14167 lines...] [junit4] Suite: org.apache.solr.cloud.LeaderElectionContextKeyTest [junit4] 2> 2468401 INFO (SUITE-LeaderElectionContextKeyTest-seed#[B60225E5447CD6C7]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/checkout/solr/build/solr-core/test/J1/temp/solr.cloud.LeaderElectionContextKeyTest_B60225E5447CD6C7-001/init-core-data-001 [junit4] 2> 2468402 INFO
[JENKINS] Lucene-Solr-repro - Build # 580 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/580/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/50/consoleText [repro] Revision: b617489638db4ddca63e5fbc45a58c5695a021d3 [repro] Repro line: ant test -Dtestcase=TestTlogReplica -Dtests.method=testRecovery -Dtests.seed=A1E965CAA61A8F45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-SG -Dtests.timezone=Europe/Oslo -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=ForceLeaderTest -Dtests.method=testReplicasInLowerTerms -Dtests.seed=A1E965CAA61A8F45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=sl -Dtests.timezone=Etc/GMT+12 -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: 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [repro] git fetch [...truncated 2 lines...] [repro] git checkout b617489638db4ddca63e5fbc45a58c5695a021d3 [...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] TestTlogReplica [repro] ForceLeaderTest [repro] ant compile-test [...truncated 3298 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.TestTlogReplica|*.ForceLeaderTest" -Dtests.showOutput=onerror -Dtests.seed=A1E965CAA61A8F45 -Dtests.multiplier=2 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=zh-SG -Dtests.timezone=Europe/Oslo -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 17391 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.ForceLeaderTest [repro] 2/5 failed: org.apache.solr.cloud.TestTlogReplica [repro] git checkout 89fc02a3b04aedf2803a46782b3a8b8e9b5c9a7b [...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
[jira] [Commented] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464718#comment-16464718 ] Mark Miller commented on SOLR-12297: Actually I think it does protocol negotiation too. That remove any time based roadblocks for great http2 support. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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-7.x-Solaris (64bit/jdk1.8.0) - Build # 597 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/597/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 14 tests failed. FAILED: org.apache.solr.cloud.TestTlogReplica.testBasicLeaderElection Error Message: Error from server at http://127.0.0.1:44080/solr/tlog_replica_test_basic_leader_election_shard1_replica_t1: Invalid version (expected 2, but 0) or the data in not in 'javabin' format Stack Trace: org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from server at http://127.0.0.1:44080/solr/tlog_replica_test_basic_leader_election_shard1_replica_t1: Invalid version (expected 2, but 0) or the data in not in 'javabin' format at __randomizedtesting.SeedInfo.seed([614CCAC7F81A88C8:F7C40C8F1080CF32]:0) at org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:551) at org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1015) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:886) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948) at org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:948) at org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:819) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.cloud.TestTlogReplica.testBasicLeaderElection(TestTlogReplica.java:655) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk1.8.0_162) - Build # 176 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/176/
Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.solr.core.OpenCloseCoreStressTest.test5Seconds
Error Message:
Captured an uncaught exception in thread: Thread[id=16185, name=Thread-5736,
state=RUNNABLE, group=TGRP-OpenCloseCoreStressTest]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=16185, name=Thread-5736, state=RUNNABLE,
group=TGRP-OpenCloseCoreStressTest]
at
__randomizedtesting.SeedInfo.seed([8B8E9AD6B8CE747A:6DA1CA93D9A0D2EE]:0)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -3
at __randomizedtesting.SeedInfo.seed([8B8E9AD6B8CE747A]:0)
at java.util.ArrayList.elementData(ArrayList.java:422)
at java.util.ArrayList.get(ArrayList.java:435)
at
org.apache.solr.core.OpenCloseCoreStressTest.getRandomCore(OpenCloseCoreStressTest.java:290)
at org.apache.solr.core.OneIndexer.run(OpenCloseCoreStressTest.java:385)
Build Log:
[...truncated 13289 lines...]
[junit4] Suite: org.apache.solr.core.OpenCloseCoreStressTest
[junit4] 2> Creating dataDir:
/home/jenkins/workspace/Lucene-Solr-7.3-Linux/solr/build/solr-core/test/J2/temp/solr.core.OpenCloseCoreStressTest_8B8E9AD6B8CE747A-001/init-core-data-001
[junit4] 2> 1256611 WARN
(SUITE-OpenCloseCoreStressTest-seed#[8B8E9AD6B8CE747A]-worker) []
o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=28 numCloses=28
[junit4] 2> 1256611 INFO
(SUITE-OpenCloseCoreStressTest-seed#[8B8E9AD6B8CE747A]-worker) []
o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true)
w/NUMERIC_DOCVALUES_SYSPROP=false
[junit4] 2> 1256612 INFO
(SUITE-OpenCloseCoreStressTest-seed#[8B8E9AD6B8CE747A]-worker) []
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via:
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
[junit4] 2> 1256612 INFO
(SUITE-OpenCloseCoreStressTest-seed#[8B8E9AD6B8CE747A]-worker) []
o.a.s.SolrTestCaseJ4 SecureRandom sanity checks:
test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom
[junit4] IGNOR/A 0.00s J2 | OpenCloseCoreStressTest.test10Minutes
[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
[junit4] IGNOR/A 0.00s J2 | OpenCloseCoreStressTest.test15Seconds
[junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
[junit4] IGNOR/A 0.00s J2 | OpenCloseCoreStressTest.test1Hour
[junit4]> Assumption #1: 'weekly' test group is disabled (@Weekly())
[junit4] 2> 1256614 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.a.s.SolrTestCaseJ4 ###Starting test5Seconds
[junit4] 2> 1256619 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.Server jetty-9.4.8.v20171121, build timestamp:
2017-11-21T17:27:37-04:00, git hash: 82b8fb23f757335bb3329d540ce37a2a2615f0a8
[junit4] 2> 1256620 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.session DefaultSessionIdManager workerName=node0
[junit4] 2> 1256620 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.session No SessionScavenger set, using defaults
[junit4] 2> 1256620 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.session Scavenging every 60ms
[junit4] 2> 1256620 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.h.ContextHandler Started
o.e.j.s.ServletContextHandler@5240ed22{/solr,null,AVAILABLE}
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.AbstractConnector Started ServerConnector@3d977647{SSL,[ssl,
http/1.1]}{127.0.0.1:46793}
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.e.j.s.Server Started @1258051ms
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr,
hostPort=46793}
[junit4] 2> 1256622 ERROR
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.a.s.u.StartupLoggingUtils Missing Java Option solr.log.dir. Logging may be
missing or incomplete.
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.a.s.s.SolrDispatchFilter ___ _ Welcome to Apache Solr™ version
7.3.1
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
o.a.s.s.SolrDispatchFilter / __| ___| |_ _ Starting in standalone mode on
port null
[junit4] 2> 1256622 INFO
(TEST-OpenCloseCoreStressTest.test5Seconds-seed#[8B8E9AD6B8CE747A]) []
[jira] [Commented] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464701#comment-16464701 ] Mark Miller commented on SOLR-12297: Oh nice, I was reading outdated Jetty 9 docs, the recent versions have built in support for SSL via Conscrypt. That's sweet. I think for protocol negotiation to run Http1.1 and Http2 on the same port probably still requires the alpn stuff, which means either Java 9 and passing a startup arg pointing to the boot jar. > Create a good SolrClient for SolrCloud paving the way for async requests, > HTTP2, multiplexing, and the latest & greatest Jetty features. > > > Key: SOLR-12297 > URL: https://issues.apache.org/jira/browse/SOLR-12297 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > Blocking or async support as well as HTTP2 compatible with multiplexing. > Once it supports enough and is stable, replace internal usage, allowing > async, and eventually move to HTTP2 connector and allow multiplexing. Could > support HTTP1.1 and HTTP2 on different ports depending on state of the world > then. > The goal of the client itself is to work against HTTP1.1 or HTTP2 with > minimal or no code path differences and the same for async requests (should > initially work for both 1.1 and 2 and share majority of code). > The client should also be able to replace HttpSolrClient and plug into the > other clients the same way. > I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually > though. > I evaluated some clients and while there are a few options, I went with > Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5 > beta) and we would have to update to a new API for Apache HttpClient anyway. > Meanwhile, the Jetty guys have been very supportive of helping Solr with any > issues and I like having the client and server from the same project. -- 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-11453) Create separate logger for slow requests
[ https://issues.apache.org/jira/browse/SOLR-11453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464689#comment-16464689 ] Ralph Goers commented on SOLR-11453: If you want to have a configuration that is only enabled under special circumstances you can use the RoutingAppender - http://logging.apache.org/log4j/2.x/manual/appenders.html#RoutingAppender or the ScriptAppenderSelector - http://logging.apache.org/log4j/2.x/manual/appenders.html#ScriptAppenderSelector. If those don't fit the bill make a suggestion for how you would like it to work. > Create separate logger for slow requests > > > Key: SOLR-11453 > URL: https://issues.apache.org/jira/browse/SOLR-11453 > Project: Solr > Issue Type: Improvement > Components: logging >Affects Versions: 7.0.1 >Reporter: Shawn Heisey >Assignee: Shawn Heisey >Priority: Minor > Attachments: SOLR-11453.patch, SOLR-11453.patch, SOLR-11453.patch > > > There is some desire on the mailing list to create a separate logfile for > slow queries. Currently it is not possible to do this cleanly, because the > WARN level used by slow query logging within the SolrCore class is also used > for other events that SolrCore can log. Those messages would be out of place > in a slow query log. They should typically stay in main solr logfile. > I propose creating a custom logger for slow queries, similar to what has been > set up for request logging. In the SolrCore class, which is > org.apache.solr.core.SolrCore, there is a special logger at > org.apache.solr.core.SolrCore.Request. This is not a real class, just a > logger which makes it possible to handle those log messages differently than > the rest of Solr's logging. I propose setting up another custom logger > within SolrCore which could be org.apache.solr.core.SolrCore.SlowRequest. -- 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-NightlyTests-7.3 - Build # 21 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/21/ 3 tests failed. FAILED: org.apache.lucene.index.TestBinaryDocValuesUpdates.testTonsOfUpdates Error Message: _3_4.fnm Stack Trace: java.io.FileNotFoundException: _3_4.fnm at __randomizedtesting.SeedInfo.seed([44891BA4A58B78F8:3CACC5AF47AB571A]:0) at org.apache.lucene.store.RAMDirectory.openInput(RAMDirectory.java:243) at org.apache.lucene.store.Directory.openChecksumInput(Directory.java:119) at org.apache.lucene.store.RawDirectoryWrapper.openChecksumInput(RawDirectoryWrapper.java:41) at org.apache.lucene.codecs.lucene60.Lucene60FieldInfosFormat.read(Lucene60FieldInfosFormat.java:113) at org.apache.lucene.index.SegmentReader.initFieldInfos(SegmentReader.java:190) at org.apache.lucene.index.SegmentReader.(SegmentReader.java:93) at org.apache.lucene.index.ReadersAndUpdates.writeFieldUpdates(ReadersAndUpdates.java:688) at org.apache.lucene.index.IndexWriter$ReaderPool.writeSomeDocValuesUpdates(IndexWriter.java:705) at org.apache.lucene.index.FrozenBufferedUpdates.apply(FrozenBufferedUpdates.java:331) at org.apache.lucene.index.DocumentsWriter$ResolveUpdatesEvent.process(DocumentsWriter.java:740) at org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5106) at org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5096) at org.apache.lucene.index.IndexWriter.updateDocValues(IndexWriter.java:1891) at org.apache.lucene.index.TestBinaryDocValuesUpdates.testTonsOfUpdates(TestBinaryDocValuesUpdates.java:1323) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
[jira] [Commented] (SOLR-12313) TestInjection#waitForInSyncWithLeader needs improvement.
[ https://issues.apache.org/jira/browse/SOLR-12313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464684#comment-16464684 ] Mark Miller commented on SOLR-12313: Okay, I see, the uncommitted changes check is needed for the tlog replica type. I think it's just the version check not matching our replication check that may be the issue. > TestInjection#waitForInSyncWithLeader needs improvement. > > > Key: SOLR-12313 > URL: https://issues.apache.org/jira/browse/SOLR-12313 > Project: Solr > Issue Type: Test > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Priority: Major > > This really should have some doc for why it would be used. > I also think it causes BasicDistributedZkTest to take forever for sometimes > and perhaps other tests? > I think checking for uncommitted data is probably a race condition and should > be removed. > Checking index versions should follow the rules that replication does - if > the slave is higher than the leader, it's in sync, being equal is not > required. If it's expected for a test it should be a specific test that > fails. This just introduces massive delays. -- 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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16464683#comment-16464683
]
Munendra S N commented on SOLR-12303:
-
[^SOLR-12303.patch]
Same issue exists for solrCloud too.
Now, I have added the qt override test for the distributed subquery. Currently,
parent handler inheritance test is not added for distributed mode(As it is
similar to the standalone mode)
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-12303:
Attachment: SOLR-12303.patch
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
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 # 1840 - Still Failing!
Error processing tokens: Error while parsing action 'Text/ZeroOrMore/FirstOf/Token/DelimitedToken/DelimitedToken_Action3' at input position (line 79, pos 4): )"} ^ java.lang.OutOfMemoryError: Java heap space - 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 # 21959 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21959/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
4 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration
Error Message:
did not finish processing in time
Stack Trace:
java.lang.AssertionError: did not finish processing in time
at
__randomizedtesting.SeedInfo.seed([69C528660A3DC88A:3A7C6AD6E82C5D70]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration
Error Message:
last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
"replicationFactor":"2", "pullReplicas":"0",
"router":{"name":"compositeId"},
