[GitHub] [lucene-solr] atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search
atris commented on issue #823: LUCENE-8939: Introduce Shared Count Early Termination In Parallel Search URL: https://github.com/apache/lucene-solr/pull/823#issuecomment-526540019 Thanks @jimczi ! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13728) Fail partial updates if it would inadvertently remove nested docs
[
https://issues.apache.org/jira/browse/SOLR-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919466#comment-16919466
]
Lucene/Solr QA commented on SOLR-13728:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 58s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 47m
39s{color} | {color:green} core in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 38s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-13728 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12978939/SOLR-13728.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 / 6dea678 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/543/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/543/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Fail partial updates if it would inadvertently remove nested docs
> -
>
> Key: SOLR-13728
> URL: https://issues.apache.org/jira/browse/SOLR-13728
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Attachments: SOLR-13728.patch
>
>
> In SOLR-12638 Solr gained the ability to do partial updates (aka atomic
> updates) to nested documents. However this feature only works if the schema
> meets certain circumstances. We can know we don't support it and fail the
> request – what I propose here. This is much friendlier than wiping out
> existing documents.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy closed pull request #745: SOLR-13122: Ability to query aliases in Solr Admin UI
janhoy closed pull request #745: SOLR-13122: Ability to query aliases in Solr Admin UI URL: https://github.com/apache/lucene-solr/pull/745 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919490#comment-16919490 ] ASF subversion and git services commented on SOLR-13122: Commit 52be32d4addbead8536dbde84ed8c80af4993b8b in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=52be32d ] SOLR-13122: Ability to query aliases in Solr Admin UI > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-master - Build # 3649 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3649/
All tests passed
Build Log:
[...truncated 63909 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj237353181
[ecj-lint] Compiling 1289 source files to /tmp/ecj237353181
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 232)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 628)
[ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new
PeerSyncWithLeader(core,
[ecj-lint]^^
[ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
(at line 186)
[ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith,
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true,
peerSyncOnlyWithActive, false);
[ecj-lint]
[ecj-lint] Resource leak: 'peerSync' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 726)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 195 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/195/ No tests ran. Build Log: [...truncated 24871 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2594 links (2120 relative) to 3410 anchors in 259 files [echo] Validated Links & Anchors via: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.3.0.tgz into /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure:
[jira] [Updated] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dr Oleg Savrasov updated SOLR-6930: --- Attachment: SOLR-6930.patch > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-8758:
-
Fix Version/s: (was: 8.x)
8.3
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks Amish.
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.3
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919512#comment-16919512 ] Rodney Aaron Stainback commented on SOLR-13434: --- Just curious if there is a target release for this feature, would really like it. > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13729) Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide
Erick Erickson created SOLR-13729: - Summary: Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide Key: SOLR-13729 URL: https://issues.apache.org/jira/browse/SOLR-13729 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson Assignee: Erick Erickson I was asked "where do we point out that schemaless isn't recommended for production?" and realized about the only place it comes up that a user can reasonable be expected to see is when you use bin/solr to create a collection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919672#comment-16919672 ] Tomoko Uchida commented on SOLR-13691: -- Updated the patch. Will commit it to the master in shortly. > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, SOLR-13691.patch, Screenshot from > 2019-08-30 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919581#comment-16919581
]
ASF subversion and git services commented on LUCENE-8758:
-
Commit ea67d9c8c65c6c883ef2ebb3c061fcc6b251a360 in lucene-solr's branch
refs/heads/master from Amish Shah
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ea67d9c ]
LUCENE-8758 Remove unused fields in QuadPrefixTree
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: SOLR-13691.patch > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, SOLR-13691.patch, Screenshot from > 2019-08-30 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-13122. Resolution: Fixed > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13122) Ability to query aliases in Solr Admin UI
[ https://issues.apache.org/jira/browse/SOLR-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919500#comment-16919500 ] ASF subversion and git services commented on SOLR-13122: Commit e8c2b6af2abfe86196e15ebefc25337bb8536b1c in lucene-solr's branch refs/heads/branch_8x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e8c2b6a ] SOLR-13122: Ability to query aliases in Solr Admin UI (cherry picked from commit 52be32d4addbead8536dbde84ed8c80af4993b8b) > Ability to query aliases in Solr Admin UI > - > > Key: SOLR-13122 > URL: https://issues.apache.org/jira/browse/SOLR-13122 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Reporter: mosh >Assignee: Jan Høydahl >Priority: Major > Labels: UI > Fix For: 8.3 > > Attachments: alias-collection-menu-selected.png, > alias-collection-view.png, alias-collections-menu.png, > alias-collections-menu.png, alias-delete-dialogue.png, alias-dropdown.png, > alias-properties.png, alias-select-double.png, alias-view.png, > new-collection-dropdown.png, new-oll-overview.png > > Time Spent: 20m > Remaining Estimate: 0h > > After having recently toyed with Time Routed Alias in SolrCloud, > we have noticed there is no way to query an alias from the admin UI, > since the combo box only contains the current collection in the cluster. > Solr Admin UI ought to have a way to query these aliases, for better > convenience. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8758) Class Field levelN is not populated correctly in QuadPrefixTree
[
https://issues.apache.org/jira/browse/LUCENE-8758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919588#comment-16919588
]
ASF subversion and git services commented on LUCENE-8758:
-
Commit f3b2358bc73b688341920d1753aecc39e6a9494a in lucene-solr's branch
refs/heads/branch_8x from Amish Shah
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3b2358 ]
LUCENE-8758 Remove unused fields in QuadPrefixTree
(cherry picked from commit ea67d9c8c65c6c883ef2ebb3c061fcc6b251a360)
> Class Field levelN is not populated correctly in QuadPrefixTree
> ---
>
> Key: LUCENE-8758
> URL: https://issues.apache.org/jira/browse/LUCENE-8758
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial-extras
>Affects Versions: 4.0, 5.0, 6.0, 7.0, 8.0
>Reporter: Dominic Page
>Assignee: David Smiley
>Priority: Trivial
> Labels: beginner
> Fix For: 8.x
>
> Attachments: LUCENE-8758.patch
>
>
> QuadPrefixTree in Lucene prepopulates these arrays:
> {{levelW = new double[maxLevels];}}
> {{levelH = new double[maxLevels];}}
> {{*levelS = new int[maxLevels];*}}
> {{*levelN = new int[maxLevels];*}}
> Like this
> {{for (int i = 1; i < levelW.length; i++) {}}
> {{ levelW[i] = levelW[i - 1] / 2.0;}}
> {{ levelH[i] = levelH[i - 1] / 2.0;}}
> {{ *levelS[i] = levelS[i - 1] * 2;*}}
> {{ *levelN[i] = levelN[i - 1] * 4;*}}
> {{}}}
> The field
> {{levelN[]}}
> overflows after level 14 = 1073741824 where maxLevels is limited to
> {{MAX_LEVELS_POSSIBLE = 50;}}
> The field levelN appears not to be used anywhere. Likewise, the field
> {{levelS[] }}
> is only used in the
> {{printInfo}}
> method. I would propose either to remove both
> {{levelN[],}}{{levelS[]}}
> or to change the datatype
> {{levelN = new long[maxLevels];}}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[ https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919491#comment-16919491 ] Dr Oleg Savrasov commented on SOLR-6930: Patch is reworked to use Request Parameters API in order to modify Memory Circuit Breaker configuration on the fly. > Provide "Circuit Breakers" For Expensive Solr Queries > - > > Key: SOLR-6930 > URL: https://issues.apache.org/jira/browse/SOLR-6930 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Mike Drob >Priority: Major > Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch, > SOLR-6930.patch > > > Ref: > http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html > ES currently allows operators to configure "circuit breakers" to preemptively > fail queries that are estimated too large rather than allowing an OOM > Exception to happen. We might be able to do the same thing. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[
https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919526#comment-16919526
]
Dr Oleg Savrasov commented on SOLR-6930:
Request Parameters are supposed to be configured like
{code:java}
{"params":{
"circuit.breaker":{
"circuit.breaker.enabled":"true",
"threshold.unInvertedField":"30%",
"":{"v":0}
}
}}{code}
> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Mike Drob
>Priority: Major
> Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch,
> SOLR-6930.patch
>
>
> Ref:
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively
> fail queries that are estimated too large rather than allowing an OOM
> Exception to happen. We might be able to do the same thing.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11185) Make DIH work with Schemaless mode.
[ https://issues.apache.org/jira/browse/SOLR-11185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11185. --- Resolution: Duplicate > Make DIH work with Schemaless mode. > --- > > Key: SOLR-11185 > URL: https://issues.apache.org/jira/browse/SOLR-11185 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, Data-driven Schema, Schema > and Analysis >Reporter: Kshitij Shukla >Priority: Minor > Labels: features > > Hello Everyone, > Hope you are all doing well. > Recently I have trying to make work a solr schemaless configuration with > DIH(mysql 5.6). After working on it around 4-5 Hrs I realized that schemaless > with DIH wont work. It might be my assumptions and chances are any of you > might know a way to make them together work. If so, please let me know how, > if not can this be treated as the improvement? > Best regards -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Labels: package (was: )
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: package
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul reassigned SOLR-13722:
-
Assignee: Noble Paul
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide blob upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Summary: A cluster-wide blob upload package option (was: A cluster-wide
upload package option)
> A cluster-wide blob upload package option
> -
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13722) A cluster-wide upload package option
[
https://issues.apache.org/jira/browse/SOLR-13722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-13722:
--
Description:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/blob
{code}
This does the following operations
* Upload this jar to all the live nodes in the system
Subsequently, when a node is started, it tries to get all the available blobs
from one of the live nodes where it is available.
was:
This ticket totally eliminates the need for an external service to host the
jars. So a url will no longer be required.
Add a jar to cluster as follows
{code:java}
curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
@myjar.jar http://localhost:8983/api/cluster/package/mypkg
{code}
This does the following operations
* Check if a package {{mypkg}} is already available , if yes , it is
equivalent to an {{update-package}} command. if not, this is like an
{{add-package}}
* Upload this jar to all the live nodes in the system
* Creates a package called {{mypkg}} with appropriate sha256
the end-point {{/api/cluster/package}} to list all the available packages
Subsequently, when a node is started, it tries to get all the available
packages from one of the live nodes where it is available.
> A cluster-wide upload package option
>
>
> Key: SOLR-13722
> URL: https://issues.apache.org/jira/browse/SOLR-13722
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> This ticket totally eliminates the need for an external service to host the
> jars. So a url will no longer be required.
>
> Add a jar to cluster as follows
> {code:java}
> curl -X POST -H 'Content-Type: application/octet-stream' --data-binary
> @myjar.jar http://localhost:8983/api/cluster/blob
> {code}
> This does the following operations
> * Upload this jar to all the live nodes in the system
>
> Subsequently, when a node is started, it tries to get all the available blobs
> from one of the live nodes where it is available.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13729) Add the caution that schemaless is not suitable for production to the "Schemaless Mode" section of the ref guide
[ https://issues.apache.org/jira/browse/SOLR-13729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-13729: -- Attachment: SOLR-13729.patch Status: Open (was: Open) Proposed wording for discouraging schemaless mode. I'll check it in over the weekend unless there are objections. > Add the caution that schemaless is not suitable for production to the > "Schemaless Mode" section of the ref guide > > > Key: SOLR-13729 > URL: https://issues.apache.org/jira/browse/SOLR-13729 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-13729.patch > > > I was asked "where do we point out that schemaless isn't recommended for > production?" and realized about the only place it comes up that a user can > reasonable be expected to see is when you use bin/solr to create a collection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6930) Provide "Circuit Breakers" For Expensive Solr Queries
[
https://issues.apache.org/jira/browse/SOLR-6930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16911237#comment-16911237
]
Dr Oleg Savrasov edited comment on SOLR-6930 at 8/30/19 12:47 PM:
--
Our customers very often experience OOM because of caching too large
UnInvertedField items. This happens when they try to count facets or sort by
not docvalues field. We don't want to fully disable UnInvertedFields usage
because in some cases they work better than docvalues. For example, if the
field is sparse and defined just in a few documents out of the millions, it
seems better to create and cache relatively small UnInvertedField rather than
traverse full docvalues structure. So to prevent OOM we need a kind of circuit
breaker which would count memory utilized by UnInvertedField items and forbid
caching them, when some configured threshold is exceeded. As you can see, with
such an approach we are not trying to predict memory consumption, we're just
restricting UnInvertedField cache by consumed memory.
Since such a breakers try to control memory usage, ideally they should be part
of some Global Resource Manager, see
https://issues.apache.org/jira/browse/SOLR-13578. But we don't have such a
manager so far, so for the time being we've tried to rely on existing Metric
framework. Memory consumption is controlled by custom MetricReporter, so to
enable circuit breaker it's necessary to configure appropriate unInvertedField
metric reporter in solr.xml, for example:
{code:java}
20%
{code}
was (Author: osavrasov):
Our customers very often experience OOM because of caching too large
UnInvertedField items. This happens when they try to count facets or sort by
not docvalues field. We don't want to fully disable UnInvertedFields usage
because in some cases they work better than docvalues. For example, if the
field is sparse and defined just in a few documents out of the millions, it
seems better to create and cache relatively small UnInvertedField rather than
traverse full docvalues structure. So to prevent OOM we need a kind of circuit
breaker which would count memory utilized by UnInvertedField items and forbid
caching them, when some configured threshold is exceeded. As you can see, with
such an approach we are not trying to predict memory consumption, we're just
restricting UnInvertedField cache by consumed memory.
Since such a breakers try to control memory usage, ideally they should be part
of some Global Resource Manager, see
https://issues.apache.org/jira/browse/SOLR-13578. But we don't have such a
manager so far, so for the time being we've tried to rely on existing Metric
framework. Memory consumption is controlled by custom MetricReporter, so to
enable circuit breaker it's necessary to configure appropriate unInvertedField
metric reporter in solr.xml, for example:
{code:java}
20%
{code}
> Provide "Circuit Breakers" For Expensive Solr Queries
> -
>
> Key: SOLR-6930
> URL: https://issues.apache.org/jira/browse/SOLR-6930
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Mike Drob
>Priority: Major
> Attachments: SOLR-6930.patch, SOLR-6930.patch, SOLR-6930.patch,
> SOLR-6930.patch
>
>
> Ref:
> http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html
> ES currently allows operators to configure "circuit breakers" to preemptively
> fail queries that are estimated too large rather than allowing an OOM
> Exception to happen. We might be able to do the same thing.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-NightlyTests-master - Build # 77 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-NightlyTests-master/77/ 2 tests failed. FAILED: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat.testSparseLongNumericsVsStoredFields 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([3DEA610DC88B642E]:0) FAILED: junit.framework.TestSuite.org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([3DEA610DC88B642E]:0) Build Log: [...truncated 7915 lines...] [junit4] Suite: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat [junit4] 2> ao?t 30, 2019 1:02:21 PM com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate [junit4] 2> WARNING: Suite execution timed out: org.apache.lucene.codecs.simpletext.TestSimpleTextDocValuesFormat [junit4] 2>1) Thread[id=11, name=JUnit4-serializer-daemon, state=TIMED_WAITING, group=main] [junit4] 2> at java.base@11.0.1/java.lang.Thread.sleep(Native Method) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.events.Serializer$1.run(Serializer.java:50) [junit4] 2>2) Thread[id=1, name=main, state=WAITING, group=main] [junit4] 2> at java.base@11.0.1/java.lang.Object.wait(Native Method) [junit4] 2> at java.base@11.0.1/java.lang.Thread.join(Thread.java:1305) [junit4] 2> at java.base@11.0.1/java.lang.Thread.join(Thread.java:1379) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:639) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:496) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:269) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:394) [junit4] 2> at app//com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:13) [junit4] 2>3) Thread[id=762, name=TEST-TestSimpleTextDocValuesFormat.testSparseLongNumericsVsStoredFields-seed#[3DEA610DC88B642E], state=TIMED_WAITING, group=TGRP-TestSimpleTextDocValuesFormat] [junit4] 2> at java.base@11.0.1/java.lang.Object.wait(Native Method) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.doWait(IndexWriter.java:4672) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1997) [junit4] 2> at app//org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1923) [junit4] 2> at app//org.apache.lucene.index.RandomIndexWriter.forceMerge(RandomIndexWriter.java:500) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1250) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.doTestNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1207) [junit4] 2> at app//org.apache.lucene.index.BaseDocValuesFormatTestCase.testSparseLongNumericsVsStoredFields(BaseDocValuesFormatTestCase.java:1417) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [junit4] 2> at java.base@11.0.1/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2> at java.base@11.0.1/java.lang.reflect.Method.invoke(Method.java:566) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) [junit4] 2> at app//com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) [junit4] 2> at app//org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) [junit4] 2> at app//org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) [junit4] 2> at app//org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) [junit4] 2> at app//org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) [junit4]
[GitHub] [lucene-solr] megancarey opened a new pull request #850: SOLR-13727: Bug fix for V2Request handling in HttpSolrClient
megancarey opened a new pull request #850: SOLR-13727: Bug fix for V2Request handling in HttpSolrClient URL: https://github.com/apache/lucene-solr/pull/850 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I am authorized to contribute this code to the ASF and have removed any code I do not have a license to distribute. - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 461 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/461/ 1 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing Error Message: Solr11035BandAid failed, counts differ after updates: expected:<199> but was:<200> Stack Trace: java.lang.AssertionError: Solr11035BandAid failed, counts differ after updates: expected:<199> but was:<200> at __randomizedtesting.SeedInfo.seed([15B345B130871AD:B422DF8C146EE9E9]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.SolrTestCaseJ4.Solr11035BandAid(SolrTestCaseJ4.java:3144) at org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:405) at org.apache.solr.cloud.ReindexCollectionTest.doTestSameTargetReindexing(ReindexCollectionTest.java:166) at org.apache.solr.cloud.ReindexCollectionTest.testSameTargetReindexing(ReindexCollectionTest.java:158) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) 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:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) 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
[JENKINS] Lucene-Solr-Tests-master - Build # 3652 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3652/
All tests passed
Build Log:
[...truncated 63924 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj286057262
[ecj-lint] Compiling 1289 source files to /tmp/ecj286057262
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 232)
[ecj-lint] ReplicationHandler replicationHandler = (ReplicationHandler)
handler;
[ecj-lint]^^
[ecj-lint] Resource leak: 'replicationHandler' is never closed
[ecj-lint] --
[ecj-lint] 3. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/RecoveryStrategy.java
(at line 628)
[ecj-lint] PeerSyncWithLeader peerSyncWithLeader = new
PeerSyncWithLeader(core,
[ecj-lint]^^
[ecj-lint] Resource leak: 'peerSyncWithLeader' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
(at line 186)
[ecj-lint] PeerSync peerSync = new PeerSync(core, syncWith,
core.getUpdateHandler().getUpdateLog().getNumRecordsToKeep(), true,
peerSyncOnlyWithActive, false);
[ecj-lint]
[ecj-lint] Resource leak: 'peerSync' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/CoreContainer.java
(at line 726)
[ecj-lint] SolrFieldCacheBean fieldCacheBean = new SolrFieldCacheBean();
[ecj-lint]^^
[ecj-lint] Resource leak: 'fieldCacheBean' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 19)
[ecj-lint] import javax.naming.Context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 9. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 20)
[ecj-lint] import javax.naming.InitialContext;
[ecj-lint]^^^
[ecj-lint] The type javax.naming.InitialContext is not accessible
[ecj-lint] --
[ecj-lint] 10. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
(at line 21)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 11. ERROR in
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-master/solr/core/src/java/org/apache/solr/core/SolrResourceLoader.java
payload text is parsed in a backward order
I followed https://lucidworks.com/post/end-to-end-payload-example-in-solr/ to
add a payload field for my solr schema and found out that the
DelimitedPayloadTokenFilter used to parse payload input is parsing it in
a backward order, which will let it always find the first delimiter ('|' in
my case) to split on, which will result in parsing error for inputs like
"abc|def|0.5" (`def|0.5` is not a float). And it makes sense if my key for
this payload happen to contain a '|'. Is it possible to change it to split
on the last delimiter or provide an option for this as the sub-string after
the last delimiter is guaranteed to be a payload score?
Many thanks,
W
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1946 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1946/ No tests ran. Build Log: [...truncated 25 lines...] ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/test-data org.tmatesoft.svn.core.SVNException: svn: E175002: connection refused by the server svn: E175002: OPTIONS request failed on '/repos/asf/lucene/test-data' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:112) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:96) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:765) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:340) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:910) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:702) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:113) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1035) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:164) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getRevisionNumber(SvnNgRepositoryAccess.java:119) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:43) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:831) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:26) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:11) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1239) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at hudson.scm.subversion.CheckoutUpdater$SubversionUpdateTask.perform(CheckoutUpdater.java:133) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:176) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:168) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:1041) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:1017) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:990) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3086) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:744) Caused by: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at org.tmatesoft.svn.core.internal.util.SVNSocketConnection.run(SVNSocketConnection.java:57) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:345) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
[jira] [Created] (SOLR-13730) payload text is parsed in a backward order
Weijie Wang created SOLR-13730:
--
Summary: payload text is parsed in a backward order
Key: SOLR-13730
URL: https://issues.apache.org/jira/browse/SOLR-13730
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: query parsers
Affects Versions: 8.2
Reporter: Weijie Wang
I followed
[this|[https://lucidworks.com/post/end-to-end-payload-example-in-solr/]] to add
a payload field for my solr schema and find out that
DelimitedPayloadTokenFilter used to parse payload input is parsing it in a
backward order, which will let it always find the first delimiter ('|' in my
case) to split on, which will result in parsing error for inputs like
"abc|def|0.5" (`def|0.5` is not a float). And it makes sense if my key for this
payload happen to contain a '|'. Is it possible to change it to split on the
last delimiter or provide an option for this as the sub-string after the last
delimiter is guaranteed to be a payload score?
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[
https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16919243#comment-16919243
]
Tomoko Uchida commented on SOLR-13691:
--
Here is the patch [^SOLR-13691.patch] including only changes for
{{analyzers.adoc}}. Other files - {{tokenizers.adoc}},
{{filter-descriptions.adoc}}, and so on - would need to be updated in a similar
way.
Is there any good methods to automatically convert them...
> Add example field type configurations using "name" attributes to Ref Guide
> --
>
> Key: SOLR-13691
> URL: https://issues.apache.org/jira/browse/SOLR-13691
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Reporter: Tomoko Uchida
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13691.patch, Screenshot from 2019-08-30
> 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png
>
>
> This is a follow-up task for SOLR-13593.
> To encourage users to use the "name" attribute in field type configurations,
> we should add examples that includes "name" instead of "class" (and mark
> "Legacy" to the old examples).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13691) Add example field type configurations using "name" attributes to Ref Guide
[ https://issues.apache.org/jira/browse/SOLR-13691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomoko Uchida updated SOLR-13691: - Attachment: SOLR-13691.patch > Add example field type configurations using "name" attributes to Ref Guide > -- > > Key: SOLR-13691 > URL: https://issues.apache.org/jira/browse/SOLR-13691 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-13691.patch, Screenshot from 2019-08-30 > 14-19-01.png, Screenshot from 2019-08-30 14-19-09.png > > > This is a follow-up task for SOLR-13593. > To encourage users to use the "name" attribute in field type configurations, > we should add examples that includes "name" instead of "class" (and mark > "Legacy" to the old examples). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
