[jira] [Commented] (LUCENE-6435) java.util.ConcurrentModificationException: Removal from the cache failed error in SimpleNaiveBayesClassifier
[
https://issues.apache.org/jira/browse/LUCENE-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14940825#comment-14940825
]
Chang KaiShin commented on LUCENE-6435:
---
Good to hear the problem solved!
> java.util.ConcurrentModificationException: Removal from the cache failed
> error in SimpleNaiveBayesClassifier
>
>
> Key: LUCENE-6435
> URL: https://issues.apache.org/jira/browse/LUCENE-6435
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/classification
>Affects Versions: 5.1
>Reporter: Tommaso Teofili
>Assignee: Tommaso Teofili
> Fix For: Trunk, 6.0
>
> Attachments: LUCENE-6435.patch, patch.rtf
>
>
> While using {{SimpleNaiveBayesClassifier}} on a very large index (all Italian
> Wikipedia articles) I see the following code triggering a
> {{ConcurrentModificationException}} when evicting the {{Query}} from the
> {{LRUCache}}.
> {code}
> BooleanQuery booleanQuery = new BooleanQuery();
> BooleanQuery subQuery = new BooleanQuery();
> for (String textFieldName : textFieldNames) {
> subQuery.add(new BooleanClause(new TermQuery(new Term(textFieldName,
> word)), BooleanClause.Occur.SHOULD));
> }
> booleanQuery.add(new BooleanClause(subQuery, BooleanClause.Occur.MUST));
> booleanQuery.add(new BooleanClause(new TermQuery(new Term(classFieldName,
> c)), BooleanClause.Occur.MUST));
> //...
> TotalHitCountCollector totalHitCountCollector = new
> TotalHitCountCollector();
> indexSearcher.search(booleanQuery, totalHitCountCollector);
> return totalHitCountCollector.getTotalHits();
> {code}
> this is the complete stacktrace:
> {code}
> java.util.ConcurrentModificationException: Removal from the cache failed!
> This is probably due to a query which has been modified after having been put
> into the cache or a badly implemented clone(). Query class: [class
> org.apache.lucene.search.BooleanQuery], query: [#text:panoram #cat:1356]
> at
> __randomizedtesting.SeedInfo.seed([B6513DEC3681FEF5:138235BE33532634]:0)
> at
> org.apache.lucene.search.LRUQueryCache.evictIfNecessary(LRUQueryCache.java:285)
> at
> org.apache.lucene.search.LRUQueryCache.putIfAbsent(LRUQueryCache.java:268)
> at
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:569)
> at
> org.apache.lucene.search.ConstantScoreWeight.scorer(ConstantScoreWeight.java:82)
> at org.apache.lucene.search.Weight.bulkScorer(Weight.java:137)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:560)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:367)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.getWordFreqForClass(SimpleNaiveBayesClassifier.java:288)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.calculateLogLikelihood(SimpleNaiveBayesClassifier.java:248)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClassNormalizedList(SimpleNaiveBayesClassifier.java:169)
> at
> org.apache.lucene.classification.SimpleNaiveBayesClassifier.assignClass(SimpleNaiveBayesClassifier.java:125)
> at
> org.apache.lucene.classification.WikipediaTest.testItalianWikipedia(WikipediaTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
> at
>
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941212#comment-14941212 ] ASF subversion and git services commented on SOLR-8085: --- Commit 1706423 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1706423 ] SOLR-8085: Fix a variety of issues that can result in replicas getting out of sync. > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b78) - Build # 14380 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14380/ Java: 32bit/jdk1.9.0-ea-b78 -client -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: Captured an uncaught exception in thread: Thread[id=545, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=545, name=RecoveryThread-source_collection_shard1_replica2, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] at __randomizedtesting.SeedInfo.seed([3FE60AB6FDCBDCC5:98A2B2129070CF7C]:0) Caused by: org.apache.solr.common.cloud.ZooKeeperException: at __randomizedtesting.SeedInfo.seed([3FE60AB6FDCBDCC5]:0) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:234) Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_3FE60AB6FDCBDCC5-001/jetty-002/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1513923944398192640 (No such file or directory) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244) at org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173) at org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610) at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877) at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:526) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:227) Caused by: java.io.FileNotFoundException: /home/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_3FE60AB6FDCBDCC5-001/jetty-002/cores/source_collection_shard1_replica2/data/tlog/tlog.007.1513923944398192640 (No such file or directory) at java.io.RandomAccessFile.open0(Native Method) at java.io.RandomAccessFile.open(RandomAccessFile.java:327) at java.io.RandomAccessFile.(RandomAccessFile.java:243) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236) ... 7 more FAILED: org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking Error Message: Shard a1x2_shard1_replica1 received all 10 requests Stack Trace: java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests at __randomizedtesting.SeedInfo.seed([3FE60AB6FDCBDCC5:77DA537609C0CD53]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:109) 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:504) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (LUCENE-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941139#comment-14941139
]
Michael McCandless commented on LUCENE-6664:
bq. Could this be a candidate for 6.0 (breaking back-compat)?
Probably not ... I think [~rcmuir]'s objections would still hold for 6.0 as
well?
The patch is fairly standalone so you could just use this new token filter
({{SynonymGraphFilter}}) in your own world?
> Replace SynonymFilter with SynonymGraphFilter
> -
>
> Key: LUCENE-6664
> URL: https://issues.apache.org/jira/browse/LUCENE-6664
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
> LUCENE-6664.patch, usa.png, usa_flat.png
>
>
> Spinoff from LUCENE-6582.
> I created a new SynonymGraphFilter (to replace the current buggy
> SynonymFilter), that produces correct graphs (does no "graph
> flattening" itself). I think this makes it simpler.
> This means you must add the FlattenGraphFilter yourself, if you are
> applying synonyms during indexing.
> Index-time syn expansion is a necessarily "lossy" graph transformation
> when multi-token (input or output) synonyms are applied, because the
> index does not store {{posLength}}, so there will always be phrase
> queries that should match but do not, and then phrase queries that
> should not match but do.
> http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
> goes into detail about this.
> However, with this new SynonymGraphFilter, if instead you do synonym
> expansion at query time (and don't do the flattening), and you use
> TermAutomatonQuery (future: somehow integrated into a query parser),
> or maybe just "enumerate all paths and make union of PhraseQuery", you
> should get 100% correct matches (not sure about "proper" scoring
> though...).
> This new syn filter still cannot consume an arbitrary graph.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8116) SearchGroupsResultTransformer tweaks
Christine Poerschke created SOLR-8116: - Summary: SearchGroupsResultTransformer tweaks Key: SOLR-8116 URL: https://issues.apache.org/jira/browse/SOLR-8116 Project: Solr Issue Type: Wish Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor SearchGroupsResultTransformer tweaks (String literals, NamedList and Map initialCapacity) - patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-8115) On query timeout, casting error (...ResultContext cannot be cast to ...SolrDocumentList)
[
https://issues.apache.org/jira/browse/SOLR-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Cautaerts closed SOLR-8115.
---
Resolution: Duplicate
As Markus Jelsma noticed, this is a duplicate of SOLR7864. Sorry, I hadn't
found it!
Thanks,
> On query timeout, casting error (...ResultContext cannot be cast to
> ...SolrDocumentList)
>
>
> Key: SOLR-8115
> URL: https://issues.apache.org/jira/browse/SOLR-8115
> Project: Solr
> Issue Type: Bug
> Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04 with Java 1.8.0.60
> Using solR in non-distributed, non Cloud mode.
>Reporter: Vincent Cautaerts
>Priority: Minor
>
> When making a query, and hitting a timeout, solR throws an error
> "org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList"
> This is display in solrJ log files. No mention of a timeout can be seen here.
> When searching in server log files, just before that error, I find this
> message (WARN):
> The request took too long to iterate over terms.
> It seems that in case of an exception, the value of
> rb.rsp.getValues().get("response");
> is not a SolrDocumentList, but a ResultContext. And therefore the cast at
> line 297 of SearchHandler fails, and an erroneous error message (...) is
> output.
> the problem is not the timeout, but the fact that a timeout gives a casting
> exception, instead of a timeout exeption. This makes finding the origin of
> the problem hard (and impossible if looking only at the logs on the client
> side).
> Note: complete stack trace:
> 2015-10-02 07:07:49,523 ERROR
> [qtp1192108080-22][org.apache.solr.common.SolrException] (core.SolrCore:139)
> - java.lang.ClassCastEx
> ception: org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:297)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8116) SearchGroupsResultTransformer tweaks
[ https://issues.apache.org/jira/browse/SOLR-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-8116: -- Attachment: SOLR-8116.patch proposed patch against trunk > SearchGroupsResultTransformer tweaks > > > Key: SOLR-8116 > URL: https://issues.apache.org/jira/browse/SOLR-8116 > Project: Solr > Issue Type: Wish >Reporter: Christine Poerschke >Assignee: Christine Poerschke >Priority: Minor > Attachments: SOLR-8116.patch > > > SearchGroupsResultTransformer tweaks (String literals, NamedList and Map > initialCapacity) - patch to follow -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7495) Unexpected docvalues type NUMERIC when grouping by a int facet
[
https://issues.apache.org/jira/browse/SOLR-7495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941011#comment-14941011
]
Spyros Kapnissis commented on SOLR-7495:
Same error with 5.3.1. Changing the grouping field to string type as mentioned
above temporarily resolved the issue for me.
> Unexpected docvalues type NUMERIC when grouping by a int facet
> --
>
> Key: SOLR-7495
> URL: https://issues.apache.org/jira/browse/SOLR-7495
> Project: Solr
> Issue Type: Bug
>Affects Versions: 5.0, 5.1, 5.2, 5.3
>Reporter: Fabio Batista da Silva
> Attachments: SOLR-7495.patch
>
>
> Hey All,
> After upgrading from solr 4.10 to 5.1 with solr could
> I'm getting a IllegalStateException when i try to facet a int field.
> IllegalStateException: unexpected docvalues type NUMERIC for field 'year'
> (expected=SORTED). Use UninvertingReader or index with docvalues.
> schema.xml
> {code}
>
>
>
>
>
>
> multiValued="false" required="true"/>
> multiValued="false" required="true"/>
>
>
> stored="true"/>
>
>
>
> />
> sortMissingLast="true"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> precisionStep="0" positionIncrementGap="0"/>
> positionIncrementGap="0"/>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> positionIncrementGap="100">
>
>
> words="stopwords.txt" />
>
> maxGramSize="15"/>
>
>
>
> words="stopwords.txt" />
> synonyms="synonyms.txt" ignoreCase="true" expand="true"/>
>
>
>
> class="solr.SpatialRecursivePrefixTreeFieldType" geo="true"
> distErrPct="0.025" maxDistErr="0.09" units="degrees" />
>
> id
> name
>
>
> {code}
> query :
> {code}
> http://solr.dev:8983/solr/my_collection/select?wt=json=id=index_type:foobar=true=year_make_model=true=true=year
> {code}
> Exception :
> {code}
> ull:org.apache.solr.common.SolrException: Exception during facet.field: year
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:627)
> at org.apache.solr.request.SimpleFacets$3.call(SimpleFacets.java:612)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.apache.solr.request.SimpleFacets$2.execute(SimpleFacets.java:566)
> at
> org.apache.solr.request.SimpleFacets.getFacetFieldCounts(SimpleFacets.java:637)
> at
> org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:280)
> at
> org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:106)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:222)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1984)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:829)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:446)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:220)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
> at
>
[jira] [Created] (SOLR-8114) Grouping.java: sort variable names confusion
Christine Poerschke created SOLR-8114:
-
Summary: Grouping.java: sort variable names confusion
Key: SOLR-8114
URL: https://issues.apache.org/jira/browse/SOLR-8114
Project: Solr
Issue Type: Wish
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
The undistributed case i.e. {{solr/Grouping.java}}'s variable names confusingly
differ from the names used by lucene (and by the distributed case).
Specifically the name {{groupSort}} in lucene (and in the distributed case)
means between-groups-sort but in the Grouping.java it means within-group-sort.
lucene:
{code}
TermFirstPassGroupingCollector(... Sort groupSort ...)
TermSecondPassGroupingCollector(... Sort groupSort, Sort withinGroupSort ...)
{code}
solr:
{code}
SearchGroupsFieldCommand.java: firstPassGroupingCollector = new
TermFirstPassGroupingCollector(field.getName(), groupSort, topNGroups);
TopGroupsFieldCommand.java: secondPassCollector = new
TermSecondPassGroupingCollector(... groupSort, sortWithinGroup ...);
Grouping.java:public Sort groupSort; // the sort of the documents
*within* a single group.
Grouping.java:public Sort sort;// the sort between groups
Grouping.java: firstPass = new TermFirstPassGroupingCollector(groupBy, sort,
actualGroupsToFind);
Grouping.java: secondPass = new TermSecondPassGroupingCollector(... sort,
groupSort ...);
{code}
This JIRA proposes to rename the Grouping.java variables to remove the
confusion:
* part 1: in Grouping.java rename groupSort to withinGroupSort
* part 2: in Grouping.java rename sort to groupSort
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8115) On query timeout, casting error (...ResultContext cannot be cast to ...SolrDocumentList)
[
https://issues.apache.org/jira/browse/SOLR-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Cautaerts updated SOLR-8115:
Environment:
Ubuntu 14.04 with Java 1.8.0.60
Using solR in non-distributed, non Cloud mode.
was:Ubuntu 14.04 with Java 1.8.0.60
> On query timeout, casting error (...ResultContext cannot be cast to
> ...SolrDocumentList)
>
>
> Key: SOLR-8115
> URL: https://issues.apache.org/jira/browse/SOLR-8115
> Project: Solr
> Issue Type: Bug
> Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04 with Java 1.8.0.60
> Using solR in non-distributed, non Cloud mode.
>Reporter: Vincent Cautaerts
>Priority: Minor
>
> When making a query, and hitting a timeout, solR throws an error
> "org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList"
> This is display in solrJ log files. No mention of a timeout can be seen here.
> When searching in server log files, just before that error, I find this
> message (WARN):
> The request took too long to iterate over terms.
> It seems that in case of an exception, the value of
> rb.rsp.getValues().get("response");
> is not a SolrDocumentList, but a ResultContext. And therefore the cast at
> line 297 of SearchHandler fails, and an erroneous error message (...) is
> output.
> the problem is not the timeout, but the fact that a timeout gives a casting
> exception, instead of a timeout exeption. This makes finding the origin of
> the problem hard (and impossible if looking only at the logs on the client
> side).
> Note: complete stack trace:
> 2015-10-02 07:07:49,523 ERROR
> [qtp1192108080-22][org.apache.solr.common.SolrException] (core.SolrCore:139)
> - java.lang.ClassCastEx
> ception: org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:297)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8115) On query timeout, casting error (...ResultContext cannot be cast to ...SolrDocumentList)
[
https://issues.apache.org/jira/browse/SOLR-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Cautaerts updated SOLR-8115:
Environment: Ubuntu 14.04 with Java 1.8.0.60 (was: Ubuntu 14.04 with Java
1.8.60)
> On query timeout, casting error (...ResultContext cannot be cast to
> ...SolrDocumentList)
>
>
> Key: SOLR-8115
> URL: https://issues.apache.org/jira/browse/SOLR-8115
> Project: Solr
> Issue Type: Bug
> Components: Server
>Affects Versions: 5.3.1
> Environment: Ubuntu 14.04 with Java 1.8.0.60
>Reporter: Vincent Cautaerts
>Priority: Minor
>
> When making a query, and hitting a timeout, solR throws an error
> "org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList"
> This is display in solrJ log files. No mention of a timeout can be seen here.
> When searching in server log files, just before that error, I find this
> message (WARN):
> The request took too long to iterate over terms.
> It seems that in case of an exception, the value of
> rb.rsp.getValues().get("response");
> is not a SolrDocumentList, but a ResultContext. And therefore the cast at
> line 297 of SearchHandler fails, and an erroneous error message (...) is
> output.
> the problem is not the timeout, but the fact that a timeout gives a casting
> exception, instead of a timeout exeption. This makes finding the origin of
> the problem hard (and impossible if looking only at the logs on the client
> side).
> Note: complete stack trace:
> 2015-10-02 07:07:49,523 ERROR
> [qtp1192108080-22][org.apache.solr.common.SolrException] (core.SolrCore:139)
> - java.lang.ClassCastEx
> ception: org.apache.solr.response.ResultContext cannot be cast to
> org.apache.solr.common.SolrDocumentList
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:297)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:499)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-5.x - Build # 973 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/973/ 2 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test Error Message: Error from server at http://127.0.0.1:34287: Could not load collection from ZK:halfcollectionblocker Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:34287: Could not load collection from ZK:halfcollectionblocker at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:302) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:419) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at
[jira] [Updated] (SOLR-8114) Grouping.java: sort variable names confusion
[
https://issues.apache.org/jira/browse/SOLR-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-8114:
--
Attachment: SOLR-8114-part2of2.patch
SOLR-8114-part1of2.patch
proposed patches (against trunk)
> Grouping.java: sort variable names confusion
>
>
> Key: SOLR-8114
> URL: https://issues.apache.org/jira/browse/SOLR-8114
> Project: Solr
> Issue Type: Wish
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-8114-part1of2.patch, SOLR-8114-part2of2.patch
>
>
> The undistributed case i.e. {{solr/Grouping.java}}'s variable names
> confusingly differ from the names used by lucene (and by the distributed
> case).
> Specifically the name {{groupSort}} in lucene (and in the distributed case)
> means between-groups-sort but in the Grouping.java it means within-group-sort.
> lucene:
> {code}
> TermFirstPassGroupingCollector(... Sort groupSort ...)
> TermSecondPassGroupingCollector(... Sort groupSort, Sort withinGroupSort ...)
> {code}
> solr:
> {code}
> SearchGroupsFieldCommand.java: firstPassGroupingCollector = new
> TermFirstPassGroupingCollector(field.getName(), groupSort, topNGroups);
> TopGroupsFieldCommand.java: secondPassCollector = new
> TermSecondPassGroupingCollector(... groupSort, sortWithinGroup ...);
> Grouping.java:public Sort groupSort; // the sort of the documents
> *within* a single group.
> Grouping.java:public Sort sort;// the sort between groups
> Grouping.java: firstPass = new TermFirstPassGroupingCollector(groupBy, sort,
> actualGroupsToFind);
> Grouping.java: secondPass = new TermSecondPassGroupingCollector(... sort,
> groupSort ...);
> {code}
> This JIRA proposes to rename the Grouping.java variables to remove the
> confusion:
> * part 1: in Grouping.java rename groupSort to withinGroupSort
> * part 2: in Grouping.java rename sort to groupSort
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (64bit/jdk1.9.0-ea-b78) - Build # 14379 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14379/ Java: 64bit/jdk1.9.0-ea-b78 -XX:-UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestSolrCloudWithKerberosAlt Error Message: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=10455, name=changePwdReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:746)2) Thread[id=10457, name=groupCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:746)3) Thread[id=10454, name=apacheds, state=WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:516) at java.util.TimerThread.mainLoop(Timer.java:526) at java.util.TimerThread.run(Timer.java:505)4) Thread[id=10458, name=ou=system.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:746)5) Thread[id=10456, name=kdcReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093) at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:746) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestSolrCloudWithKerberosAlt: 1) Thread[id=10455, name=changePwdReplayCache.data, state=TIMED_WAITING, group=TGRP-TestSolrCloudWithKerberosAlt] at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078) at
[jira] [Created] (SOLR-8115) On query timeout, casting error (...ResultContext cannot be cast to ...SolrDocumentList)
Vincent Cautaerts created SOLR-8115:
---
Summary: On query timeout, casting error (...ResultContext cannot
be cast to ...SolrDocumentList)
Key: SOLR-8115
URL: https://issues.apache.org/jira/browse/SOLR-8115
Project: Solr
Issue Type: Bug
Components: Server
Affects Versions: 5.3.1
Environment: Ubuntu 14.04 with Java 1.8.60
Reporter: Vincent Cautaerts
Priority: Minor
When making a query, and hitting a timeout, solR throws an error
"org.apache.solr.response.ResultContext cannot be cast to
org.apache.solr.common.SolrDocumentList"
This is display in solrJ log files. No mention of a timeout can be seen here.
When searching in server log files, just before that error, I find this message
(WARN):
The request took too long to iterate over terms.
It seems that in case of an exception, the value of
rb.rsp.getValues().get("response");
is not a SolrDocumentList, but a ResultContext. And therefore the cast at line
297 of SearchHandler fails, and an erroneous error message (...) is output.
the problem is not the timeout, but the fact that a timeout gives a casting
exception, instead of a timeout exeption. This makes finding the origin of the
problem hard (and impossible if looking only at the logs on the client side).
Note: complete stack trace:
2015-10-02 07:07:49,523 ERROR
[qtp1192108080-22][org.apache.solr.common.SolrException] (core.SolrCore:139) -
java.lang.ClassCastEx
ception: org.apache.solr.response.ResultContext cannot be cast to
org.apache.solr.common.SolrDocumentList
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:297)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator
[ https://issues.apache.org/jira/browse/LUCENE-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated LUCENE-6823: - Attachment: LUCENE-6823.patch Updated patch. > Remove use of System.currentTimeMillis() from LocalReplicator > - > > Key: LUCENE-6823 > URL: https://issues.apache.org/jira/browse/LUCENE-6823 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ishan Chattopadhyaya >Priority: Minor > Attachments: LUCENE-6823.patch, LUCENE-6823.patch > > > LocalReplicator uses System.currentTimeMillis() for session expiry, which is > not guaranteed monotonic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator
[
https://issues.apache.org/jira/browse/LUCENE-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941292#comment-14941292
]
Ishan Chattopadhyaya commented on LUCENE-6823:
--
Thanks for the pointer, [~steve_rowe]. I copied it from
ControlledRealTimeReopenThread's line 179:
{noformat}
long startMS = System.nanoTime()/100;
{noformat}
I'll add another patch.
> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is
> not guaranteed monotonic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941316#comment-14941316
]
Mark Miller commented on SOLR-7746:
---
FY on the CHANGES.txt entry for this one:
{noformat}
SOLR-7746: Ping requests stopped working with distrib=true in Solr 5.2.1.
(Michael Sun)
{noformat}
It should read:
{noformat}
SOLR-7746: Ping requests stopped working with distrib=true in Solr 5.2.1.
(Alexey Serba, Michael Sun via Greg Chanan)
{noformat}
Reporter always gets credit and if committer didn't really contribute we use
the via credit.
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch,
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE=test2=2=1=2=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json=true=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941216#comment-14941216 ] Mark Miller commented on SOLR-8085: --- I also have a test change we may need to prevent false fails - I'll spin that off into it's own issue. > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941215#comment-14941215 ] ASF subversion and git services commented on SOLR-8085: --- Commit 1706424 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1706424 ] SOLR-8085: Fix a variety of issues that can result in replicas getting out of sync. > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-8085. --- Resolution: Fixed > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6823) Remove use of System.currentTimeMillis() from LocalReplicator
[
https://issues.apache.org/jira/browse/LUCENE-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941283#comment-14941283
]
Steve Rowe commented on LUCENE-6823:
[~ichattopadhyaya], it's better to convert between time units using
{{TimeUnit.TARGETUNIT.convert(sourceDuration, TimeUnit.SOURCEUNIT)}}, rather
than using hard-coded conversion constants, which could be accidentally wrong.
E.g. to convert from nanos to millis:
{{TimeUnit.MILLISECONDS.convert(nanoseconds, TimeUnit.NANOSECONDS)}}.
> Remove use of System.currentTimeMillis() from LocalReplicator
> -
>
> Key: LUCENE-6823
> URL: https://issues.apache.org/jira/browse/LUCENE-6823
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Ishan Chattopadhyaya
>Priority: Minor
> Attachments: LUCENE-6823.patch
>
>
> LocalReplicator uses System.currentTimeMillis() for session expiry, which is
> not guaranteed monotonic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60) - Build # 14382 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14382/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> https://127.0.0.1:44818/puwf/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> https://127.0.0.1:58743/puwf/collection1/: An exception has occurred on the server, refer to server log for details. Stack Trace: java.io.IOException: --> https://127.0.0.1:44818/puwf/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> https://127.0.0.1:58743/puwf/collection1/: An exception has occurred on the server, refer to server log for details. at __randomizedtesting.SeedInfo.seed([1770F0E01B63BAD4:B034484476D8A96D]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:178) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:1317) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:232) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:96) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941432#comment-14941432
]
Judith Silverman commented on SOLR-6203:
Hello, all. I have created a patch based on Hoss Man's advice. I added some
unit tests and tested in my company's dev environment but have not tested with
live traffic. I will upload the patch along with a README file summarizing the
changes.
This is my first patch; apologies in advance if I am doing something wrong, but
please let me know!
Thanks,
Judith
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nathan Dire
> Attachments: README, SOLR-6203-unittest.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Judith Silverman updated SOLR-6203:
---
Attachment: SOLR-6203.patch
README
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nathan Dire
> Attachments: README, SOLR-6203-unittest.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941441#comment-14941441
]
Judith Silverman commented on SOLR-6203:
Hello, all. I have created a patch based on Hoss Man's advice. I added some
unit tests and tested in my company's dev environment but have not tested with
live traffic. I will upload the patch along with a README file summarizing the
changes.
This is my first patch; apologies in advance if I am doing something wrong, but
please let me know!
Thanks,
Judith
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nathan Dire
> Attachments: README, SOLR-6203-unittest.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941482#comment-14941482 ] Joel Bernstein edited comment on SOLR-8086 at 10/2/15 6:00 PM: --- Initial patch with one passing test for the Map/Reduce implementation. More unit tests coming. was (Author: joel.bernstein): Initial patch with one passing test for Map/Reduce implementation. More unit tests coming. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8086: - Attachment: SOLR-8086.patch Initial patch with one passing test for Map/Reduce implementation. More unit tests coming. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941394#comment-14941394
]
Gregory Chanan commented on SOLR-7746:
--
Thanks Mark, both the "via" and reporter points make sense. Should I go back
and update the CHANGES.txt?
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch,
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE=test2=2=1=2=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json=true=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (SOLR-6203) cast exception while searching with sort function and result grouping
[
https://issues.apache.org/jira/browse/SOLR-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Judith Silverman updated SOLR-6203:
---
Comment: was deleted
(was: Hello, all. I have created a patch based on Hoss Man's advice. I added
some unit tests and tested in my company's dev environment but have not tested
with live traffic. I will upload the patch along with a README file
summarizing the changes.
This is my first patch; apologies in advance if I am doing something wrong, but
please let me know!
Thanks,
Judith
)
> cast exception while searching with sort function and result grouping
> -
>
> Key: SOLR-6203
> URL: https://issues.apache.org/jira/browse/SOLR-6203
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 4.7, 4.8
>Reporter: Nathan Dire
> Attachments: README, SOLR-6203-unittest.patch, SOLR-6203.patch
>
>
> After upgrading from 4.5.1 to 4.7+, a schema including a {{"*"}} dynamic
> field as text gets a cast exception when using a sort function and result
> grouping.
> Repro (with example config):
> # Add {{"*"}} dynamic field as a {{TextField}}, eg:
> {noformat}
>
> {noformat}
> # Create sharded collection
> {noformat}
> curl
> 'http://localhost:8983/solr/admin/collections?action=CREATE=test=2=2'
> {noformat}
> # Add example docs (query must have some results)
> # Submit query which sorts on a function result and uses result grouping:
> {noformat}
> {
> "responseHeader": {
> "status": 500,
> "QTime": 50,
> "params": {
> "sort": "sqrt(popularity) desc",
> "indent": "true",
> "q": "*:*",
> "_": "1403709010008",
> "group.field": "manu",
> "group": "true",
> "wt": "json"
> }
> },
> "error": {
> "msg": "java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef",
> "code": 500
> }
> }
> {noformat}
> Source exception from log:
> {noformat}
> ERROR - 2014-06-25 08:10:10.055; org.apache.solr.common.SolrException;
> java.lang.ClassCastException: java.lang.Double cannot be cast to
> org.apache.lucene.util.BytesRef
> at
> org.apache.solr.schema.FieldType.marshalStringSortValue(FieldType.java:981)
> at org.apache.solr.schema.TextField.marshalSortValue(TextField.java:176)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.serializeSearchGroup(SearchGroupsResultTransformer.java:125)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:65)
> at
> org.apache.solr.search.grouping.distributed.shardresultserializer.SearchGroupsResultTransformer.transform(SearchGroupsResultTransformer.java:43)
> at
> org.apache.solr.search.grouping.CommandHandler.processResult(CommandHandler.java:193)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:340)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> ...
> {noformat}
> It looks like {{serializeSearchGroup}} is matching the sort expression as the
> {{"*"}} dynamic field, which is a TextField in the repro.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941458#comment-14941458
]
Mark Miller commented on SOLR-7746:
---
Yeah, personally I think it's worth it for the reporter credit.
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch,
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE=test2=2=1=2=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json=true=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 92 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/92/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 2 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([24A02F6269CC2173:83E497C6047732CA]:0) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:285) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:96) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.update.processor.DocExpirationUpdateProcessorFactoryTest.testAutomaticDeletes Error Message:
[jira] [Updated] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8086: - Attachment: SOLR-8086.patch Added initial test for JSON Facet API implementation. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941582#comment-14941582 ] Joel Bernstein edited comment on SOLR-8086 at 10/2/15 7:11 PM: --- Added initial tests for JSON Facet API implementation. was (Author: joel.bernstein): Added initial test for JSON Facet API implementation. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14383 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14383/ Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([8F4E1B750AA4747C:280AA3D1671F67C5]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.8.0_60) - Build # 14095 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14095/ Java: 32bit/jdk1.8.0_60 -server -XX:+UseG1GC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: ERROR: SolrIndexSearcher opens=51 closes=50 Stack Trace: java.lang.AssertionError: ERROR: SolrIndexSearcher opens=51 closes=50 at __randomizedtesting.SeedInfo.seed([F6CCEEBA37AD7284]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:467) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:233) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at java.lang.Thread.run(Thread.java:745) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=7570, name=searcherExecutor-3392-thread-1, state=WAITING, group=TGRP-TestLazyCores] 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:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) Thread[id=7570, name=searcherExecutor-3392-thread-1, state=WAITING, group=TGRP-TestLazyCores] 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:1067) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at __randomizedtesting.SeedInfo.seed([F6CCEEBA37AD7284]:0) FAILED: junit.framework.TestSuite.org.apache.solr.core.TestLazyCores Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=7570,
[jira] [Updated] (SOLR-8117) Rule-based placement issue with 'cores' tag
[ https://issues.apache.org/jira/browse/SOLR-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ludovic Boutros updated SOLR-8117: -- Attachment: SOLR-8117.patch > Rule-based placement issue with 'cores' tag > > > Key: SOLR-8117 > URL: https://issues.apache.org/jira/browse/SOLR-8117 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.3, 5.3.1 >Reporter: Ludovic Boutros > Attachments: SOLR-8117.patch > > > The rule-based placement fails on an empty node (core count = 0) with > condition 'cores:<1'. > It also fails if current core number is equal to the core number in the > condition - 1. > During the placement strategy process, the core counts for a node are > incremented when all the rules match. > At the end of the code, an additional verification of all the conditions is > done (with incremented core count) and it fails. > I don't know why this condition is needed and removing it seems to fix the > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8086: - Attachment: SOLR-8086.patch Added tests with a simple WHERE clause. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch, SOLR-8086.patch, SOLR-8086.patch, > SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Solaris (multiarch/jdk1.7.0) - Build # 94 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Solaris/94/ Java: multiarch/jdk1.7.0 -d64 -XX:-UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest Error Message: There are still nodes recoverying - waited for 10 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 10 seconds at __randomizedtesting.SeedInfo.seed([5B364428C3BA988D:159531FBD261899D]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:836) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForThingsToLevelOut(AbstractFullDistribZkTestBase.java:1393) at org.apache.solr.security.TestAuthorizationFramework.authorizationFrameworkTest(TestAuthorizationFramework.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Created] (SOLR-8117) Rule-based placement issue with 'cores' tag
Ludovic Boutros created SOLR-8117: - Summary: Rule-based placement issue with 'cores' tag Key: SOLR-8117 URL: https://issues.apache.org/jira/browse/SOLR-8117 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.3, 5.3.1 Reporter: Ludovic Boutros The rule-based placement fails on an empty node (core count = 0) with condition 'cores:<1'. It also fails if current core number is equal to the core number in the condition - 1. During the placement strategy process, the core counts for a node are incremented when all the rules match. At the end of the code, an additional verification of all the conditions is done (with incremented core count) and it fails. I don't know why this condition is needed and removing it seems to fix the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8086) Add support for SELECT DISTINCT queries to the SQL interface
[ https://issues.apache.org/jira/browse/SOLR-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8086: - Attachment: SOLR-8086.patch More Map/Reduce implementation tests including parallel tests. Still need to add tests for the JSON Facet API. > Add support for SELECT DISTINCT queries to the SQL interface > > > Key: SOLR-8086 > URL: https://issues.apache.org/jira/browse/SOLR-8086 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Joel Bernstein > Attachments: SOLR-8086.patch, SOLR-8086.patch > > > This ticket will add the SELECT DISTINCT query to the SQL interface. > There will be a Map/Reduce implementation using the UniqueStream and a JSON > Facet API implementation using the FacetStream. SQL clients will be able to > switch between Map/Reduce and JSON Facet API using the *aggregationMode* > [map_reduce or facet] http param introduced in SOLR-7903. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8117) Rule-based placement issue with 'cores' tag
[ https://issues.apache.org/jira/browse/SOLR-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941733#comment-14941733 ] Ludovic Boutros commented on SOLR-8117: --- A patch with a test and the additional verification removed. The rule test and rule engine test pass. > Rule-based placement issue with 'cores' tag > > > Key: SOLR-8117 > URL: https://issues.apache.org/jira/browse/SOLR-8117 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.3, 5.3.1 >Reporter: Ludovic Boutros > Attachments: SOLR-8117.patch > > > The rule-based placement fails on an empty node (core count = 0) with > condition 'cores:<1'. > It also fails if current core number is equal to the core number in the > condition - 1. > During the placement strategy process, the core counts for a node are > incremented when all the rules match. > At the end of the code, an additional verification of all the conditions is > done (with incremented core count) and it fails. > I don't know why this condition is needed and removing it seems to fix the > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
Joel Bernstein created SOLR-8118: Summary: Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. Key: SOLR-8118 URL: https://issues.apache.org/jira/browse/SOLR-8118 Project: Solr Issue Type: Bug Reporter: Joel Bernstein -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8118: - Description: Today the TestSQLHandler test cases began failing. It turned out that they weren't calling waitForRecoveriesToFinish(false);. This ticket adds the method call to all the Streaming/SQL test cases. (was: Today the TestSQLHandler test cases began failing. It turned out that they weren't call waitForRecoveriesToFinish(false);. This ticket adds the call to all the Streaming/SQL test cases.) > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > > Today the TestSQLHandler test cases began failing. It turned out that they > weren't calling waitForRecoveriesToFinish(false);. This ticket adds the > method call to all the Streaming/SQL test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8118: - Description: Today the TestSQLHandler test cases began failing. It turned out that they weren't call waitForRecoveriesToFinish(false);. This ticket adds the call all the Streaming/SQL test cases. (was: Today the TestSQLHandler test cases began failing. It turned out that they weren't call wa) > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > > Today the TestSQLHandler test cases began failing. It turned out that they > weren't call waitForRecoveriesToFinish(false);. This ticket adds the call all > the Streaming/SQL test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8118: - Description: Today the TestSQLHandler test cases began failing. It turned out that they weren't call waitForRecoveriesToFinish(false);. This ticket adds the call to all the Streaming/SQL test cases. (was: Today the TestSQLHandler test cases began failing. It turned out that they weren't call waitForRecoveriesToFinish(false);. This ticket adds the call all the Streaming/SQL test cases.) > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > > Today the TestSQLHandler test cases began failing. It turned out that they > weren't call waitForRecoveriesToFinish(false);. This ticket adds the call to > all the Streaming/SQL test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941896#comment-14941896
]
ASF subversion and git services commented on SOLR-7746:
---
Commit 1706499 from gcha...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1706499 ]
SOLR-7746: Update credit in CHANGES.txt
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch,
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE=test2=2=1=2=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json=true=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941803#comment-14941803 ] Joel Bernstein commented on SOLR-8085: -- I think I'm using the wrong method to index documents and this ticket just exposed that. > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8118: - Description: Today the TestSQLHandler test cases began failing. It turned out that they weren't call wa > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > > Today the TestSQLHandler test cases began failing. It turned out that they > weren't call wa -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941887#comment-14941887 ] Joel Bernstein commented on SOLR-8118: -- Committed a fix for this but forgot the jira ticket number on the commit. The commit was: http://svn.apache.org/viewvc?view=revision=1706497 > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14384 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14384/ Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:58687/_qxs/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:36616/_qxs/collection1/: An exception has occurred on the server, refer to server log for details. Stack Trace: java.io.IOException: --> http://127.0.0.1:58687/_qxs/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:36616/_qxs/collection1/: An exception has occurred on the server, refer to server log for details. at __randomizedtesting.SeedInfo.seed([CB2E2824C5796AD4:6C6A9080A8C2796D]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:178) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:1317) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:232) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:96) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941841#comment-14941841 ] Joel Bernstein commented on SOLR-8085: -- Ok, the issue was that I wasn't calling: waitForRecoveriesToFinish(false); Once I added this the test passes. > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-8118: - Summary: Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. (was: Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.) > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7995) Add a LIST command to ConfigSets API
[ https://issues.apache.org/jira/browse/SOLR-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7995: - Attachment: SOLR-7995.patch Here's a patch that implements this. Following SOLR-7049, the processing is done in the handler rather than the overseer. > Add a LIST command to ConfigSets API > > > Key: SOLR-7995 > URL: https://issues.apache.org/jira/browse/SOLR-7995 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7995.patch > > > It would be useful to have a LIST command in the ConfigSets API so that > clients do not have to access zookeeper in order to get the ConfigSets to use > for the other operations (create, delete). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8085) Fix a variety of issues that can result in replicas getting out of sync.
[ https://issues.apache.org/jira/browse/SOLR-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941771#comment-14941771 ] Joel Bernstein commented on SOLR-8085: -- [~markrmil...@gmail.com], I'm getting errors in the TestSQLHandler test cases, which extends AbstractFullDistribZkTestBase, following this commit. In the test case it looks like one of the shards is not having documents added to it. Still investigating... > Fix a variety of issues that can result in replicas getting out of sync. > > > Key: SOLR-8085 > URL: https://issues.apache.org/jira/browse/SOLR-8085 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Critical > Fix For: Trunk, 5.4 > > Attachments: SOLR-8085.patch, SOLR-8085.patch, SOLR-8085.patch, > fail.150922_125320, fail.150922_130608 > > > I've been discussing this fail I found with Yonik. > The problem seems to be that a replica tries to recover and publishes > recovering - the attempt then fails, but docs are now coming in from the > leader. The replica tries to recover again and has gotten enough docs to pass > peery sync. > I'm trying a possible solution now where we won't allow peer sync after a > recovery that is not successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_60) - Build # 5300 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5300/ Java: 32bit/jdk1.8.0_60 -client -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:52089/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:52137/collection1/: An exception has occurred on the server, refer to server log for details. Stack Trace: java.io.IOException: --> http://127.0.0.1:52089/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:52137/collection1/: An exception has occurred on the server, refer to server log for details. at __randomizedtesting.SeedInfo.seed([895F0EA26B806F0C:2E1BB606063B7CB5]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:178) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:1317) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:232) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:96) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[jira] [Commented] (SOLR-7746) Ping requests stopped working with distrib=true in Solr 5.2.1
[
https://issues.apache.org/jira/browse/SOLR-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941908#comment-14941908
]
ASF subversion and git services commented on SOLR-7746:
---
Commit 1706502 from gcha...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1706502 ]
SOLR-7746: Update credit in CHANGES.txt
> Ping requests stopped working with distrib=true in Solr 5.2.1
> -
>
> Key: SOLR-7746
> URL: https://issues.apache.org/jira/browse/SOLR-7746
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Alexey Serba
>Assignee: Gregory Chanan
> Fix For: Trunk, 5.4
>
> Attachments: SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch,
> SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch, SOLR-7746.patch
>
>
> {noformat:title="steps to reproduce"}
> # start 1 node SolrCloud cluster
> sh> ./bin/solr -c -p
> # create a test collection (we won’t use it, but I just want to it to load
> solr configs to Zk)
> ./bin/solr create_collection -c test -d sample_techproducts_configs -p
> # create another test collection with 2 shards
> curl
> 'http://localhost:/solr/admin/collections?action=CREATE=test2=2=1=2=test'
> # try distrib ping request
> curl
> 'http://localhost:/solr/test2/admin/ping?wt=json=true=true'
> ...
> "error":{
> "msg":"Ping query caused exception: Error from server at
> http://192.168.59.3:/solr/test2_shard2_replica1: Cannot execute the
> PingRequestHandler recursively"
> ...
> {noformat}
> {noformat:title="Exception"}
> 2116962 [qtp599601600-13] ERROR org.apache.solr.core.SolrCore [test2 shard2
> core_node1 test2_shard2_replica1] – org.apache.solr.common.SolrException:
> Cannot execute the PingRequestHandler recursively
> at
> org.apache.solr.handler.PingRequestHandler.handlePing(PingRequestHandler.java:246)
> at
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:211)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7995) Add a LIST command to ConfigSets API
[ https://issues.apache.org/jira/browse/SOLR-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7995: - Attachment: SOLR-7995.patch new patch with updated TestConfigSetAdminRequest. > Add a LIST command to ConfigSets API > > > Key: SOLR-7995 > URL: https://issues.apache.org/jira/browse/SOLR-7995 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > Attachments: SOLR-7995.patch, SOLR-7995.patch > > > It would be useful to have a LIST command in the ConfigSets API so that > clients do not have to access zookeeper in order to get the ConfigSets to use > for the other operations (create, delete). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8054) Add a GET command to ConfigSets API
[ https://issues.apache.org/jira/browse/SOLR-8054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14941964#comment-14941964 ] Gregory Chanan commented on SOLR-8054: -- I started prototyping this out. I think there are potentially multiple tasks here: 1) Config API / Schema API equivalents for ConfigSets See SOLR-7570 for the genesis of this; in short, the collection-based Config API and Schema APIs should not modify the underlying ConfigSet. It makes sense, then, to have GET-able Config API/Schema APIs that are specific to the ConfigSet because: a) these may be different from the Collection-Config representation b) you may not have a collection using the ConfigSet currently in a "template" world (SOLR-5955). Having PUT/POST-able ConfigSet-specific APIs is an open question IMO. 2) "Raw" File based view I'm thinking an http equivalent for "ZkCli -cmd DOWNCONFIG". The motivation is a subset of the motivation for a ConfigSet API as a whole, namely: m1) Doesn't require zookeeper access (which may not be available) m2) Can use the same authentication/authorization mechanisms as the rest of Solr m3) Doesn't require a collection to be instantiated (as today via the ShowFile API) There is a limitation due to http as compared to the ZkCli equivalent, namely that you can't "download" multiple files in a single GET request, see http://stackoverflow.com/questions/1041542/how-to-download-multiple-files-with-one-http-request. So we'd have to do one of the following: o1) zip up the ConfigSet o2) require the client to go file-by-file like the ShowFile API today o3) invent/use our own format that has "file breaks" within a single response I'm not sure the effort here is worth it, considering (I hope) the future is API-based like the Config/Schema API, not File-based. But it does at least seem useful until we are in a world where the majority are using the APIs. As for the options, I don't like o1). I don't have a strong preference for o2) vs o3), although I think I'd lean slightly to o3) just to be able to reduce the number of http calls required to download a config. Thoughts? > Add a GET command to ConfigSets API > --- > > Key: SOLR-8054 > URL: https://issues.apache.org/jira/browse/SOLR-8054 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Gregory Chanan >Assignee: Gregory Chanan > > It would be useful to have a command that allows you to view a ConfigSet via > the API rather than going to zookeeper directly. Mainly for security > reasons, e.g. > - solr may have different security requirements than the ZNodes e.g. only > solr can view znodes but any authenticated user can call ConfigSet API > - it's nicer than pointing to the web UI and using the zookeeper viewer, > because of the same security concerns as above and that you don't have to > know the internal zookeeper paths. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60) - Build # 14388 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/14388/ Java: 64bit/jdk1.8.0_60 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([4A683E3AE282C25C:ED2C869E8F39D1E5]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationWithTruncatedTlog(CdcrReplicationHandlerTest.java:121) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:52) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 810 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/810/ 1 tests failed. FAILED: org.apache.solr.handler.TestSQLHandler.doTest Error Message: --> http://127.0.0.1:60472/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:48489/collection1/: An exception has occurred on the server, refer to server log for details. Stack Trace: java.io.IOException: --> http://127.0.0.1:60472/collection1:java.util.concurrent.ExecutionException: java.io.IOException: --> http://127.0.0.1:48489/collection1/: An exception has occurred on the server, refer to server log for details. at __randomizedtesting.SeedInfo.seed([8DBBA9930FEE5899:2AFF113762554B20]:0) at org.apache.solr.client.solrj.io.stream.SolrStream.read(SolrStream.java:178) at org.apache.solr.handler.TestSQLHandler.getTuples(TestSQLHandler.java:1317) at org.apache.solr.handler.TestSQLHandler.testBasicSelect(TestSQLHandler.java:232) at org.apache.solr.handler.TestSQLHandler.doTest(TestSQLHandler.java:96) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Commented] (SOLR-7938) MergeStream to support N streams
[
https://issues.apache.org/jira/browse/SOLR-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14942048#comment-14942048
]
Dennis Gove commented on SOLR-7938:
---
Any thoughts on the feature or attached patch?
> MergeStream to support N streams
>
>
> Key: SOLR-7938
> URL: https://issues.apache.org/jira/browse/SOLR-7938
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
>Affects Versions: Trunk
>Reporter: Dennis Gove
>Priority: Minor
> Labels: streaming
> Attachments: SOLR-7938.patch
>
>
> Enhances MergeStream to support merging N streams. This was previously
> limited to merging just two streams but with this enhancement it can now
> accept any number of streams to merge.
> Based on the comparator, if more than one stream could provide the next value
> then the selected value will follow the order of the streams as they appear
> in the expression or were added to the MergeStream object.
> {code}
> merge(
> search(collection1, q="id:(0 4)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(1)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> search(collection1, q="id:(2)", fl="id,a_s,a_i,a_f", sort="a_f asc, a_s
> asc"),
> on="a_f asc"
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.8.0) - Build # 2719 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2719/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.cloud.MultiThreadedOCPTest.test Error Message: Error from server at http://127.0.0.1:61685: KeeperErrorCode = Session expired for /overseer/collection-map-completed/mn-2 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:61685: KeeperErrorCode = Session expired for /overseer/collection-map-completed/mn-2 at __randomizedtesting.SeedInfo.seed([3710F62795045593:BF44C9FD3BF8386B]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:575) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:150) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:167) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.getRequestState(AbstractFullDistribZkTestBase.java:1904) at org.apache.solr.cloud.MultiThreadedOCPTest.testParallelCollectionAPICalls(MultiThreadedOCPTest.java:79) at org.apache.solr.cloud.MultiThreadedOCPTest.test(MultiThreadedOCPTest.java:57) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Closed] (SOLR-8118) Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests.
[ https://issues.apache.org/jira/browse/SOLR-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein closed SOLR-8118. Resolution: Fixed Fix Version/s: Trunk > Call waitForRecoveriesToFinish(false); in the Streaming and SQL tests. > -- > > Key: SOLR-8118 > URL: https://issues.apache.org/jira/browse/SOLR-8118 > Project: Solr > Issue Type: Bug >Reporter: Joel Bernstein > Fix For: Trunk > > > Today the TestSQLHandler test cases began failing. It turned out that they > weren't calling waitForRecoveriesToFinish(false);. This ticket adds the > method call to all the Streaming/SQL test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java8 - Build # 437 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/437/ 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: Captured an uncaught exception in thread: Thread[id=4516, name=RecoveryThread-source_collection_shard1_replica1, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=4516, name=RecoveryThread-source_collection_shard1_replica1, state=RUNNABLE, group=TGRP-CdcrReplicationHandlerTest] Caused by: org.apache.solr.common.cloud.ZooKeeperException: at __randomizedtesting.SeedInfo.seed([D9026BAD12D58D3B]:0) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:232) Caused by: org.apache.solr.common.SolrException: java.io.FileNotFoundException: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_D9026BAD12D58D3B-001/jetty-001/cores/source_collection_shard1_replica1/data/tlog/tlog.008.1513979058230132736 (No such file or directory) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:244) at org.apache.solr.update.CdcrTransactionLog.incref(CdcrTransactionLog.java:173) at org.apache.solr.update.UpdateLog.getRecentUpdates(UpdateLog.java:1079) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1579) at org.apache.solr.update.UpdateLog.seedBucketsWithHighestVersion(UpdateLog.java:1610) at org.apache.solr.core.SolrCore.seedVersionBuckets(SolrCore.java:877) at org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:534) at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:225) Caused by: java.io.FileNotFoundException: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_D9026BAD12D58D3B-001/jetty-001/cores/source_collection_shard1_replica1/data/tlog/tlog.008.1513979058230132736 (No such file or directory) at java.io.RandomAccessFile.open0(Native Method) at java.io.RandomAccessFile.open(RandomAccessFile.java:316) at java.io.RandomAccessFile.(RandomAccessFile.java:243) at org.apache.solr.update.CdcrTransactionLog.reopenOutputStream(CdcrTransactionLog.java:236) ... 7 more Build Log: [...truncated 10056 lines...] [junit4] Suite: org.apache.solr.cloud.CdcrReplicationHandlerTest [junit4] 2> Creating dataDir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-trunk-Java8/solr/build/solr-core/test/J0/temp/solr.cloud.CdcrReplicationHandlerTest_D9026BAD12D58D3B-001/init-core-data-001 [junit4] 2> 615439 INFO (SUITE-CdcrReplicationHandlerTest-seed#[D9026BAD12D58D3B]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) [junit4] 2> 615439 INFO (SUITE-CdcrReplicationHandlerTest-seed#[D9026BAD12D58D3B]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: / [junit4] 2> 615461 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 615462 INFO (Thread-1980) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 615462 INFO (Thread-1980) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 615562 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.ZkTestServer start zk server on port:37893 [junit4] 2> 615562 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 615563 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 615565 INFO (zkCallback-363-thread-1) [] o.a.s.c.c.ConnectionManager Watcher org.apache.solr.common.cloud.ConnectionManager@64ed3165 name:ZooKeeperConnection Watcher:127.0.0.1:37893 got event WatchedEvent state:SyncConnected type:None path:null path:null type:None [junit4] 2> 615565 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 615565 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.SolrZkClient Using default ZkACLProvider [junit4] 2> 615565 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.SolrZkClient makePath: /solr [junit4] 2> 615568 INFO (TEST-CdcrReplicationHandlerTest.doTest-seed#[D9026BAD12D58D3B]) [] o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider [junit4] 2> 615570 INFO
[JENKINS] Lucene-Solr-trunk-Solaris (64bit/jdk1.8.0) - Build # 93 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Solaris/93/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.TestConfigSetsAPIExclusivity.testAPIExclusivity Error Message: Unexpected exception: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43018/solr: create the configset time out:300s expected:<0> but was:<1> Stack Trace: java.lang.AssertionError: Unexpected exception: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://127.0.0.1:43018/solr: create the configset time out:300s expected:<0> but was:<1> at __randomizedtesting.SeedInfo.seed([69C89628B70BD3C2:14BD8FD3EEAF6A8B]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.TestConfigSetsAPIExclusivity.testAPIExclusivity(TestConfigSetsAPIExclusivity.java:95) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1665) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:864) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:900) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:914) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:873) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:775) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:820) 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:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
