[jira] [Commented] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory
[
https://issues.apache.org/jira/browse/SOLR-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466909#comment-16466909
]
Mikhail Khludnev commented on SOLR-12322:
-
I don't really understand how [^doc_level_exaplantion.docx] answers my question
(what can't be done with \[subquery]?). If it's returning parents without
children, it can be done with {{fq}} on subquery level. Statements about
termcount still is not clear, how the proposed patch address it?
> Select specific field list for child documents using
> ChildDocTransformerFactory
> ---
>
> Key: SOLR-12322
> URL: https://issues.apache.org/jira/browse/SOLR-12322
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Response Writers, search
>Affects Versions: 6.6
>Reporter: adeppa
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-12322.patch, doc_level_exaplantion.docx
>
>
> With the current version of SOLR and nested indexing, when you are fetch a
> parent record it returns all the fields of its children. This is increasing
> the size of data being returned from SOLR and also hits our performance
> sometime.
> This ticket will be used to update the ChildDocTransformerFactory class with
> additional parameters to specify the list of fields to be pulled for child
> documents.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)
[
https://issues.apache.org/jira/browse/SOLR-12298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466905#comment-16466905
]
mosh commented on SOLR-12298:
-
David you have some really strong points.
Firstly,
While it is true __childDocument__ is not required, sometimes the JSON you get
is not an array, but a child document, e.g.
{code:java}
{ "id": "X998_Y998", "from": { "name": "Peyton Manning", "id": "X18" },
"message": "Where's my contract?", "actions": [ { "name": "Comment", "link":
"http://www.facebook.com/X998/posts/Y998; }, { "name": "Like", "link":
"http://www.facebook.com/X998/posts/Y998; } ], "type": "status",
"created_time": "2010-08-02T21:27:44+", "updated_time":
"2010-08-02T21:27:44+" }
{code}
This is a sample Facebook API response. The array syntax will index the array
as child documents, but it will not index the child document under the key
"from"
{code:java}
{ "from": { "name": "Peyton Manning", "id": "X18" } } {code}
It would be nice if you could just index JSON as is, like you can in elastic
search, moving the responsibility from the user to Solr itself.
This feature could also be added to the XML loader if needed, to enable feature
equality. After this change the is introduced to the data loaders, the rest can
be done using an URP, as long as the loaders add the needed metadata for the
URP to add the required fields.
Afterwards, a new transformer could be introduced that rebuilds the whole JSON
structure, including the full original hierarchy.
On the other hand, adding a SolrInputDocument as a supported field could be the
better way to go, making most of the logic "hack" redundant and unneeded.
Perhaps you are right, and this is the better choice in the long run.
> Index Full nested document Hierarchy For Queries (umbrella issue)
> -
>
> Key: SOLR-12298
> URL: https://issues.apache.org/jira/browse/SOLR-12298
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: mosh
>Priority: Major
>
> Solr ought to have the ability to index deeply nested objects, while storing
> the original document hierarchy.
> Currently the client has to index the child document's full path and level
> to manually reconstruct the original document structure, since the children
> are flattened and returned in the reserved "__childDocuments__" key.
> Ideally you could index a nested document, having Solr transparently add the
> required fields while providing a document transformer to rebuild the
> original document's hierarchy.
>
> This issue is an umbrella issue for the particular tasks that will make it
> all happen – either subtasks or issue linking.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-master-Linux (64bit/jdk-9.0.4) - Build # 33 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-master-Linux/33/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 4 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage Error Message: SolrCore.getOpenCount()==2 Stack Trace: java.lang.RuntimeException: SolrCore.getOpenCount()==2 at __randomizedtesting.SeedInfo.seed([E7AB18C3973B3046]:0) at org.apache.solr.util.TestHarness.close(TestHarness.java:379) at org.apache.solr.SolrTestCaseJ4.deleteCore(SolrTestCaseJ4.java:801) at org.apache.solr.cloud.AbstractZkTestCase.azt_afterClass(AbstractZkTestCase.java:147) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:897) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: junit.framework.TestSuite.org.apache.solr.rest.TestManagedResourceStorage Error Message: 4 threads leaked from SUITE scope at org.apache.solr.rest.TestManagedResourceStorage: 1) Thread[id=17721, name=Thread-3920, state=WAITING, group=TGRP-TestManagedResourceStorage] at java.base@9.0.4/java.lang.Object.wait(Native Method) at java.base@9.0.4/java.lang.Thread.join(Thread.java:1353) at java.base@9.0.4/java.lang.Thread.join(Thread.java:1427) at app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:313) at app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:313) at app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:496)2) Thread[id=17723, name=SessionTracker, state=TIMED_WAITING, group=TGRP-TestManagedResourceStorage] at java.base@9.0.4/java.lang.Object.wait(Native Method) at app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147) 3) Thread[id=17722, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, group=TGRP-TestManagedResourceStorage] at java.base@9.0.4/sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) at java.base@9.0.4/sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:265) at java.base@9.0.4/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:92) at java.base@9.0.4/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) at java.base@9.0.4/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) at app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:196) at java.base@9.0.4/java.lang.Thread.run(Thread.java:844)4) Thread[id=17725, name=ProcessThread(sid:0 cport:36081):, state=WAITING, group=TGRP-TestManagedResourceStorage] at java.base@9.0.4/jdk.internal.misc.Unsafe.park(Native Method) at
[JENKINS] Lucene-Solr-repro - Build # 590 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/590/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/214/consoleText [repro] Revision: b72af046c5bd04eec4e84700a2ee20ab5a833e39 [repro] Ant options: -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testTrigger -Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration -Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testMergeIntegration -Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 08ee037ff8cc1edee87c14424d5a5a479ad2adf5 [repro] git fetch [...truncated 2 lines...] [repro] git checkout b72af046c5bd04eec4e84700a2ee20ab5a833e39 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3316 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -DsmokeTestRelease.java9=/home/jenkins/tools/java/latest1.9 -Dtests.seed=BDC3D8125D4F03FD -Dtests.multiplier=2 -Dtests.locale=mk -Dtests.timezone=Etc/GMT-13 -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 7658 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 08ee037ff8cc1edee87c14424d5a5a479ad2adf5 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 5 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12321) Use of builtin java serialization for admin response breaks 7.3 compatibility
[
https://issues.apache.org/jira/browse/SOLR-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466871#comment-16466871
]
Mark Miller commented on SOLR-12321:
Yeah, this should have been done by serializing the response map itself with
JavaBin or something. There is always a better option than built in Java
serialization. I actually reviewed this and put it in way back, so it's my
fault. We should have pulled the map from the object and serialized that with
JavaBin or stored it as JSON or or or.
> Use of builtin java serialization for admin response breaks 7.3 compatibility
> -
>
> Key: SOLR-12321
> URL: https://issues.apache.org/jira/browse/SOLR-12321
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3, 7.3.1
>Reporter: Will Currie
>Priority: Minor
>
> Premise: During an upgrade I should be able to run a 7.3 pull replica against
> a 7.2 tlog leader. Or vice versa.
>
> Adding a new method[1] to SolrResponse has broken binary compatibility. When
> I try to register a new pull replica using the admin api[2] I get an HTTP 500
> responseI see this error logged: java.io.InvalidClassException:
> org.apache.solr.client.solrj.SolrResponse; local class incompatible: stream
> classdesc serialVersionUID = 3945300637328478755, local class
> serialVersionUID = -793110010336024264
>
> The replica actually seems to register ok it just can't read the response
> because the bytes from the 7.2 leader include a different serialVersionUID.
>
> Should SolrResponse include a serialVersionIUID? All subclasses too.
> [~markrmil...@gmail.com]'s advice is that the project should never use
> builtin java serialization.
>
> It looks like stock java serialization is only used for these admin
> responses. Query responses use JavaBinCodec instead..
>
> Full(ish) stack trace:
> {noformat}
> ERROR HttpSolrCall null:org.apache.solr.common.SolrException:
> java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse;
> local class incompatible: st
> ream classdesc serialVersionUID = 3945300637328478755, local class
> serialVersionUID = -7931100103360242645
> at
> org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:73)
> at
> org.apache.solr.handler.admin.CollectionsHandler.sendToOCPQueue(CollectionsHandler.java:348)
> at
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:256)
> at
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
> at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
> at
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
> {noformat}
>
> [1]
> [https://github.com/apache/lucene-solr/commit/5ce83237e804ac1130eaf5cf793955667793fee0#diff-b809fa594f93aa6805381029a188e4e2R46]
> [2]
> [http://localhost:8983/solr/admin/collections?action=ADDREPLICA=blah=shard1=blah=pull]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12209) add Paging Streaming Expression
[
https://issues.apache.org/jira/browse/SOLR-12209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466868#comment-16466868
]
Lucene/Solr QA commented on SOLR-12209:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
45s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m
13s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 25m 46s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12209 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12922219/SOLR-12209.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 08ee037 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 8 2015 |
| Default Java | 1.8.0_172 |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/85/testReport/ |
| modules | C: solr/solrj U: solr/solrj |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/85/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> add Paging Streaming Expression
> ---
>
> Key: SOLR-12209
> URL: https://issues.apache.org/jira/browse/SOLR-12209
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Affects Versions: 7.3
>Reporter: mosh
>Priority: Major
> Attachments: 0001-added-skip-and-limit-stream-decorators.patch,
> SOLR-12209.patch, SOLR-12209.patch
>
>
> Currently the closest streaming expression that allows some sort of
> pagination is top.
> I propose we add a new streaming expression, which is based on the
> RankedStream class to add offset to the stream. currently it can only be done
> in code by reading the stream until the desired offset is reached.
> The new expression will be used as such:
> {{paging(rows=3, search(collection1, q="*:*", qt="/export",
> fl="id,a_s,a_i,a_f", sort="a_f desc, a_i desc"), sort="a_f asc, a_i asc",
> start=100)}}
> {{this will offset the returned stream by 100 documents}}
>
> [~joel.bernstein] what to you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12055) Enable asynch logging by default
[ https://issues.apache.org/jira/browse/SOLR-12055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466865#comment-16466865 ] Mark Miller commented on SOLR-12055: If we enable it by default we should loudly point out one of the the downsides that could affect some users negatively - particularly anyone counting on logging for auditing. > Enable asynch logging by default > > > Key: SOLR-12055 > URL: https://issues.apache.org/jira/browse/SOLR-12055 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > > When SOLR-7887 is done, switching to asynch logging will be a simple change > to the config files for log4j2. This will reduce contention and increase > throughput generally and logging in particular. > There's a discussion of the pros/cons here: > https://logging.apache.org/log4j/2.0/manual/async.html > An alternative is to put a note in the Ref Guide about how to enable async > logging. > I guess even if we enable async by default the ref guide still needs a note > about how to _disable_ it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR
[
https://issues.apache.org/jira/browse/SOLR-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466856#comment-16466856
]
Mark Miller commented on SOLR-11881:
Patch looks nice [~tomasflobbe] - very clean.
> Connection Reset Causing LIR
>
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch,
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX
> r:core_node56 collection_shardX_replicaY]
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy
> working SolrCloud cluster, even a rare response like this from a replica can
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET
> requests. Updates are POST requests
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since
> they have been versioned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466848#comment-16466848
]
Lucene/Solr QA commented on SOLR-12303:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
23s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 2m 30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 2m 20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 2m 20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate ref guide {color} |
{color:green} 2m 20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}182m 43s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}193m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.IndexSizeTriggerTest |
| | solr.cloud.TestRandomFlRTGCloud |
| | solr.cloud.autoscaling.sim.TestGenericDistributedQueue |
| | solr.security.hadoop.TestSolrCloudWithHadoopAuthPlugin |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12303 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12922284/SOLR-12303.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns validaterefguide |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 3e8f31e |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_172 |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/84/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/84/testReport/ |
| modules | C: solr/core solr/solr-ref-guide U: solr |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/84/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.3 - Build # 22 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/22/ 2 tests failed. FAILED: org.apache.solr.cloud.RestartWhileUpdatingTest.test Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([A1301A2097C7DAD]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.RestartWhileUpdatingTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([A1301A2097C7DAD]:0) Build Log: [...truncated 15360 lines...] [junit4] Suite: org.apache.solr.cloud.RestartWhileUpdatingTest [junit4] 2> 3831694 INFO (SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> Creating dataDir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/build/solr-core/test/J1/temp/solr.cloud.RestartWhileUpdatingTest_A1301A2097C7DAD-001/init-core-data-001 [junit4] 2> 3831711 WARN (SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=25 numCloses=25 [junit4] 2> 3831713 INFO (SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 3831727 INFO (SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN) [junit4] 2> 3831728 INFO (SUITE-RestartWhileUpdatingTest-seed#[A1301A2097C7DAD]-worker) [] o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /h/ [junit4] 2> 3831731 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 3831772 INFO (Thread-9567) [] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 3831772 INFO (Thread-9567) [] o.a.s.c.ZkTestServer Starting server [junit4] 2> 3831792 ERROR (Thread-9567) [] o.a.z.s.ZooKeeperServer ZKShutdownHandler is not registered, so ZooKeeper server won't take any action on ERROR or SHUTDOWN server state changes [junit4] 2> 3831890 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.ZkTestServer start zk server on port:41496 [junit4] 2> 3831934 INFO (zkConnectionManagerCallback-2648-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 3832040 INFO (zkConnectionManagerCallback-2650-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 3832043 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/solrconfig-tlog.xml to /configs/conf1/solrconfig.xml [junit4] 2> 3832057 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/schema15.xml to /configs/conf1/schema.xml [junit4] 2> 3832058 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/solrconfig.snippet.randomindexconfig.xml to /configs/conf1/solrconfig.snippet.randomindexconfig.xml [junit4] 2> 3832059 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/stopwords.txt to /configs/conf1/stopwords.txt [junit4] 2> 3832077 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/protwords.txt to /configs/conf1/protwords.txt [junit4] 2> 3832078 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put /home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/checkout/solr/core/src/test-files/solr/collection1/conf/currency.xml to /configs/conf1/currency.xml [junit4] 2> 3832079 INFO (TEST-RestartWhileUpdatingTest.test-seed#[A1301A2097C7DAD]) [] o.a.s.c.AbstractZkTestCase put
[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR
[
https://issues.apache.org/jira/browse/SOLR-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466841#comment-16466841
]
Mark Miller commented on SOLR-11881:
Yeah, I'd be hesitant to add retries to DBQ without input from
[~ysee...@gmail.com].
> Connection Reset Causing LIR
>
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch,
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX
> r:core_node56 collection_shardX_replicaY]
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy
> working SolrCloud cluster, even a rare response like this from a replica can
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET
> requests. Updates are POST requests
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since
> they have been versioned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11881) Connection Reset Causing LIR
[
https://issues.apache.org/jira/browse/SOLR-11881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466833#comment-16466833
]
Tomás Fernández Löbbe commented on SOLR-11881:
--
I updated the CR with a new patch. Added a test for minRf, but this is more
deeply tested in ReplicationFactorTest (that test now takes longer because of
the retries. I'm thinking in either making the wait time configurable or modify
it for test purposes only). ReplicationFactorTest is marked as {{@BadApple}}
pointing to SOLR-6944, this retry logic will probably fix that one. I haven't
seen failures of that test so far.
There is one nocommit in the code, I'm wondering if we want to keep the retries
for DBQs. I'm thinking in setting the retry count for DBQs to 0, since those
are not versioned AFAIK.
Another thing I noticed is that we sleep after each error retried (so if we
need to retry two requests to two hosts, we sleep before the first request, and
sleep before the second one). This seems odd, I think we want to sleep before
retrying a batch of errors. I won't be changing this here though, I'll create a
new Jira for that.
I'll be running some tests with the current patch, feel free to review and let
me know if you have any thoughts
> Connection Reset Causing LIR
>
>
> Key: SOLR-11881
> URL: https://issues.apache.org/jira/browse/SOLR-11881
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch,
> SOLR-11881.patch
>
>
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will
> initiate LIR
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX
> r:core_node56 collection_shardX_replicaY]
> o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start recovery on
> replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(SocketInputStream.java:210)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:543)
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409)
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304)
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446)
> at
> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:312)
> at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.run(ConcurrentUpdateSolrClient.java:185)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> From https://issues.apache.org/jira/browse/SOLR-6931 Mark says "On a heavy
> working SolrCloud cluster, even a rare response like this from a replica can
> cause a recovery and heavy cluster disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET
> requests. Updates are POST requests
> {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since
>
[jira] [Commented] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory
[ https://issues.apache.org/jira/browse/SOLR-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466831#comment-16466831 ] adeppa commented on SOLR-12322: --- [~mkhludnev] Please find attachment for the explanation of business use case and what feature i used > Select specific field list for child documents using > ChildDocTransformerFactory > --- > > Key: SOLR-12322 > URL: https://issues.apache.org/jira/browse/SOLR-12322 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Response Writers, search >Affects Versions: 6.6 >Reporter: adeppa >Priority: Minor > Fix For: 6.6 > > Attachments: SOLR-12322.patch, doc_level_exaplantion.docx > > > With the current version of SOLR and nested indexing, when you are fetch a > parent record it returns all the fields of its children. This is increasing > the size of data being returned from SOLR and also hits our performance > sometime. > This ticket will be used to update the ChildDocTransformerFactory class with > additional parameters to specify the list of fields to be pulled for child > documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12322) Select specific field list for child documents using ChildDocTransformerFactory
[ https://issues.apache.org/jira/browse/SOLR-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] adeppa updated SOLR-12322: -- Attachment: doc_level_exaplantion.docx > Select specific field list for child documents using > ChildDocTransformerFactory > --- > > Key: SOLR-12322 > URL: https://issues.apache.org/jira/browse/SOLR-12322 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Response Writers, search >Affects Versions: 6.6 >Reporter: adeppa >Priority: Minor > Fix For: 6.6 > > Attachments: SOLR-12322.patch, doc_level_exaplantion.docx > > > With the current version of SOLR and nested indexing, when you are fetch a > parent record it returns all the fields of its children. This is increasing > the size of data being returned from SOLR and also hits our performance > sometime. > This ticket will be used to update the ChildDocTransformerFactory class with > additional parameters to specify the list of fields to be pulled for child > documents. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Review Request 66967: SolrCmdDistributor retries requestss from leader to followers
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/66967/ --- (Updated May 8, 2018, 3:51 a.m.) Review request for lucene. Repository: lucene-solr Description (updated) --- SolrCmdDistributor retries requestss from leader to followers Diffs (updated) - solr/core/src/java/org/apache/solr/update/SolrCmdDistributor.java 08b397fbb2 solr/core/src/java/org/apache/solr/update/StreamingSolrClients.java 316aa455a1 solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java d5e4194b15 solr/core/src/java/org/apache/solr/update/processor/TimeRoutedAliasUpdateProcessor.java 224bd4b6ba solr/core/src/test/org/apache/solr/cloud/ChaosMonkeySafeLeaderTest.java 76c1984a0d solr/core/src/test/org/apache/solr/update/MockStreamingSolrClients.java 72d39ff89b solr/core/src/test/org/apache/solr/update/SolrCmdDistributorTest.java 1699b0d70d Diff: https://reviews.apache.org/r/66967/diff/3/ Changes: https://reviews.apache.org/r/66967/diff/2-3/ Testing --- Thanks, Tomás Fernández Löbbe
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-9) - Build # 4613 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4613/ Java: 64bit/jdk-9 -XX:-UseCompressedOops -XX:+UseSerialGC 4 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger Error Message: waitFor not elapsed but produced an event Stack Trace: java.lang.AssertionError: waitFor not elapsed but produced an event at __randomizedtesting.SeedInfo.seed([68D8E8204374F09C:B13DEA2DABB83B1]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger(IndexSizeTriggerTest.java:180) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testTrigger Error Message: number of ops expected:<2> but was:<1> Stack Trace: java.lang.AssertionError: number of ops expected:<2> but was:<1> at
[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)
[
https://issues.apache.org/jira/browse/SOLR-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466789#comment-16466789
]
David Smiley commented on SOLR-12258:
-
Thanks for the input. Here's another variation of this method; this time
without a secondTry arg which I don't really like:
{code:java}
protected DocCollection resolveDocCollection(String collectionStr) {
if (!cores.isZooKeeperAware()) {
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Solr not
running in cloud mode ");
}
ZkStateReader zkStateReader = cores.getZkController().getZkStateReader();
Supplier logic = () -> {
this.collectionsList = resolveCollectionListOrAlias(collectionStr); //
side-effect
String collectionName = collectionsList.get(0); // first
//TODO an option to choose another collection in the list if can't find a
local replica of the first?
return
zkStateReader.getClusterState().getCollectionOrNull(collectionName);
};
DocCollection docCollection = logic.get();
if (docCollection != null) {
return docCollection;
}
// ensure our view is up to date before trying again
try {
zkStateReader.aliasesManager.update();
zkStateReader.forceUpdateCollection(collectionsList.get(0));
} catch (Exception e) {
log.error("Error trying to update state while resolving collection.", e);
//don't propagate exception on purpose
}
return logic.get();
}
{code}
I can't come up with anything elegant. At least the lambda had little ceremony
to it, helped by the fact that no checked exceptions are involved and so I
could use the standard Supplier interface.
bq. forciblyRefreshAllClusterStateSlow
Heh; I didn't notice it. It sure does look like a candidate! Yeah, adding
sync() over there ought to be its own JIRA.
> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry
> the request as if anew (in collaboration with SolrDispatchFilter). If it
> fails to resolve again we stop there and return an error; it doesn't go on
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism. It'll return
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that
> will at least help the odds of a newly made collection from being known to
> this Solr node. It'd be nice if this was more explicit – i.e. if there was a
> mechanism similar to AliasesManager.update() but for a collection. I'm not
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to
> issue a V2 based request to change the configuration of a collection that was
> created immediately before it. It's pretty mysterious. I am aware of
> SolrCloudTestCase.waitForState which is maybe something that needs to be
> called? But if that were true then *every* SolrCloud test would need to use
> it; it just seems wrong to me that we ought to use this method commonly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12265) Upgrade Jetty to 9.4.10
[
https://issues.apache.org/jira/browse/SOLR-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-12265:
-
Summary: Upgrade Jetty to 9.4.10 (was: Upgrade Jetty to 9.4.9)
> Upgrade Jetty to 9.4.10
> ---
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8
> We're seeing this WARN very sporadically ( maybe one in every 100k requests )
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) -
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0
> of
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
> of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x
> and then in Jetty 9.4.9 this class has undergone quite a few changes
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
> .
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12308) LISTALIASES should return up to date response
[ https://issues.apache.org/jira/browse/SOLR-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-12308. - Resolution: Fixed Fix Version/s: 7.4 > LISTALIASES should return up to date response > - > > Key: SOLR-12308 > URL: https://issues.apache.org/jira/browse/SOLR-12308 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.4 > > Attachments: SOLR-12308.patch > > > The LISTALIASES command might return a stale response due to the default > eventual consistency of reads of ZooKeeper. I think if someone calls this > command (which generally won't be rapid-fire), they deserve an up to date > response. This is easily done with a one-liner; patch forthcoming. > Returning stale alias info is the only plausible explanation I have for why a > recent CI failure for AliasesIntegrationTest.tearDown() failed to detect > aliases to be deleted. It calls listAliases to know which aliases exist so it > can then delete them 1st. > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/] > tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which > interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() > perhaps this ought to delete all aliases _as well_ since, after all, if there > were any aliases then well deleting all collections is bound to fail. Should > I file a separate issue or just handle this together? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response
[ https://issues.apache.org/jira/browse/SOLR-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466755#comment-16466755 ] ASF subversion and git services commented on SOLR-12308: Commit 6b1a64e1e6041e1205c3180c08365bbab18096a1 in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6b1a64e ] SOLR-12308: LISTALIASES is now assured to return an up-to-date response * MiniSolrCloudCluster.deleteAllCollections will now first delete aliases * Minor refactorings to AliasesManager, AliasIntegrationTest, CreateRoutedAliasTest (cherry picked from commit 08ee037) > LISTALIASES should return up to date response > - > > Key: SOLR-12308 > URL: https://issues.apache.org/jira/browse/SOLR-12308 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-12308.patch > > > The LISTALIASES command might return a stale response due to the default > eventual consistency of reads of ZooKeeper. I think if someone calls this > command (which generally won't be rapid-fire), they deserve an up to date > response. This is easily done with a one-liner; patch forthcoming. > Returning stale alias info is the only plausible explanation I have for why a > recent CI failure for AliasesIntegrationTest.tearDown() failed to detect > aliases to be deleted. It calls listAliases to know which aliases exist so it > can then delete them 1st. > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/] > tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which > interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() > perhaps this ought to delete all aliases _as well_ since, after all, if there > were any aliases then well deleting all collections is bound to fail. Should > I file a separate issue or just handle this together? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response
[ https://issues.apache.org/jira/browse/SOLR-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466750#comment-16466750 ] ASF subversion and git services commented on SOLR-12308: Commit 08ee037ff8cc1edee87c14424d5a5a479ad2adf5 in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=08ee037 ] SOLR-12308: LISTALIASES is now assured to return an up-to-date response * MiniSolrCloudCluster.deleteAllCollections will now first delete aliases * Minor refactorings to AliasesManager, AliasIntegrationTest, CreateRoutedAliasTest > LISTALIASES should return up to date response > - > > Key: SOLR-12308 > URL: https://issues.apache.org/jira/browse/SOLR-12308 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-12308.patch > > > The LISTALIASES command might return a stale response due to the default > eventual consistency of reads of ZooKeeper. I think if someone calls this > command (which generally won't be rapid-fire), they deserve an up to date > response. This is easily done with a one-liner; patch forthcoming. > Returning stale alias info is the only plausible explanation I have for why a > recent CI failure for AliasesIntegrationTest.tearDown() failed to detect > aliases to be deleted. It calls listAliases to know which aliases exist so it > can then delete them 1st. > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/] > tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which > interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() > perhaps this ought to delete all aliases _as well_ since, after all, if there > were any aliases then well deleting all collections is bound to fail. Should > I file a separate issue or just handle this together? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.3-Windows (64bit/jdk-10) - Build # 45 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Windows/45/ Java: 64bit/jdk-10 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testTrigger Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([A409447E985B591E:C7C272FC01942A33]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest.testTrigger(NodeAddedTriggerTest.java:111) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) Build Log: [...truncated 14183 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest [junit4] 2> 2818821 INFO (SUITE-NodeAddedTriggerTest-seed#[A409447E985B591E]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null &
[JENKINS] Lucene-Solr-Tests-master - Build # 2521 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/2521/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([8F301B8FD3EE943:5B4A43081F2F7CB9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13145 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [junit4] 2> 802241 INFO (SUITE-IndexSizeTriggerTest-seed#[8F301B8FD3EE943]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null &
[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-7767: -- Attachment: (was: image-2018-05-08-02-26-29-989.png) > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Attachments: zk-status-error.png, zk-status-tab.png > > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI
[
https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466680#comment-16466680
]
Jan Høydahl commented on SOLR-7767:
---
Here is screenshot from a new "Zookeeper" tab in the cloud section:
!zk-status-tab.png|width=700!
It takes zkHost string and talks directly to each configured zookeeper using
the low-level socket API
"[four-letter-word|https://zookeeper.apache.org/doc/r3.4.11/zookeeperAdmin.html#sc_zkCommands];
and returns monitoring status (MNTR) as well as configuration details (CONF)
for each ZK. It will also print warnings if there is an odd number of nodes, if
there is a mix of standalone and ensemble nodes and other warning states.
The API is added to {{ZookeeperInfoHandler}}, with parameter {{mntr=true}}.
Example:
[http://localhost:8983/solr/admin/zookeeper?mntr=true]
{code}
{
"responseHeader": {
"QTime": 24,
"status": 0
},
"zkStatus": {
"details": [{
"clientPort": "9983",
"dataDir":
"/Users/janhoy/git/lucene-solr/solr/server/solr/zoo_data/version-2",
"dataLogDir":
"/Users/janhoy/git/lucene-solr/solr/server/solr/zoo_data/version-2",
"host": "localhost:9983",
"maxClientCnxns": "60",
"maxSessionTimeout": "4",
"minSessionTimeout": "4000",
"ok": true,
"serverId": "0",
"tickTime": "2000",
"zk_approximate_data_size": "210920",
"zk_avg_latency": "0",
"zk_ephemerals_count": "3",
"zk_max_file_descriptor_count": "10240",
"zk_max_latency": "4",
"zk_min_latency": "0",
"zk_num_alive_connections": "3",
"zk_open_file_descriptor_count": "158",
"zk_outstanding_requests": "0",
"zk_packets_received": "165",
"zk_packets_sent": "167",
"zk_server_state": "standalone",
"zk_version": "3.4.11-37e277162d567b55a07d1755f0b31c32e93c01a0, built on
11/01/2017 18:06 GMT",
"zk_watch_count": "18",
"zk_znode_count": "79"
}],
"ensembleSize": 1,
"mode": "standalone",
"status": "green"
}
}
{code}
Here's an example of an error (one zk cannot be reached):
!zk-status-error.png|width=700!
> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
> Issue Type: New Feature
> Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: image-2018-05-08-02-26-29-989.png, zk-status-error.png,
> zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes
> from the zookeeper ensemble. So that user can easily get to know if any of
> zookeeper instance is down or having any other issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-7767: -- Attachment: zk-status-error.png > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Attachments: image-2018-05-08-02-26-29-989.png, zk-status-error.png, > zk-status-tab.png > > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-7767: -- Attachment: image-2018-05-08-02-26-29-989.png > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Attachments: image-2018-05-08-02-26-29-989.png, zk-status-tab.png > > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
[ https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-9480: --- Attachment: SOLR-9480.patch > Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph) > -- > > Key: SOLR-9480 > URL: https://issues.apache.org/jira/browse/SOLR-9480 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Trey Grainger >Priority: Major > Attachments: SOLR-9480.patch, SOLR-9480.patch > > > This issue is to track the contribution of the Semantic Knowledge Graph Solr > Plugin (request handler), which exposes a graph-like interface for > discovering and traversing significant relationships between entities within > an inverted index. > This data model has been described in the following research paper: [The > Semantic Knowledge Graph: A compact, auto-generated model for real-time > traversal and ranking of any relationship within a > domain|https://arxiv.org/abs/1609.00464], as well as in presentations I gave > in October 2015 at [Lucene/Solr > Revolution|http://www.slideshare.net/treygrainger/leveraging-lucenesolr-as-a-knowledge-graph-and-intent-engine] > and November 2015 at the [Bay Area Search > Meetup|http://www.treygrainger.com/posts/presentations/searching-on-intent-knowledge-graphs-personalization-and-contextual-disambiguation/]. > The source code for this project is currently available at > [https://github.com/careerbuilder/semantic-knowledge-graph], and the folks at > CareerBuilder (where this was built) have given me the go-ahead to now > contribute this back to the Apache Solr Project, as well. > Check out the Github repository, research paper, or presentations for a more > detailed description of this contribution. Initial patch coming soon. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9480) Graph Traversal for Significantly Related Terms (Semantic Knowledge Graph)
[
https://issues.apache.org/jira/browse/SOLR-9480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1644#comment-1644
]
Hoss Man commented on SOLR-9480:
I've been playing with this "SKG" code off an on for a bit, and talking with
trey about it offline, and I think I've come up with a nice strategy for
integrating it directly into JSON Faceting as a handfull small improvements, to
be able to leverage most of the existing JSON Facet code (including distributed
refinement) w/o needing to be "tacked on" to the outside as much as the code in
the older patch/github-repo does.
The attached patch includes the 3 most "important" of these improvements in
order for this to work, along with lots of new tests...
# Refactoring the {{SlotAcc}} so that everytime it's asked to {{collect(...)}}
a slot, it has the ability to ask for a {{Query}} that identifies this slot
_independent of the current context_
** This allows the new SKG code (described below) to have enough information
about the current bucket that it can compute the full "foreground" that it
wants, regardless of the bucket type or how the current bucket may be nested
under other facets ... so SKG graphs can be built by nesting any types of
facets (including range & query facets) regardless of how the top level {{q +
fq}} params realted to the {{foreground}} query.
** this happens via a {{IntFunction}} callback function – so there
shouldn't be any overhead to existing FacetProcessor/SlotAcc usages that don't
care about this extra info about the bucket – there's no extra {{TermQuery}}
(or {{RangeQuery}} etc...) overhead when the accumulators only care about the
final filtered set of documents for the current bucket/slot.
# Add an {{skg(...)}} AggValueSource function that can be nested under any
facet
** this function takes in the "foreground" and "background" queries to use,
which just like any existing (aggregate) function can be {{$variables}}
pointing to existing request params
** this means that, unlike the original SKG code linked from this issue, you
could compute the SKG relatedness info only at certain points in the facet
herirachy, or use different foreground/background queries in different places
** this function actually produces JSON "objects" as the function result,
containing the foreground/background popularities as well as the "relatedness"
score – which is what's used if you sort on this function
** I originally experimented with implementing "SKG" as a new type of _facet_
that could be nested under any (othe) facet, but implementing as a function
means that we can leverage the existing code for sorting (parent) facet buckets
by the (child) function's results – which is very powerful for SKG results (and
it's not currently possible to "sort" on the results of a sub-facet, and doing
so would be a lot of work given how sub-facet refinement is currently handled
... i looked into it briefly)
** but sorting on the {{skg()}} function is optional, and not strictly
neccessary when the clients care more about performance then accuracy – as with
the existing SKG code trey contributed, the (default) sort on facet count could
still be used, which means the existing JSON faceting code would only compute
the (semi-expensive) {{skg()}} function on the final buckets to be returned,
and the client could then post-process to re-sort them by the {{skg()}} values.
# Add support for a "explicit query domain" via syntax like {{domain :
\{query:'foo:bar'\}}} (or any other JSON query syntax supported by the
{{filters}} option) that let's you arbitrarily pick any set of queries you want
to use as a "domain" for a facet, regardless of it's parent facets/bucket.
** this provides an optional way to improve the "top n" accuracy of sub-facets
in a deep SKG request, by letting you ignore the "ancestor facet bucket
filtering" typically done in faceting, and instead request that *all* buckets
under some arbitrarr query – like the original background query – be considered.
** SKG users that care more about speed & aproximations can ignore this
feature, and just sort the regular facet terms by the {{skg()}} function to get
a good aproximation of the top terms ... or as I mentioned before: trust the
(default) sort on facet counts (w/or w/o using the {{$background_q}} as an
explicit domain) to approximate the top N terms)
An example of what all these features together can look like right now...
{noformat}
rows=0&
q=type:QUESTION&
fore=body:%22harry+potter%22&
back=*:*&
json.facet='{
tags : {
type : terms,
field : tags,
limit : 5,
sort : { skg: desc },
facet : {
skg : "skg($fore,$back)",
body : {
type : terms,
field : body,
limit : 5,
domain : { query:{param:back} },
sort : { skg: desc },
facet : {
skg : "skg($fore,$back)"
}
}
}
}
}'
[jira] [Updated] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-7767: -- Attachment: zk-status-tab.png > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Attachments: zk-status-tab.png > > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12258) V2 API should "retry" for unresolved collections/aliases (like V1 does)
[
https://issues.apache.org/jira/browse/SOLR-12258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466632#comment-16466632
]
Gus Heck commented on SOLR-12258:
-
I think it might read better to move the contents of the two
{code:java}
if (secondTry){code}
blocks into the
{code:java}
if(!secondTry){code}
block just before recursion. (conditionally "Update and recurse" rather than
recurse then conditionally update)
Also in inspecting usages of
{code:java}
forceUpdateCollection(collectionName) {code}
I came across the javadoc comment on
{code:java}
org.apache.solr.common.cloud.ZkStateReader#forciblyRefreshAllClusterStateSlow{code}
method. That method seems like an even bigger candidate for a Zookeeper.sync(),
but maybe that's another jira
> V2 API should "retry" for unresolved collections/aliases (like V1 does)
> ---
>
> Key: SOLR-12258
> URL: https://issues.apache.org/jira/browse/SOLR-12258
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, v2 API
>Reporter: David Smiley
>Priority: Major
> Attachments: SOLR-12258.patch, SOLR-12258.patch
>
>
> When using V1, if the request refers to a possible collection/alias that
> fails to resolve, HttpSolrCall will invoke AliasesManager.update() then retry
> the request as if anew (in collaboration with SolrDispatchFilter). If it
> fails to resolve again we stop there and return an error; it doesn't go on
> forever.
> V2 (V2HttpCall specifically) doesn't have this retry mechanism. It'll return
> "no such collection or alias".
> The retry will not only work for an alias but the retrying is a delay that
> will at least help the odds of a newly made collection from being known to
> this Solr node. It'd be nice if this was more explicit – i.e. if there was a
> mechanism similar to AliasesManager.update() but for a collection. I'm not
> sure how to do that?
> BTW I discovered this while debugging a Jenkins failure of
> TimeRoutedAliasUpdateProcessorTest.test where it early on simply goes to
> issue a V2 based request to change the configuration of a collection that was
> created immediately before it. It's pretty mysterious. I am aware of
> SolrCloudTestCase.waitForState which is maybe something that needs to be
> called? But if that were true then *every* SolrCloud test would need to use
> it; it just seems wrong to me that we ought to use this method commonly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-10) - Build # 7306 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7306/ Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseParallelGC 27 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([343DA872540BC647:DB311327BF40FB9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration(IndexSizeTriggerTest.java:298) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at
[jira] [Commented] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466623#comment-16466623
]
Julie Tibshirani commented on LUCENE-8287:
--
We caught up offline, and [~jim.ferenczi] agrees that we should match the
RegexpQuery semantics of returning no results. I'll work on updating the patch.
> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no
> error, and all suggestions are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12308) LISTALIASES should return up to date response
[ https://issues.apache.org/jira/browse/SOLR-12308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466591#comment-16466591 ] Gus Heck commented on SOLR-12308: - Changes all look good to me :) > LISTALIASES should return up to date response > - > > Key: SOLR-12308 > URL: https://issues.apache.org/jira/browse/SOLR-12308 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: SOLR-12308.patch > > > The LISTALIASES command might return a stale response due to the default > eventual consistency of reads of ZooKeeper. I think if someone calls this > command (which generally won't be rapid-fire), they deserve an up to date > response. This is easily done with a one-liner; patch forthcoming. > Returning stale alias info is the only plausible explanation I have for why a > recent CI failure for AliasesIntegrationTest.tearDown() failed to detect > aliases to be deleted. It calls listAliases to know which aliases exist so it > can then delete them 1st. > [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/1833/] > tearDown then calls MiniSolrCloudCluster.deleteAllCollections() which > interestingly grabs a ZkStateReader.createClusterStateWatchersAndUpdate() > perhaps this ought to delete all aliases _as well_ since, after all, if there > were any aliases then well deleting all collections is bound to fail. Should > I file a separate issue or just handle this together? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk1.8.0_162) - Build # 1865 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1865/ Java: 64bit/jdk1.8.0_162 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([F0994C2055A8DF16:93527AA2CC67AC3B]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger(SearchRateTriggerTest.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13143 lines...] [junit4] Suite:
[JENKINS] Lucene-Solr-repro - Build # 588 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/588/ [...truncated 32 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/598/consoleText [repro] Revision: 7db633910424244356652944d4aca6184807faf6 [repro] Repro line: ant test -Dtestcase=NodeAddedTriggerTest -Dtests.method=testRestoreState -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=und -Dtests.timezone=America/Hermosillo -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testSplitIntegration -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Cancun -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] Repro line: ant test -Dtestcase=IndexSizeTriggerTest -Dtests.method=testTrigger -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=ja-JP -Dtests.timezone=America/Cancun -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 3e8f31ead006a1ed2ee744bc9b37723851c9dd22 [repro] git fetch [...truncated 2 lines...] [repro] git checkout 7db633910424244356652944d4aca6184807faf6 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] NodeAddedTriggerTest [repro] IndexSizeTriggerTest [repro] ant compile-test [...truncated 3316 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.NodeAddedTriggerTest|*.IndexSizeTriggerTest" -Dtests.showOutput=onerror -Dtests.seed=3AE1E401E324462C -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=und -Dtests.timezone=America/Hermosillo -Dtests.asserts=true -Dtests.file.encoding=US-ASCII [...truncated 7172 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.autoscaling.NodeAddedTriggerTest [repro] 4/5 failed: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest [repro] git checkout 3e8f31ead006a1ed2ee744bc9b37723851c9dd22 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-7.x - Build # 599 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/599/ 3 tests failed. FAILED: org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration Error Message: did not finish processing in time Stack Trace: java.lang.AssertionError: did not finish processing in time at __randomizedtesting.SeedInfo.seed([A8F5270D88239D33:FB4C65BD6A3208C9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) FAILED: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([A8F5270D88239D33:CB3E118F11ECEE1E]:0) at org.junit.Assert.fail(Assert.java:93)
[jira] [Commented] (SOLR-12320) Not all multi-part post requests should create tmp files.
[ https://issues.apache.org/jira/browse/SOLR-12320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466535#comment-16466535 ] Mark Miller commented on SOLR-12320: I will have to investigate some to be sure of much, but as far as I know, we currently write to a tmp file due to a File based implementation we pick from commons-fileupload. If Tika writes to a different temp file anyway, maybe it's as simple as changing that implementation, I'm not sure yet. We do currently clean up using this reaper thread class that we have copied from commons-fileupload due to needing some customizations. I really don't like it though - if we could do cleanup without a reaper thread always running in the background that would be great - or if we didn't need to write to a tmp file here at all. I don't know if we can avoid it entirely or not though. The only thing I could think of that might count on it is uploading very large files for tika to parse with Solr Cell. > Not all multi-part post requests should create tmp files. > - > > Key: SOLR-12320 > URL: https://issues.apache.org/jira/browse/SOLR-12320 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > > We create tmp files for multi-part posts because often they are uploaded > files for Solr cell or something but we also sometimes write params only or > params and updates as multi-part post. These should not create any tmp files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Solaris (64bit/jdk1.8.0) - Build # 603 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/603/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
11 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration
Error Message:
did not finish processing in time
Stack Trace:
java.lang.AssertionError: did not finish processing in time
at
__randomizedtesting.SeedInfo.seed([20867F412CBCAEC9:733F3DF1CEAD3B33]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testMergeIntegration(IndexSizeTriggerTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration
Error Message:
last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/84)={
"replicationFactor":"2", "pullReplicas":"0",
[jira] [Commented] (SOLR-12298) Index Full nested document Hierarchy For Queries (umbrella issue)
[ https://issues.apache.org/jira/browse/SOLR-12298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466517#comment-16466517 ] David Smiley commented on SOLR-12298: - bq. that will not prevent the need for a new JSON loader, since the current one requires the \_childDocument\_ to be added at each level. I'm not sure I understand you. Firstly, \_childDocument\_ isn't required; you could instead provide an array as a JSON value and it'll be assumed to contain multiple child documents. JsonLoaderTest.PARENT_TWO_CHILDREN_JSON demonstrates that. Secondly, I don't get the point/consequence of why this is a problem. Nevertheless, I can see that SolrInputDocument.getChildDocuments doesn't capture the nature of the relationship, plus some child docs may have a varying relationship. The JSON structure will usually have labels that are indicative of that relationship, like a "comments" array of child docs on a blog post, and perhaps an "author" child doc for the author of the post (if we imagine modeling it this way). Still; it'd be a shame if a solution here were fixed to JSON only, so I'm stubborn on going with an URP for at least part of this. Perhaps if the SolrInputDocument held optional contextual metadata populated by JsonLoader, then an URP could use this information. Lacking that information it could work in a general way (e.g. assume simply "child" relationship). Or... what if SolrInputDocument did not have an explicit \_childDocuments field list. What if a SolrInputDocument was simply a supported value inside SolrInputField? That would be a bigger change but may be a more appropriate fix, since adding the relationship after the fact (what we're talking about) could be seen a hack on top of SolrInputDocument which doesn't capture it natively when it should. I'll sleep on it. > Index Full nested document Hierarchy For Queries (umbrella issue) > - > > Key: SOLR-12298 > URL: https://issues.apache.org/jira/browse/SOLR-12298 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: mosh >Priority: Major > > Solr ought to have the ability to index deeply nested objects, while storing > the original document hierarchy. > Currently the client has to index the child document's full path and level > to manually reconstruct the original document structure, since the children > are flattened and returned in the reserved "__childDocuments__" key. > Ideally you could index a nested document, having Solr transparently add the > required fields while providing a document transformer to rebuild the > original document's hierarchy. > > This issue is an umbrella issue for the particular tasks that will make it > all happen – either subtasks or issue linking. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12328) Adding graph json facet domain change
[ https://issues.apache.org/jira/browse/SOLR-12328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Meehl updated SOLR-12328: Attachment: SOLR-12328.patch > Adding graph json facet domain change > - > > Key: SOLR-12328 > URL: https://issues.apache.org/jira/browse/SOLR-12328 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.3 >Reporter: Daniel Meehl >Priority: Major > Attachments: SOLR-12328.patch > > > Json facets now support join queries via domain change. I've made a > relatively small enhancement to add graph to the mix. I'll attach a patch for > your viewing. I'm hoping this can be merged into solr proper. Please let me > know if there are any problems/changes/requirements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12328) Adding graph json facet domain change
Daniel Meehl created SOLR-12328: --- Summary: Adding graph json facet domain change Key: SOLR-12328 URL: https://issues.apache.org/jira/browse/SOLR-12328 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Facet Module Affects Versions: 7.3 Reporter: Daniel Meehl Json facets now support join queries via domain change. I've made a relatively small enhancement to add graph to the mix. I'll attach a patch for your viewing. I'm hoping this can be merged into solr proper. Please let me know if there are any problems/changes/requirements. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466442#comment-16466442
]
Jan Høydahl commented on SOLR-8207:
---
{quote}One thing that's a little confusing still is the fact that clicking on
the numbers - which otherwise have no indication that they are clickable -
opens up the more detailed stats
{quote}
That's how things get when the whole table cell has an on-click action
attached. I plan to add some mouseover-bgcolor change to the whole row to
indicate that something will happen. But I'm not married to this click-anywhere
style. Could just as well replace this with a simple {{(expand details...)}}
link at the bottom of the "Node" column and a {{(expand details for all...)}}
link in the "Host" column. Or some graphical symbol.
I'd be thrilled if someone with a nose for the visuals could take a stab at
clarifying this and more...
> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
> Issue Type: Improvement
> Components: Admin UI
>Affects Versions: 5.3
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png,
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was
> making real use of SolrCloud, and when we didn't really know the use-cases we
> would need to support. I would argue that, whilst they are pretty (and
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
> * promote the tree tab to top level
> * remove the graph views and the dump tab
> * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and
> their associated replicas/collections. From this view, it would be possible
> to add/remove replicas and to see the status of nodes. It would also be
> possible to filter nodes by status: "show me only up nodes", "show me nodes
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission
> node" option, that would ensure that no replicas on this node are leaders,
> and then remove all replicas from the node, ready for it to be removed from
> the cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.3-Linux (64bit/jdk-9.0.4) - Build # 189 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.3-Linux/189/
Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC
6 tests failed.
FAILED: org.apache.solr.cloud.AddReplicaTest.test
Error Message:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:46597/solr","node_name":"127.0.0.1:46597_solr","state":"active","type":"NRT"}
Stack Trace:
java.lang.AssertionError:
core_node6:{"core":"addreplicatest_coll_shard1_replica_n5","base_url":"https://127.0.0.1:46597/solr","node_name":"127.0.0.1:46597_solr","state":"active","type":"NRT"}
at
__randomizedtesting.SeedInfo.seed([273761F71B89A3B3:AF635E2DB575CE4B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.apache.solr.cloud.AddReplicaTest.test(AddReplicaTest.java:84)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)
FAILED: org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts
Error
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466430#comment-16466430 ] Cassandra Targett commented on SOLR-8207: - I didn't get a chance to give feedback last week, but I agree with much that was said, and the new changes look good IMO. I do think the numbers are still a bit large, but the colors are a fine mitigation of that if you think they are better with a larger font. IOW, with the color variation I don't have strong opinions about it. Another couple years and I'll need the numbers that big anyway! One thing that's a little confusing still is the fact that clicking on the numbers - which otherwise have no indication that they are clickable - opens up the more detailed stats. My first intuition was to click the Node name which is clearly clickable, but that opens up the Solr Admin for that node. That's fine, but how do we tell the user there is more to the stats portion? Maybe a carat icon in the cell that holds the first metric that shows the cell expands? It would be too much maybe to have it in all 3 cells in one row, but the first one would get the point across that more is there, hopefully without being too cluttered. WDYT? > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #370: SOLR-12312: Change buf to not always use up 1...
Github user millerjeff0 closed the pull request at: https://github.com/apache/lucene-solr/pull/370 --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface
[ https://issues.apache.org/jira/browse/SOLR-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466415#comment-16466415 ] Cassandra Targett commented on SOLR-4052: - bq. Is this still wanted even now when we have config set API and "bin/solr zk cp" capabilities? I think if we want to minimize the user need to interact with ZK directly, we should instead think about how to make UIs that use our existing APIs (Configset API, Config API, Parameters API, etc.) and where we still have gaps to fill with new APIs. Implementing those would be a better use of our collective time and efforts, IMO. > Upload files to ZooKeeper from Solr Admin interface > --- > > Key: SOLR-4052 > URL: https://issues.apache.org/jira/browse/SOLR-4052 > Project: Solr > Issue Type: Improvement >Reporter: Eric Pugh >Priority: Major > Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch > > > It would be nice if you could add files to ZooKeeper through the solr admin > tool instead of having to use the zkCli. Steffan and I talked about this at > ApacheCon Euro, and he suggested that if I put the java code in place, he'll > put in the pretty GUI aspects! This patch is based around using a tool like > http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet. I > hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't > have a better sense of where it should go. A *very* annoying thing is that > it seems like from the browser side you can't select a directory of files and > upload it, which would make loading a new solr core configuration split > across many directory VERY annoying. Also, this doesn't really feel like a > solid solution to just pulling up a file in the ZK tree browser webpage, > editing it (maybe via a big text box) and then posting the contents back. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references
[
https://issues.apache.org/jira/browse/LUCENE-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466361#comment-16466361
]
ASF subversion and git services commented on LUCENE-8261:
-
Commit 572490088149e6fc498b1a1ca739f277c7364e00 in lucene-solr's branch
refs/heads/branch_7x from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5724900 ]
LUCENE-8261: non-recursive->recursive (javadoc update).
> InterpolatedProperties.interpolate and recursive property references
>
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
> java.lang.IllegalArgumentException: named capturing group is missing
> trailing '}'
> at
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements;
> they should be fixed strings (quoted verbatim)? So
> {{Pattern.quoteReplacement}} would be adequate here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references
[
https://issues.apache.org/jira/browse/LUCENE-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466362#comment-16466362
]
ASF subversion and git services commented on LUCENE-8261:
-
Commit 3e8f31ead006a1ed2ee744bc9b37723851c9dd22 in lucene-solr's branch
refs/heads/master from [~dawid.weiss]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3e8f31e ]
LUCENE-8261: non-recursive->recursive (javadoc update).
> InterpolatedProperties.interpolate and recursive property references
>
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
> java.lang.IllegalArgumentException: named capturing group is missing
> trailing '}'
> at
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements;
> they should be fixed strings (quoted verbatim)? So
> {{Pattern.quoteReplacement}} would be adequate here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references
[
https://issues.apache.org/jira/browse/LUCENE-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466358#comment-16466358
]
Dawid Weiss commented on LUCENE-8261:
-
Thanks Steve, I'll correct the Javadoc and commit it in.
> InterpolatedProperties.interpolate and recursive property references
>
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
> java.lang.IllegalArgumentException: named capturing group is missing
> trailing '}'
> at
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements;
> they should be fixed strings (quoted verbatim)? So
> {{Pattern.quoteReplacement}} would be adequate here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC
[ https://issues.apache.org/jira/browse/SOLR-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-12312. - Resolution: Fixed Fix Version/s: 7.4 > Replication's IndexFetcher buf size can be initialized smarter to not waste > RAM/GC > -- > > Key: SOLR-12312 > URL: https://issues.apache.org/jira/browse/SOLR-12312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Fix For: 7.4 > > Time Spent: 40m > Remaining Estimate: 0h > > IndexFetcher's constructor knows the size of the file it's going to transfer. > As-such, it ought to initialize the "buf" field to no larger than this size. > This has been shown to waste Java heap/GC in an environment with lots of > cores of small indexes and thus small files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8288) Context query with regex "." produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466340#comment-16466340
]
Jim Ferenczi commented on LUCENE-8288:
--
I attached a new patch that fixes the name of the option (preserveSep is the
correct option, preservePositionIncrements is for keeping holes when tokens are
removed by a filter). I'll commit next week if there is no objection.
> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch,
> LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator
> followed by SEP_LABEL
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from
> https://issues.apache.org/jira/browse/LUCENE-8287, where the
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past
> CompletionAnalyzer.SEP_LABEL, so the matching prefix in
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1864 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1864/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode
Error Message:
unexpected DELETENODE status:
{responseHeader={status=0,QTime=3},status={state=notfound,msg=Did not find
[search_rate_trigger3/37da35ec58f98T9hn4lq5d40l4kmq30kadte16t/0] in any tasks
queue}}
Stack Trace:
java.lang.AssertionError: unexpected DELETENODE status:
{responseHeader={status=0,QTime=3},status={state=notfound,msg=Did not find
[search_rate_trigger3/37da35ec58f98T9hn4lq5d40l4kmq30kadte16t/0] in any tasks
queue}}
at
__randomizedtesting.SeedInfo.seed([CE0FD220A5BC8799:EC9D1CA2927608E4]:0)
at org.junit.Assert.fail(Assert.java:93)
at
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.lambda$testDeleteNode$6(SearchRateTriggerIntegrationTest.java:668)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at
org.apache.solr.cloud.autoscaling.SearchRateTriggerIntegrationTest.testDeleteNode(SearchRateTriggerIntegrationTest.java:660)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
[jira] [Updated] (LUCENE-8288) Context query with regex "." produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Ferenczi updated LUCENE-8288:
-
Attachment: LUCENE-8288.patch
> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch,
> LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator
> followed by SEP_LABEL
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from
> https://issues.apache.org/jira/browse/LUCENE-8287, where the
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past
> CompletionAnalyzer.SEP_LABEL, so the matching prefix in
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1539 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1539/
2 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.IndexSizeTriggerTest.testSplitIntegration
Error Message:
last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
"replicationFactor":"2", "pullReplicas":"0",
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"false", "nrtReplicas":"2", "tlogReplicas":"0",
"autoCreated":"true", "shards":{ "shard2":{ "replicas":{
"core_node3":{
"core":"testSplitIntegration_collection_shard2_replica_n3",
"leader":"true", "SEARCHER.searcher.maxDoc":11,
"SEARCHER.searcher.deletedDocs":0, "INDEX.sizeInBytes":1,
"node_name":"127.0.0.1:10001_solr", "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":11}, "core_node4":{
"core":"testSplitIntegration_collection_shard2_replica_n4",
"SEARCHER.searcher.maxDoc":11, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:1_solr",
"state":"active", "type":"NRT",
"SEARCHER.searcher.numDocs":11}}, "range":"0-7fff",
"state":"active"}, "shard1":{ "stateTimestamp":"1525714553704979100",
"replicas":{ "core_node1":{
"core":"testSplitIntegration_collection_shard1_replica_n1",
"leader":"true", "SEARCHER.searcher.maxDoc":14,
"SEARCHER.searcher.deletedDocs":0, "INDEX.sizeInBytes":1,
"node_name":"127.0.0.1:10001_solr", "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":14}, "core_node2":{
"core":"testSplitIntegration_collection_shard1_replica_n2",
"SEARCHER.searcher.maxDoc":14, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:1_solr",
"state":"active", "type":"NRT",
"SEARCHER.searcher.numDocs":14}}, "range":"8000-",
"state":"inactive"}, "shard1_1":{ "parent":"shard1",
"stateTimestamp":"1525714553738107800", "range":"c000-",
"state":"active", "replicas":{ "core_node10":{
"leader":"true",
"core":"testSplitIntegration_collection_shard1_1_replica1",
"SEARCHER.searcher.maxDoc":6, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:1_solr",
"base_url":"http://127.0.0.1:1/solr;, "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":6},
"core_node9":{
"core":"testSplitIntegration_collection_shard1_1_replica0",
"SEARCHER.searcher.maxDoc":6, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:10001_solr",
"base_url":"http://127.0.0.1:10001/solr;, "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":6}}}, "shard1_0":{
"parent":"shard1", "stateTimestamp":"1525714553737785050",
"range":"8000-bfff", "state":"active", "replicas":{
"core_node7":{ "leader":"true",
"core":"testSplitIntegration_collection_shard1_0_replica0",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:10001_solr",
"base_url":"http://127.0.0.1:10001/solr;, "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":7},
"core_node8":{
"core":"testSplitIntegration_collection_shard1_0_replica1",
"SEARCHER.searcher.maxDoc":7, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1, "node_name":"127.0.0.1:1_solr",
"base_url":"http://127.0.0.1:1/solr;, "state":"active",
"type":"NRT", "SEARCHER.searcher.numDocs":7}
Stack Trace:
java.util.concurrent.TimeoutException: last state:
DocCollection(testSplitIntegration_collection//clusterstate.json/40)={
"replicationFactor":"2",
"pullReplicas":"0",
"router":{"name":"compositeId"},
"maxShardsPerNode":"2",
"autoAddReplicas":"false",
"nrtReplicas":"2",
"tlogReplicas":"0",
"autoCreated":"true",
"shards":{
"shard2":{
"replicas":{
"core_node3":{
"core":"testSplitIntegration_collection_shard2_replica_n3",
"leader":"true",
"SEARCHER.searcher.maxDoc":11,
"SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":1,
"node_name":"127.0.0.1:10001_solr",
"state":"active",
"type":"NRT",
[jira] [Resolved] (SOLR-4528) Implementation numShards option in admin interface
[ https://issues.apache.org/jira/browse/SOLR-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-4528. --- Resolution: Not A Problem > Implementation numShards option in admin interface > -- > > Key: SOLR-4528 > URL: https://issues.apache.org/jira/browse/SOLR-4528 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.1 >Reporter: Arkadi Colson >Priority: Major > > Currently it is possible to just start creating shards on nodes with the > admin interface without creating the collection first with the API. This way > of working creates a collection with having numShards = null in the zookeeper > config and giving trouble on updates. It would be great to have a numShards > field when creating the first shard/node of a collection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4052) Upload files to ZooKeeper from Solr Admin interface
[ https://issues.apache.org/jira/browse/SOLR-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466325#comment-16466325 ] Jan Høydahl commented on SOLR-4052: --- Is this still wanted even now when we have config set API and "bin/solr zk cp" capabilities? > Upload files to ZooKeeper from Solr Admin interface > --- > > Key: SOLR-4052 > URL: https://issues.apache.org/jira/browse/SOLR-4052 > Project: Solr > Issue Type: Improvement >Reporter: Eric Pugh >Priority: Major > Attachments: ZookeeperInfoServletTest.java, zookeeper_edit.patch > > > It would be nice if you could add files to ZooKeeper through the solr admin > tool instead of having to use the zkCli. Steffan and I talked about this at > ApacheCon Euro, and he suggested that if I put the java code in place, he'll > put in the pretty GUI aspects! This patch is based around using a tool like > http://blueimp.github.com/jQuery-File-Upload/ to upload to a java servlet. I > hung this code off the ZookeeperInfoServlet doPost method mostly b/c I didn't > have a better sense of where it should go. A *very* annoying thing is that > it seems like from the browser side you can't select a directory of files and > upload it, which would make loading a new solr core configuration split > across many directory VERY annoying. Also, this doesn't really feel like a > solid solution to just pulling up a file in the ZK tree browser webpage, > editing it (maybe via a big text box) and then posting the contents back. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC
[ https://issues.apache.org/jira/browse/SOLR-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466326#comment-16466326 ] ASF subversion and git services commented on SOLR-12312: Commit 93f9cc71b127b84c432bf40e115fd4afe689bd8a in lucene-solr's branch refs/heads/branch_7x from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93f9cc7 ] SOLR-12312: Replication's IndexFetcher buf size should be initialized to an amount no greater than the size of the file being transferred. (cherry picked from commit 81f6112) > Replication's IndexFetcher buf size can be initialized smarter to not waste > RAM/GC > -- > > Key: SOLR-12312 > URL: https://issues.apache.org/jira/browse/SOLR-12312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > IndexFetcher's constructor knows the size of the file it's going to transfer. > As-such, it ought to initialize the "buf" field to no larger than this size. > This has been shown to waste Java heap/GC in an environment with lots of > cores of small indexes and thus small files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12312) Replication's IndexFetcher buf size can be initialized smarter to not waste RAM/GC
[ https://issues.apache.org/jira/browse/SOLR-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466321#comment-16466321 ] ASF subversion and git services commented on SOLR-12312: Commit 81f611209c9b71b7538a46d047631ea164dc2a2c in lucene-solr's branch refs/heads/master from [~dsmiley] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=81f6112 ] SOLR-12312: Replication's IndexFetcher buf size should be initialized to an amount no greater than the size of the file being transferred. > Replication's IndexFetcher buf size can be initialized smarter to not waste > RAM/GC > -- > > Key: SOLR-12312 > URL: https://issues.apache.org/jira/browse/SOLR-12312 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: replication (java) >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Time Spent: 40m > Remaining Estimate: 0h > > IndexFetcher's constructor knows the size of the file it's going to transfer. > As-such, it ought to initialize the "buf" field to no larger than this size. > This has been shown to waste Java heap/GC in an environment with lots of > cores of small indexes and thus small files. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter
[
https://issues.apache.org/jira/browse/LUCENE-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466309#comment-16466309
]
David Smiley commented on LUCENE-8273:
--
Looks good Alan.
* Maybe make {{ConditionBuilder whenTerm(Predicate
predicate)}} even simpler by referring to CharSequence in the predicate instead
of CharTermAttribute? This is just a convenience method after all; and it keeps
the caller immune to some lower level details like Attributes. And it somewhat
prevents them from using mutable methods on CharTermAttribute which would be
pretty nasty.
> Add a ConditionalTokenFilter
>
>
> Key: LUCENE-8273
> URL: https://issues.apache.org/jira/browse/LUCENE-8273
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Alan Woodward
>Priority: Major
> Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch,
> LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch
>
>
> Spinoff of LUCENE-8265. It would be useful to be able to wrap a TokenFilter
> in such a way that it could optionally be bypassed based on the current state
> of the TokenStream. This could be used to, for example, only apply
> WordDelimiterFilter to terms that contain hyphens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON
[
https://issues.apache.org/jira/browse/SOLR-12327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Rosenthal resolved SOLR-12327.
Resolution: Not A Problem
Didn't realize that
*curl 'http://localhost:8983/solr/admin/info/system'*
will return pure JON with that information
> 'bin/solr status' should be able to produce output as pure JSON
> ---
>
> Key: SOLR-12327
> URL: https://issues.apache.org/jira/browse/SOLR-12327
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 7.2
>Reporter: Simon Rosenthal
>Priority: Minor
>
> The 'bin/solr status' command should optionally (so as not to break back
> compat) produce its outputs in pure JSON, for easier parsing, rather than a
> mixture of free text and JSON as it does at present.
> e.g.
> {{prompt# bin/solr status purejson}}
> {{ {}}
> {{# these two lines replace "Solr process on port "}}
> {{ *"solr_port":"8983",*}}
> {{ *"solr_pid":"14020",*}}
> {{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
> {{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu -
> 2018-01-10 00:54:21",}}
> {{ "startTime":"2018-05-02T13:51:43.388Z",}}
> {{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
> {{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
> {{ "cloud":{}}
> {{ "ZooKeeper":"localhost:9983",}}
> {{ "liveNodes":"1",}}
> {{ "collections":"1"
> The use case here is mapping a solr port (where that is the only available
> information about the Solr instance) to ZK host/port(s) for a subsequent call
> to zkcli.sh.
>
> {{ }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON
[
https://issues.apache.org/jira/browse/SOLR-12327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466234#comment-16466234
]
Simon Rosenthal edited comment on SOLR-12327 at 5/7/18 5:39 PM:
Didn't realize that
*curl 'http://localhost:8983/solr/admin/info/system'*
will return pure JSON with that information
was (Author: simon.rosenthal):
Didn't realize that
*curl 'http://localhost:8983/solr/admin/info/system'*
will return pure JON with that information
> 'bin/solr status' should be able to produce output as pure JSON
> ---
>
> Key: SOLR-12327
> URL: https://issues.apache.org/jira/browse/SOLR-12327
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
>Affects Versions: 7.2
>Reporter: Simon Rosenthal
>Priority: Minor
>
> The 'bin/solr status' command should optionally (so as not to break back
> compat) produce its outputs in pure JSON, for easier parsing, rather than a
> mixture of free text and JSON as it does at present.
> e.g.
> {{prompt# bin/solr status purejson}}
> {{ {}}
> {{# these two lines replace "Solr process on port "}}
> {{ *"solr_port":"8983",*}}
> {{ *"solr_pid":"14020",*}}
> {{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
> {{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu -
> 2018-01-10 00:54:21",}}
> {{ "startTime":"2018-05-02T13:51:43.388Z",}}
> {{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
> {{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
> {{ "cloud":{}}
> {{ "ZooKeeper":"localhost:9983",}}
> {{ "liveNodes":"1",}}
> {{ "collections":"1"
> The use case here is mapping a solr port (where that is the only available
> information about the Solr instance) to ZK host/port(s) for a subsequent call
> to zkcli.sh.
>
> {{ }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466226#comment-16466226
]
Julie Tibshirani edited comment on LUCENE-8287 at 5/7/18 5:37 PM:
--
I uploaded a patch that throws an IllegalArgumentException if an empty term is
passed to RegexCompletionQuery.
This approach certainly works, but I noticed that this behavior is a bit
inconsistent with a normal RegexpQuery, where an empty term is accepted, but
the query produces no results. [~jim.ferenczi] would it be better to have an
empty regex completion query return no results, or is the discrepancy not too
concerning to you?
was (Author: jtibshirani):
I uploaded a patch that throws an IllegalArgumentException if an empty term is
passed to RegexCompletionQuery.
This approach certainly works, but I just wanted to note that the behavior is a
bit inconsistent with a normal RegexpQuery, where an empty term is accepted,
but the query produces no results.
> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no
> error, and all suggestions are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466226#comment-16466226
]
Julie Tibshirani edited comment on LUCENE-8287 at 5/7/18 5:32 PM:
--
I uploaded a patch that throws an IllegalArgumentException if an empty term is
passed to RegexCompletionQuery.
This approach certainly works, but I just wanted to note that the behavior is a
bit inconsistent with a normal RegexpQuery, where an empty term is accepted,
but the query produces no results.
was (Author: jtibshirani):
I uploaded a patch that throws an IllegalArgumentException if an empty term is
passed to RegexCompletionQuery.
This approach certainly works, but I just wanted to note that the behavior is a
bit different in a normal RegexpQuery, where an empty term is accepted, but the
query produces no results.
> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no
> error, and all suggestions are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466226#comment-16466226
]
Julie Tibshirani commented on LUCENE-8287:
--
I uploaded a patch that throws an IllegalArgumentException if an empty term is
passed to RegexCompletionQuery.
This approach certainly works, but I just wanted to note that the behavior is a
bit different in a normal RegexpQuery, where an empty term is accepted, but the
query produces no results.
> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no
> error, and all suggestions are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8287) ContextQuery with empty RegexCompletionQuery produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julie Tibshirani updated LUCENE-8287:
-
Attachment: LUCENE-8287.patch
> ContextQuery with empty RegexCompletionQuery produces an assertion failure
> --
>
> Key: LUCENE-8287
> URL: https://issues.apache.org/jira/browse/LUCENE-8287
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8287-repro.patch, LUCENE-8287.patch
>
>
> When an empty RegexCompletionQuery is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with the context separator
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:296)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testEmptyRegexQuery(TestContextQuery.java:193)
> {code}
> This is a bit of an edge case, but may be concerning since without assertions
> enabled, you can go on to access IntsRef indices that are out of bounds.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testEmptyRegexQuery. Note that to reproduce, Java assertions
> must be enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testEmptyRegexQuery). In this case, there is no
> error, and all suggestions are returned.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466215#comment-16466215
]
Munendra S N commented on SOLR-12303:
-
[^SOLR-12303.patch]
I have added test when handleSelect=true(handleSelect=false is default previous
tests covers this case) and default is enabled/disabled
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12303) Subquery Doc transform doesn't inherit path from original request
[
https://issues.apache.org/jira/browse/SOLR-12303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N updated SOLR-12303:
Attachment: SOLR-12303.patch
> Subquery Doc transform doesn't inherit path from original request
> -
>
> Key: SOLR-12303
> URL: https://issues.apache.org/jira/browse/SOLR-12303
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Mikhail Khludnev
>Priority: Major
> Attachments: SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch, SOLR-12303.patch,
> SOLR-12303.patch
>
>
> {code:java}
> localhost:8983/solr/k_test/search?sort=score desc,uniqueId
> desc=AND=json={!parent which=parent_field:true score=max}({!edismax
> v=$origQuery})=false=uniqueId=score=_children_:[subquery]=uniqueId=false=parent_field&_children_.fl=uniqueId&_children_.fl=score&_children_.rows=3=false&_children_.q={!edismax
> qf=parentId v=$row.uniqueId}=1
> {code}
> For this request, even though the path is */search*, the subquery request
> would be fired on handler */select*.
> Subquery request should inherit the parent request handler and there should
> be an option to override this behavior. (option to override is already
> available by specifying *qt*)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12314) ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the solr.xml file
[
https://issues.apache.org/jira/browse/SOLR-12314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466208#comment-16466208
]
Varun Thacker commented on SOLR-12314:
--
CUSC is a SolrJ public API so as Mark pointed out we can simply omit the socket
timeout's and connection timeout's that the user is specifying in the
constructor.
In this approach when StreamingSolrClients creates a CUSC object to send data ,
we basically read the socket timeout's and connection timeout's from the
UpdateShardHandler / UpdateShardHandlerConfig and set it explicitly. If the
user has specifying none/only one of them then default values will be used for
the timeout's that weren't specified.
> ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the
> solr.xml file
> -
>
> Key: SOLR-12314
> URL: https://issues.apache.org/jira/browse/SOLR-12314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12314.patch, SOLR-12314.patch
>
>
> In ConcurrentUpdateSolrClient we create an HttpPost Request which allows you
> to set a request config. If the request config is not provided httpclient
> will use the default request config.
>
> {code:java}
> org.apache.http.client.config.RequestConfig.Builder requestConfigBuilder =
> HttpClientUtil.createDefaultRequestConfigBuilder();
> if (soTimeout != null) {
> requestConfigBuilder.setSocketTimeout(soTimeout);
> }
> if (connectionTimeout != null) {
> requestConfigBuilder.setConnectTimeout(connectionTimeout);
> }
> method.setConfig(requestConfigBuilder.build());{code}
> While creating the httpclient object we ensure that the default request is
> set with the properties we care about. This happens in
> HttpClientUtils#setupBuilder
> {code:java}
> RequestConfig requestConfig = requestConfigBuilder.build();
> HttpClientBuilder retBuilder =
> builder.setDefaultRequestConfig(requestConfig);{code}
> So there is no need to set a per request config
>
> Here is where the httpclient picks the request config is provided on the
> request itself :
> [https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L168]
>
> And if it's not provided it uses the default here :
> https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L148
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12314) ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the solr.xml file
[
https://issues.apache.org/jira/browse/SOLR-12314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-12314:
-
Attachment: SOLR-12314.patch
> ConcurrentUpdateSolrClient doesn't respect the timeout's defined in the
> solr.xml file
> -
>
> Key: SOLR-12314
> URL: https://issues.apache.org/jira/browse/SOLR-12314
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
> Attachments: SOLR-12314.patch, SOLR-12314.patch
>
>
> In ConcurrentUpdateSolrClient we create an HttpPost Request which allows you
> to set a request config. If the request config is not provided httpclient
> will use the default request config.
>
> {code:java}
> org.apache.http.client.config.RequestConfig.Builder requestConfigBuilder =
> HttpClientUtil.createDefaultRequestConfigBuilder();
> if (soTimeout != null) {
> requestConfigBuilder.setSocketTimeout(soTimeout);
> }
> if (connectionTimeout != null) {
> requestConfigBuilder.setConnectTimeout(connectionTimeout);
> }
> method.setConfig(requestConfigBuilder.build());{code}
> While creating the httpclient object we ensure that the default request is
> set with the properties we care about. This happens in
> HttpClientUtils#setupBuilder
> {code:java}
> RequestConfig requestConfig = requestConfigBuilder.build();
> HttpClientBuilder retBuilder =
> builder.setDefaultRequestConfig(requestConfig);{code}
> So there is no need to set a per request config
>
> Here is where the httpclient picks the request config is provided on the
> request itself :
> [https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L168]
>
> And if it's not provided it uses the default here :
> https://github.com/apache/httpcomponents-client/blob/4.5.3/httpclient/src/main/java/org/apache/http/impl/client/InternalHttpClient.java#L148
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12327) 'bin/solr status' should be able to produce output as pure JSON
Simon Rosenthal created SOLR-12327:
--
Summary: 'bin/solr status' should be able to produce output as
pure JSON
Key: SOLR-12327
URL: https://issues.apache.org/jira/browse/SOLR-12327
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: scripts and tools
Affects Versions: 7.2
Reporter: Simon Rosenthal
The 'bin/solr status' command should optionally (so as not to break back
compat) produce its outputs in pure JSON, for easier parsing, rather than a
mixture of free text and JSON as it does at present.
e.g.
{{prompt# bin/solr status purejson}}
{{ {}}
{{# these two lines replace "Solr process on port "}}
{{ *"solr_port":"8983",*}}
{{ *"solr_pid":"14020",*}}
{{ "solr_home":"/home/user/solr-7.2.1/server/solr",}}
{{ "version":"7.2.1 b2b6438b37073bee1fca40374e85bf91aa457c0b - ubuntu -
2018-01-10 00:54:21",}}
{{ "startTime":"2018-05-02T13:51:43.388Z",}}
{{ "uptime":"5 days, 2 hours, 39 minutes, 35 seconds",}}
{{ "memory":"1.2 GB (%25.7) of 4.8 GB",}}
{{ "cloud":{}}
{{ "ZooKeeper":"localhost:9983",}}
{{ "liveNodes":"1",}}
{{ "collections":"1"
The use case here is mapping a solr port (where that is the only available
information about the Solr instance) to ZK host/port(s) for a subsequent call
to zkcli.sh.
{{ }}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-12326) Unnecessary refinement requests
Yonik Seeley created SOLR-12326: --- Summary: Unnecessary refinement requests Key: SOLR-12326 URL: https://issues.apache.org/jira/browse/SOLR-12326 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Components: Facet Module Reporter: Yonik Seeley TestJsonFacets.testStatsDistrib() appears to result in more refinement requests than would otherwise be expected. Those tests were developed before refinement was implemented and hence do not need refinement to generate correct results due to limited numbers of buckets. This should be detectable by refinement code in the majority of cases to prevent extra work from being done. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.9
[
https://issues.apache.org/jira/browse/SOLR-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466170#comment-16466170
]
Varun Thacker commented on SOLR-12265:
--
Cool! I'll work on getting it upgraded now.
The "ReadPendingException" that I had mentioned on the Jira description is
likely still gonna remain a problem according to this discussion :
[https://dev.eclipse.org/mhonarc/lists/jetty-dev/msg03165.html]
But I feel it's worth upgrading to 9.4.10
> Upgrade Jetty to 9.4.9
> --
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8
> We're seeing this WARN very sporadically ( maybe one in every 100k requests )
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) -
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0
> of
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
> of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x
> and then in Jetty 9.4.9 this class has undergone quite a few changes
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
> .
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12170) terms facet on a date field can fail
[ https://issues.apache.org/jira/browse/SOLR-12170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466162#comment-16466162 ] Yonik Seeley commented on SOLR-12170: - Attached draft patch that seems to fix the issues I've found so far. > terms facet on a date field can fail > > > Key: SOLR-12170 > URL: https://issues.apache.org/jira/browse/SOLR-12170 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 6.6 >Reporter: Yonik Seeley >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-12170.patch > > > There are still some modes of failures when doing a terms facet on a date > field. This issue picks up from SOLR-12020 since the fixes likely won't make > it in time for the 7.3 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12170) terms facet on a date field can fail
[ https://issues.apache.org/jira/browse/SOLR-12170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-12170: Attachment: SOLR-12170.patch > terms facet on a date field can fail > > > Key: SOLR-12170 > URL: https://issues.apache.org/jira/browse/SOLR-12170 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 6.6 >Reporter: Yonik Seeley >Priority: Major > Fix For: 7.4 > > Attachments: SOLR-12170.patch > > > There are still some modes of failures when doing a terms facet on a date > field. This issue picks up from SOLR-12020 since the fixes likely won't make > it in time for the 7.3 release. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12265) Upgrade Jetty to 9.4.9
[
https://issues.apache.org/jira/browse/SOLR-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466130#comment-16466130
]
Michael Braun commented on SOLR-12265:
--
[~varunthacker] Jetty 9.4.10 is out -
https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.10.v20180503
> Upgrade Jetty to 9.4.9
> --
>
> Key: SOLR-12265
> URL: https://issues.apache.org/jira/browse/SOLR-12265
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3
>Reporter: Varun Thacker
>Assignee: Varun Thacker
>Priority: Major
>
> Solr 7.3 upgraded to Jetty 9.4.8
> We're seeing this WARN very sporadically ( maybe one in every 100k requests )
> on the replica when indexing.
> {code:java}
> date time WARN [qtp768306356-580185] ? (:) -
> java.nio.channels.ReadPendingException: null
> at org.eclipse.jetty.io.FillInterest.register(FillInterest.java:58)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractEndPoint.fillInterested(AbstractEndPoint.java:353)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection.fillInterested(AbstractConnection.java:134)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267)
> ~[jetty-server-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> ~[jetty-io-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:247)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:140)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:131)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:382)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:708)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:626)
> ~[jetty-util-9.4.8.v20171121.jar:9.4.8.v20171121]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0-zing_17.11.0.0]
> date time WARN [qtp768306356-580185] ? (:) - Read pending for
> org.eclipse.jetty.server.HttpConnection$BlockingReadCallback@2e98df28
> prevented AC.ReadCB@424271f8{HttpConnection@424271f8[p=HttpParser{s=START,0
> of
> -1},g=HttpGenerator@424273ae{s=START}]=>HttpChannelOverHttp@4242713d{r=141,c=false,a=IDLE,uri=null}<-DecryptedEndPoint@4242708d{/host:52824<->/host:port,OPEN,fill=FI,flush=-,to=1/86400}->HttpConnection@424271f8[p=HttpParser{s=START,0
> of -1},g=HttpGenerator@424273ae{s=START}]=>{code}
> When this happens the leader basically waits till it get's a
> SocketTimeoutException and then puts the replica into recovery.
> My motivation for upgrading to Jetty 9.4.9 is that the EatWhatYouKill was
> introduced in Jetty 9.4.x . I don't believe we saw this error in Jetty 9.3.x
> and then in Jetty 9.4.9 this class has undergone quite a few changes
> [https://github.com/eclipse/jetty.project/commit/0cb4f5629dca082eec943b94ec8ef4ca0d5f1aa4#diff-ae450a12d4eca85a437bd5082f698f48]
> .
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-8288) Context query with regex "." produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466115#comment-16466115
]
Julie Tibshirani edited comment on LUCENE-8288 at 5/7/18 4:42 PM:
--
Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're
hoping to use a "." regex completion query as part of an elasticsearch
enhancement
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].
was (Author: jtibshirani):
Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're
hoping to use a "." regex completion query as part of an elasticsearch ticket
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].
> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator
> followed by SEP_LABEL
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from
> https://issues.apache.org/jira/browse/LUCENE-8287, where the
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past
> CompletionAnalyzer.SEP_LABEL, so the matching prefix in
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8288) Context query with regex "." produces an assertion failure
[
https://issues.apache.org/jira/browse/LUCENE-8288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466115#comment-16466115
]
Julie Tibshirani commented on LUCENE-8288:
--
Thank you [~jim.ferenczi]! I'm looking forward to this fix going in, as we're
hoping to use a "." regex completion query as part of an elasticsearch ticket
([https://github.com/elastic/elasticsearch/issues/19147)|https://github.com/elastic/elasticsearch/issues/19147),].
> Context query with regex "." produces an assertion failure
> --
>
> Key: LUCENE-8288
> URL: https://issues.apache.org/jira/browse/LUCENE-8288
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Julie Tibshirani
>Priority: Major
> Attachments: LUCENE-8288-repro.patch, LUCENE-8288.patch
>
>
> When a RegexCompletionQuery of "." is provided to ContextQuery, the following
> assertion failure occurs:
> {code:java}
> java.lang.AssertionError: input should not end with a context separator
> followed by SEP_LABEL
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setInnerWeight(ContextQuery.java:299)
> at
> org.apache.lucene.search.suggest.document.ContextQuery$ContextCompletionWeight.setNextMatch(ContextQuery.java:275)
> at
> org.apache.lucene.search.suggest.document.NRTSuggester.lookup(NRTSuggester.java:221)
> at
> org.apache.lucene.search.suggest.document.CompletionScorer.score(CompletionScorer.java:70)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:78)
> at
> org.apache.lucene.search.suggest.document.SuggestIndexSearcher.suggest(SuggestIndexSearcher.java:58)
> at
> org.apache.lucene.search.suggest.document.TestContextQuery.testDotRegexQuery(TestContextQuery.java:188)
> {code}
> Note that this is a related, but distinct issue from
> https://issues.apache.org/jira/browse/LUCENE-8287, where the
> RegexCompletionQuery is empty.
> The attached patch provides a reproduction of the issue, as the test case
> TestContextQuery#testRegexDotQuery. To reproduce, Java assertions must be
> enabled (as in the default configuration for tests).
> The patch also provides a test case for the normal behavior of an empty
> RegexCompletionQuery, when it is not wrapped in ContextQuery
> (TestRegexCompletionQuery#testRegexDotQuery). In this case, there is no
> error, and all suggestions are returned.
> From a quick look, it seems as though "." doesn't capture any characters past
> CompletionAnalyzer.SEP_LABEL, so the matching prefix in
> ContextCompletionWeight#setInnerWeight is unexpectedly empty.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8261) InterpolatedProperties.interpolate and recursive property references
[
https://issues.apache.org/jira/browse/LUCENE-8261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466113#comment-16466113
]
Steve Rowe commented on LUCENE-8261:
Belated +1, [~dweiss], thanks for working on it!
One tiny nit: the class and {{load()}} methods' javadoc still say:
{code:java}
/**
* Parse a properties file, performing non-recursive Ant-like
* property value interpolation, and return the resulting Properties.
*/
[...]
/**
* Loads the properties file via {@link Properties#load(InputStream)},
* then performs non-recursive Ant-like property value interpolation.
*/
{code}
{{s/non-recursive/recursive/g}} ?
> InterpolatedProperties.interpolate and recursive property references
>
>
> Key: LUCENE-8261
> URL: https://issues.apache.org/jira/browse/LUCENE-8261
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: 7.4
>
> Attachments: LUCENE-8261.patch, LUCENE-8261.patch
>
>
> InterpolatedProperties is used in lib check tasks in the build file. I
> occasionally see this:
> {code}
> /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
> java.lang.IllegalArgumentException: named capturing group is missing
> trailing '}'
> at
> java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
> at
> java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
> at
> org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
> {code}
> I don't think we ever need to use any group references in those replacements;
> they should be fixed strings (quoted verbatim)? So
> {{Pattern.quoteReplacement}} would be adequate here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12323) Missing explain information
[
https://issues.apache.org/jira/browse/SOLR-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Langenmaier resolved SOLR-12323.
---
Resolution: Duplicate
> Missing explain information
> ---
>
> Key: SOLR-12323
> URL: https://issues.apache.org/jira/browse/SOLR-12323
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3
>Reporter: Stefan Langenmaier
>Priority: Major
>
> We have a problem in Solr 7.3 with the explain field when the edismax query
> parser is used with the boost parameter.
> To reproduce the issue I created a collection "mycollection" with the default
> configset and indexed the following csv data:
> {code:java}
> title_txt,rating_i
> mytext,2
> {code}
> When I issue the following query to analyse the computation of the score
> [http://localhost:8983/solr/mycollection/select?boost=rating_i=edismax=*,score,[explain]=title_txt:mytext]
>
> I receive the following response:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]",
> "boost":"rating_i"}},
> "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.5753642,
> "[explain]":"0.5753642 = product of:\n 1.0 = boost\n 0.5753642 =
> boost(int(rating_i))\n"}]
> }}
> {code}
> The explain no longer contains all the information of the score. For
> comparison with Solr 7.2.1 but otherwise the same setup the output looks like
> this:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]",
> "boost":"rating_i"}},
> "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"747b9102-0566-4786-a155-87fac10388cc",
> "_version_":1599803926880714752,
> "score":0.5753642,
> "[explain]":"0.5753642 = boost(title_txt:mytext,int(rating_i)),
> product of:\n 0.2876821 = weight(title_txt:mytext in 0) [SchemaSimilarity],
> result of:\n0.2876821 = score(doc=0,freq=1.0 = termFreq=1.0\n), product
> of:\n 0.2876821 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:\n1.0 = docFreq\n1.0 = docCount\n
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:\n1.0 = termFreq=1.0\n1.2
> = parameter k1\n0.75 = parameter b\n1.0 = avgFieldLength\n
> 1.0 = fieldLength\n 2.0 = int(rating_i)=2\n"}]
> }}
> {code}
> When the boost parameter gets remove Solr 7.3 also show the calculation again:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]"}},
> "response":{"numFound":1,"start":0,"maxScore":0.2876821,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.2876821,
> "[explain]":"0.2876821 = weight(title_txt:mytext in 0)
> [SchemaSimilarity], result of:\n 0.2876821 = score(doc=0,freq=1.0 =
> termFreq=1.0\n), product of:\n0.2876821 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n 1.0 = docFreq\n
> 1.0 = docCount\n1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq +
> k1 * (1 - b + b * fieldLength / avgFieldLength)) from:\n 1.0 =
> termFreq=1.0\n 1.2 = parameter k1\n 0.75 = parameter b\n 1.0 =
> avgFieldLength\n 1.0 = fieldLength\n"}]
> }}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12323) Missing explain information
[
https://issues.apache.org/jira/browse/SOLR-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466064#comment-16466064
]
Stefan Langenmaier commented on SOLR-12323:
---
This seems to be the same issue. I have the same problem with debugQuery=on.
> Missing explain information
> ---
>
> Key: SOLR-12323
> URL: https://issues.apache.org/jira/browse/SOLR-12323
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 7.3
>Reporter: Stefan Langenmaier
>Priority: Major
>
> We have a problem in Solr 7.3 with the explain field when the edismax query
> parser is used with the boost parameter.
> To reproduce the issue I created a collection "mycollection" with the default
> configset and indexed the following csv data:
> {code:java}
> title_txt,rating_i
> mytext,2
> {code}
> When I issue the following query to analyse the computation of the score
> [http://localhost:8983/solr/mycollection/select?boost=rating_i=edismax=*,score,[explain]=title_txt:mytext]
>
> I receive the following response:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]",
> "boost":"rating_i"}},
> "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.5753642,
> "[explain]":"0.5753642 = product of:\n 1.0 = boost\n 0.5753642 =
> boost(int(rating_i))\n"}]
> }}
> {code}
> The explain no longer contains all the information of the score. For
> comparison with Solr 7.2.1 but otherwise the same setup the output looks like
> this:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":3,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]",
> "boost":"rating_i"}},
> "response":{"numFound":1,"start":0,"maxScore":0.5753642,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"747b9102-0566-4786-a155-87fac10388cc",
> "_version_":1599803926880714752,
> "score":0.5753642,
> "[explain]":"0.5753642 = boost(title_txt:mytext,int(rating_i)),
> product of:\n 0.2876821 = weight(title_txt:mytext in 0) [SchemaSimilarity],
> result of:\n0.2876821 = score(doc=0,freq=1.0 = termFreq=1.0\n), product
> of:\n 0.2876821 = idf, computed as log(1 + (docCount - docFreq + 0.5) /
> (docFreq + 0.5)) from:\n1.0 = docFreq\n1.0 = docCount\n
> 1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b *
> fieldLength / avgFieldLength)) from:\n1.0 = termFreq=1.0\n1.2
> = parameter k1\n0.75 = parameter b\n1.0 = avgFieldLength\n
> 1.0 = fieldLength\n 2.0 = int(rating_i)=2\n"}]
> }}
> {code}
> When the boost parameter gets remove Solr 7.3 also show the calculation again:
> {code:java}
> {
> "responseHeader":{
> "status":0,
> "QTime":1,
> "params":{
> "q":"title_txt:mytext",
> "defType":"edismax",
> "fl":"*,score,[explain]"}},
> "response":{"numFound":1,"start":0,"maxScore":0.2876821,"docs":[
> {
> "title_txt":["mytext"],
> "rating_i":2,
> "id":"3a7299dc-9628-403b-935b-0ddf17e74897",
> "_version_":1599803310411350016,
> "score":0.2876821,
> "[explain]":"0.2876821 = weight(title_txt:mytext in 0)
> [SchemaSimilarity], result of:\n 0.2876821 = score(doc=0,freq=1.0 =
> termFreq=1.0\n), product of:\n0.2876821 = idf, computed as log(1 +
> (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n 1.0 = docFreq\n
> 1.0 = docCount\n1.0 = tfNorm, computed as (freq * (k1 + 1)) / (freq +
> k1 * (1 - b + b * fieldLength / avgFieldLength)) from:\n 1.0 =
> termFreq=1.0\n 1.2 = parameter k1\n 0.75 = parameter b\n 1.0 =
> avgFieldLength\n 1.0 = fieldLength\n"}]
> }}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12243) Edismax missing phrase queries when phrases contain multiterm synonyms
[ https://issues.apache.org/jira/browse/SOLR-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466049#comment-16466049 ] Shawn Heisey commented on SOLR-12243: - I have not been following code changes on this issue. But I have been seeing frequent failures in Solr tests even with a completely unmodified code checkout. This is what Erick is trying to fix with his recent work on tests. Until tests reach the point where they pass on virtually all runs, test failures in the automatic patch validation are to be expected, and it's not straightforward to know whether they indicate a problem in the patch. That DOES mean that automatic patch validation isn't as useful as it could be. The problem is known and is not being ignored. > Edismax missing phrase queries when phrases contain multiterm synonyms > -- > > Key: SOLR-12243 > URL: https://issues.apache.org/jira/browse/SOLR-12243 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: query parsers >Affects Versions: 7.1 > Environment: RHEL, MacOS X > Do not believe this is environment-specific. >Reporter: Elizabeth Haubert >Priority: Major > Attachments: SOLR-12243.patch, SOLR-12243.patch, SOLR-12243.patch, > SOLR-12243.patch > > Time Spent: 10m > Remaining Estimate: 0h > > synonyms.txt: > allergic, hypersensitive > aspirin, acetylsalicylic acid > dog, canine, canis familiris, k 9 > rat, rattus > request handler: > > > > edismax > 0.4 > title^100 > title~20^5000 > title~11 > title~22^1000 > text > > 3-1 6-3 930% > *:* > 25 > > > Phrase queries (pf, pf2, pf3) containing "dog" or "aspirin" against the > above list will not be generated. > "allergic reaction dog" will generate pf2: "allergic reaction", but not > pf:"allergic reaction dog", pf2: "reaction dog", or pf3: "allergic reaction > dog" > "aspirin dose in rats" will generate pf3: "dose ? rats" but not pf2: "aspirin > dose" or pf3:"aspirin dose ?" > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12309) CloudSolrClient.Builder constructors are not well documented
[
https://issues.apache.org/jira/browse/SOLR-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466035#comment-16466035
]
Shawn Heisey commented on SOLR-12309:
-
I can understand the desire to not have lots of constructors. We're using the
fluent paradigm, so the most straighforward option is only one constructor --
the one with no arguments. Complexity can then happen in the fluent methods,
making confusion a lot less likely. We could have signatures like these, where
using one of them is required before build() will work:
* withZkHosts(List zkHosts)
* withZkHosts(List zkHosts, String chroot)
* withZkConnectString(String connectString)
* withUrls(List urls)
> CloudSolrClient.Builder constructors are not well documented
>
>
> Key: SOLR-12309
> URL: https://issues.apache.org/jira/browse/SOLR-12309
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Priority: Minor
>
> I was having a lot of trouble figuring out how to create a CloudSolrClient
> object without using deprecated code.
> The no-arg constructor on the Builder object is deprecated, and the two
> remaining methods have similar signatures to each other. It is not at all
> obvious how to successfully call the one that uses ZooKeeper to connect. The
> javadoc is silent on the issue. I did finally figure it out with a lot of
> googling, and I would like to save others the hassle.
> I believe that this is what the javadoc for the third ctor should say:
>
> Provide a series of ZooKeeper hosts which will be used when configuring
> CloudSolrClient instances. Optionally, include a chroot to be used when
> accessing the ZooKeeper database.
> Here are a couple of examples. The first one has no chroot, the second one
> does:
> new CloudSolrClient.Builder(zkHosts, Optional.empty())
> new CloudSolrClient.Builder(zkHosts, Optional.of("/solr"))
>
> The javadoc for the URL-based method should probably say something to
> indicate that it is easy to confuse with the ZK-based method.
> I have not yet looked at the current reference guide to see if that has any
> clarification.
> Is it a good idea to completely eliminate the ability to create a cloud
> client using a single string that matches the zkHost value used when starting
> Solr in cloud mode?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8273) Add a ConditionalTokenFilter
[ https://issues.apache.org/jira/browse/LUCENE-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466012#comment-16466012 ] Alan Woodward commented on LUCENE-8273: --- Patch, up to date with master and passing all tests and precommit. I think this is ready? > Add a ConditionalTokenFilter > > > Key: LUCENE-8273 > URL: https://issues.apache.org/jira/browse/LUCENE-8273 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Priority: Major > Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, > LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch > > > Spinoff of LUCENE-8265. It would be useful to be able to wrap a TokenFilter > in such a way that it could optionally be bypassed based on the current state > of the TokenStream. This could be used to, for example, only apply > WordDelimiterFilter to terms that contain hyphens. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8273) Add a ConditionalTokenFilter
[ https://issues.apache.org/jira/browse/LUCENE-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-8273: -- Attachment: LUCENE-8273.patch > Add a ConditionalTokenFilter > > > Key: LUCENE-8273 > URL: https://issues.apache.org/jira/browse/LUCENE-8273 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Alan Woodward >Priority: Major > Attachments: LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, > LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch, LUCENE-8273.patch > > > Spinoff of LUCENE-8265. It would be useful to be able to wrap a TokenFilter > in such a way that it could optionally be bypassed based on the current state > of the TokenStream. This could be used to, for example, only apply > WordDelimiterFilter to terms that contain hyphens. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1863 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1863/ Java: 32bit/jdk1.8.0_162 -client -XX:+UseParallelGC 1 tests failed. FAILED: org.apache.solr.search.TestRealTimeGet.testStressGetRealtime Error Message: Captured an uncaught exception in thread: Thread[id=6, name=WRITER8, state=RUNNABLE, group=TGRP-TestRealTimeGet] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=6, name=WRITER8, state=RUNNABLE, group=TGRP-TestRealTimeGet] at __randomizedtesting.SeedInfo.seed([DA5670AD607B5B92:40587ACF46083830]:0) Caused by: java.lang.RuntimeException: org.apache.solr.common.SolrException: Exception writing document id 15 to the index; possible analysis error. at __randomizedtesting.SeedInfo.seed([DA5670AD607B5B92]:0) at org.apache.solr.search.TestRealTimeGet$1.run(TestRealTimeGet.java:706) Caused by: org.apache.solr.common.SolrException: Exception writing document id 15 to the index; possible analysis error. at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:246) at org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67) at org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) at org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:950) at org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1163) at org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:633) at org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.handleAdds(JsonLoader.java:501) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.processUpdate(JsonLoader.java:145) at org.apache.solr.handler.loader.JsonLoader$SingleThreadedJsonLoader.load(JsonLoader.java:121) at org.apache.solr.handler.loader.JsonLoader.load(JsonLoader.java:84) at org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199) at org.apache.solr.core.SolrCore.execute(SolrCore.java:2510) at org.apache.solr.servlet.DirectSolrConnection.request(DirectSolrConnection.java:125) at org.apache.solr.SolrTestCaseJ4.updateJ(SolrTestCaseJ4.java:1286) at org.apache.solr.SolrTestCaseJ4.addAndGetVersion(SolrTestCaseJ4.java:1451) at org.apache.solr.search.TestRealTimeGet$1.run(TestRealTimeGet.java:675) Caused by: java.lang.NullPointerException at org.apache.solr.update.UpdateLog.getCurrentLogSizeFromStream(UpdateLog.java:299) at org.apache.solr.update.DirectUpdateHandler2.getCurrentTLogSize(DirectUpdateHandler2.java:1007) at org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:291) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:234) ... 18 more Build Log: [...truncated 13766 lines...] [junit4] Suite: org.apache.solr.search.TestRealTimeGet [junit4] 2> Creating dataDir: /home/jenkins/workspace/Lucene-Solr-7.x-Linux/solr/build/solr-core/test/J0/temp/solr.search.TestRealTimeGet_DA5670AD607B5B92-001/init-core-data-001 [junit4] 2> 1131492 WARN (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 startTrackingSearchers: numOpens=18 numCloses=18 [junit4] 2> 1131492 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=true [junit4] 2> 1131493 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (true) via: @org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN) [junit4] 2> 1131493 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 1131493 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 updateLog impl=solr.CdcrUpdateLog [junit4] 2> 1131494 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 1131494 INFO (SUITE-TestRealTimeGet-seed#[DA5670AD607B5B92]-worker) [] o.a.s.c.SolrResourceLoader [null] Added 2 libs to classloader, from paths:
[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk-9.0.4) - Build # 580 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/580/ Java: 64bit/jdk-9.0.4 -XX:-UseCompressedOops -XX:+UseParallelGC 26 tests failed. FAILED: org.apache.solr.handler.component.DistributedSpellCheckComponentTest.test Error Message: Error from server at https://127.0.0.1:61294//collection1: Directory (MMapDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedSpellCheckComponentTest_5FBD132F0CB9CD72-001\tempDir-001\control\cores\collection1\data\spellchecker1 lockFactory=org.apache.lucene.store.NativeFSLockFactory@20774dbd) still has pending deleted files; cannot initialize IndexWriter Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at https://127.0.0.1:61294//collection1: Directory (MMapDirectory@C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J0\temp\solr.handler.component.DistributedSpellCheckComponentTest_5FBD132F0CB9CD72-001\tempDir-001\control\cores\collection1\data\spellchecker1 lockFactory=org.apache.lucene.store.NativeFSLockFactory@20774dbd) still has pending deleted files; cannot initialize IndexWriter at __randomizedtesting.SeedInfo.seed([5FBD132F0CB9CD72:D7E92CF5A245A08A]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:643) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:194) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942) at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957) at org.apache.solr.handler.component.DistributedSpellCheckComponentTest.q(DistributedSpellCheckComponentTest.java:67) at org.apache.solr.handler.component.DistributedSpellCheckComponentTest.test(DistributedSpellCheckComponentTest.java:146) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsRepeatStatement.callStatement(BaseDistributedSearchTestCase.java:1019) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at
[jira] [Commented] (SOLR-12309) CloudSolrClient.Builder constructors are not well documented
[
https://issues.apache.org/jira/browse/SOLR-12309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465984#comment-16465984
]
Shawn Heisey commented on SOLR-12309:
-
I'm not saying that the use of Optional was bad. Just that I couldn't figure
it out how to use it by looking at the Builder javadoc. I had to go searching
for docs on Optional -- it was a object type I had never encountered before. I
suspect that this will be relatively common.
A java developer gets to know the more basic objects really quickly and they
become second nature. Things like Optional are not so common. Of course we
can't provide documentation for EVERY native object we use, but when we use
something outside what developers use every day, we ought to provide some
simple examples.
At first I just tried a List with the individual zkHost values in it,
which naturally failed, because it tried to interpret those strings as URLs. I
hadn't even quite noticed that the URL-based constructor was there when I did
this. I was using my IDE's language-specific capabilities to find the
constructor, not reading the javadocs directly. When I did a closer
examination of the javadoc after that trial didn't work, I saw my mistake, but
still didn't know how to actually create an Optional object to use the correct
constructor.
I think I did try "null" for the Optional argument. If I did, I don't remember
what the error for that was. I can see what it does.
The Optional could have been replaced with a simple String value to
differentiate it from the URL-based constructor. Most java developers already
know how to deal with String.
I'm curious why the no-arg constructor and the fluent methods for providing the
ZK definition were deprecated. The Fluent paradigm that the builders use is
pretty straightforward and still present, so that still seems like a relevant
way to use the builder.
> CloudSolrClient.Builder constructors are not well documented
>
>
> Key: SOLR-12309
> URL: https://issues.apache.org/jira/browse/SOLR-12309
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
>Affects Versions: 7.3
>Reporter: Shawn Heisey
>Priority: Minor
>
> I was having a lot of trouble figuring out how to create a CloudSolrClient
> object without using deprecated code.
> The no-arg constructor on the Builder object is deprecated, and the two
> remaining methods have similar signatures to each other. It is not at all
> obvious how to successfully call the one that uses ZooKeeper to connect. The
> javadoc is silent on the issue. I did finally figure it out with a lot of
> googling, and I would like to save others the hassle.
> I believe that this is what the javadoc for the third ctor should say:
>
> Provide a series of ZooKeeper hosts which will be used when configuring
> CloudSolrClient instances. Optionally, include a chroot to be used when
> accessing the ZooKeeper database.
> Here are a couple of examples. The first one has no chroot, the second one
> does:
> new CloudSolrClient.Builder(zkHosts, Optional.empty())
> new CloudSolrClient.Builder(zkHosts, Optional.of("/solr"))
>
> The javadoc for the URL-based method should probably say something to
> indicate that it is easy to confuse with the ZK-based method.
> I have not yet looked at the current reference guide to see if that has any
> clarification.
> Is it a good idea to completely eliminate the ability to create a cloud
> client using a single string that matches the zkHost value used when starting
> Solr in cloud mode?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/371#discussion_r186447413
--- Diff:
solr/core/src/test/org/apache/solr/search/json/TestJsonRequest.java ---
@@ -401,4 +396,180 @@ public static void doJsonRequest(Client client,
boolean isDistrib) throws Except
}
+ public static void doJsonRequestWithTag(Client client) throws Exception {
--- End diff --
I haven't seen the test for tagging just string like
``` "filter": ["title:solr"]``` -> ``` "filter":
[{"#drag":"title:solr"}]```
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/371#discussion_r186446692
--- Diff:
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder,
Object val, boolean isQPars
"Error when parsing json query, expect only one query parser
here, but found : "+map.keySet());
}
String qtype = map.keySet().iterator().next();
+ String qTypeTrimmed = qtype.trim();
+ String tagName = null;
+ if (qTypeTrimmed.startsWith("#")) {
--- End diff --
and what if not? Do we have a test which verify that violating this syntax
triggers an exception?
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/371#discussion_r186446157 --- Diff: solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java --- @@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder, Object val, boolean isQPars "Error when parsing json query, expect only one query parser here, but found : "+map.keySet()); } String qtype = map.keySet().iterator().next(); + String qTypeTrimmed = qtype.trim(); --- End diff -- Not sure why to trim. Makes no sense from my pow. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/371#discussion_r186445658
--- Diff:
solr/core/src/test/org/apache/solr/search/json/TestJsonRequest.java ---
@@ -25,20 +25,20 @@
import org.junit.BeforeClass;
import org.junit.Test;
-@LuceneTestCase.SuppressCodecs({"Lucene3x","Lucene40","Lucene41","Lucene42","Lucene45","Appending"})
+@LuceneTestCase.SuppressCodecs({"Lucene3x", "Lucene40", "Lucene41",
"Lucene42", "Lucene45", "Appending"})
--- End diff --
Please don't format the code.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/371#discussion_r186445542
--- Diff:
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -77,7 +84,10 @@ private void buildLocalParams(StringBuilder builder,
Object val, boolean isQPars
if (useSubBuilder) subBuilder = new StringBuilder();
- subBuilder = subBuilder.append("{!").append(qtype).append(' ');;
+ if (tagName != null) {
+subBuilder.append("{!tag=").append(tagName).append("}");
--- End diff --
I believe it should be quoted to avoid problems with spaces inside of tags.
Also, would you mind to embed tag in the same ```{! }``` qparser, rather
than wrap. I'm afraid of some edgecases.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request #371: SOLR-9685 tag a query in JSON syntax
Github user m-khl commented on a diff in the pull request:
https://github.com/apache/lucene-solr/pull/371#discussion_r186444765
--- Diff:
solr/core/src/java/org/apache/solr/request/json/JsonQueryConverter.java ---
@@ -69,6 +69,13 @@ private void buildLocalParams(StringBuilder builder,
Object val, boolean isQPars
"Error when parsing json query, expect only one query parser
here, but found : "+map.keySet());
}
String qtype = map.keySet().iterator().next();
+ String qTypeTrimmed = qtype.trim();
+ String tagName = null;
+ if (qTypeTrimmed.startsWith("#")) {
+tagName = qTypeTrimmed.substring(1);
--- End diff --
I suppose it makes more sense to keep hash in tag just to make it more
noticeable and explicit.
---
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 215 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/215/ 1 tests failed. FAILED: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger Error Message: expected:<1> but was:<2> Stack Trace: java.lang.AssertionError: expected:<1> but was:<2> at __randomizedtesting.SeedInfo.seed([2BF31B11BE1CE9D:61740733822EBDB0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.autoscaling.SearchRateTriggerTest.testTrigger(SearchRateTriggerTest.java:133) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 15457 lines...] [junit4] Suite: org.apache.solr.cloud.autoscaling.SearchRateTriggerTest [junit4] 2> 8438141 INFO
[jira] [Commented] (LUCENE-8298) Allow DocValues updates to reset a value
[ https://issues.apache.org/jira/browse/LUCENE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465964#comment-16465964 ] Simon Willnauer commented on LUCENE-8298: - I attached a patch for discussion. I need to do some cleanups, more tests and clarify javadocs but it shows the idea > Allow DocValues updates to reset a value > > > Key: LUCENE-8298 > URL: https://issues.apache.org/jira/browse/LUCENE-8298 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8298.patch > > > Today once a document has a value in a certain DV field this values > can only be changed but not removed. While resetting / removing a value > from a field is certainly a corner case it can be used to undelete a > soft-deleted document unless it's merged away. > This allows to rollback changes without rolling back to another > commitpoint > or trashing all uncommitted changes. In certain cenarios it can be used to > "repair" history of documents in distributed systems. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8298) Allow DocValues updates to reset a value
[ https://issues.apache.org/jira/browse/LUCENE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-8298: Attachment: LUCENE-8298.patch > Allow DocValues updates to reset a value > > > Key: LUCENE-8298 > URL: https://issues.apache.org/jira/browse/LUCENE-8298 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 7.4, master (8.0) >Reporter: Simon Willnauer >Priority: Major > Fix For: 7.4, master (8.0) > > Attachments: LUCENE-8298.patch > > > Today once a document has a value in a certain DV field this values > can only be changed but not removed. While resetting / removing a value > from a field is certainly a corner case it can be used to undelete a > soft-deleted document unless it's merged away. > This allows to rollback changes without rolling back to another > commitpoint > or trashing all uncommitted changes. In certain cenarios it can be used to > "repair" history of documents in distributed systems. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-8298) Allow DocValues updates to reset a value
Simon Willnauer created LUCENE-8298: --- Summary: Allow DocValues updates to reset a value Key: LUCENE-8298 URL: https://issues.apache.org/jira/browse/LUCENE-8298 Project: Lucene - Core Issue Type: Improvement Affects Versions: 7.4, master (8.0) Reporter: Simon Willnauer Fix For: 7.4, master (8.0) Today once a document has a value in a certain DV field this values can only be changed but not removed. While resetting / removing a value from a field is certainly a corner case it can be used to undelete a soft-deleted document unless it's merged away. This allows to rollback changes without rolling back to another commitpoint or trashing all uncommitted changes. In certain cenarios it can be used to "repair" history of documents in distributed systems. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12324) handling numeric fields in uniqueBlock(id) aggregation for JSON Facet
[ https://issues.apache.org/jira/browse/SOLR-12324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-12324: Summary: handling numeric fields in uniqueBlock(id) aggregation for JSON Facet (was: handling numeric fields in uniqueBlock(id)) > handling numeric fields in uniqueBlock(id) aggregation for JSON Facet > - > > Key: SOLR-12324 > URL: https://issues.apache.org/jira/browse/SOLR-12324 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.4 >Reporter: Mikhail Khludnev >Priority: Minor > > Now it trows exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-12324) handling numeric fields in uniqueBlock(id)
[ https://issues.apache.org/jira/browse/SOLR-12324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Khludnev updated SOLR-12324: Component/s: Facet Module > handling numeric fields in uniqueBlock(id) > -- > > Key: SOLR-12324 > URL: https://issues.apache.org/jira/browse/SOLR-12324 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Facet Module >Affects Versions: 7.4 >Reporter: Mikhail Khludnev >Priority: Minor > > Now it trows exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
