[jira] [Commented] (SOLR-14516) NPE during Realtime GET
[
https://issues.apache.org/jira/browse/SOLR-14516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158910#comment-17158910
]
Munendra S N commented on SOLR-14516:
-
Thanks for the review.
[~noble.paul]
should we remove the null checked added in the previous commit? JSONWriter
already supports writing null value. In StatsComponent, the response value
could be {{null}} which is already handled.
once you confirm, I will update the patch with the changes and add javadocs as
suggested
> NPE during Realtime GET
> ---
>
> Key: SOLR-14516
> URL: https://issues.apache.org/jira/browse/SOLR-14516
> Project: Solr
> Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Attachments: SOLR-14516.patch, SOLR-14516.patch
>
>
> The exact reason is unknown. But the following is the stacktrace
>
> o.a.s.s.HttpSolrCall null:java.lang.NullPointerException\n\tat
> org.apache.solr.common.util.JsonTextWriter.writeStr(JsonTextWriter.java:83)\n\tat
> org.apache.solr.schema.StrField.write(StrField.java:101)\n\tat
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:124)\n\tat
>
> org.apache.solr.response.JSONWriter.writeSolrDocument(JSONWriter.java:106)\n\tat
>
> org.apache.solr.response.TextResponseWriter.writeSolrDocumentList(TextResponseWriter.java:170)\n\tat
>
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:147)\n\tat
>
> org.apache.solr.common.util.JsonTextWriter.writeNamedListAsMapWithDups(JsonTextWriter.java:386)\n\tat
>
> org.apache.solr.common.util.JsonTextWriter.writeNamedList(JsonTextWriter.java:292)\n\tat
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1669: SOLR-14151 Make schema components load from packages
dsmiley commented on a change in pull request #1669:
URL: https://github.com/apache/lucene-solr/pull/1669#discussion_r455511455
##
File path: solr/core/src/java/org/apache/solr/core/ConfigSet.java
##
@@ -79,4 +75,14 @@ public NamedList getProperties() {
public boolean isTrusted() {
return trusted;
}
+
+ /**Provide a Schema object on demand
Review comment:
https://google.github.io/styleguide/javaguide.html#s7-javadoc
Glad to see this supplier though.
##
File path:
solr/core/src/java/org/apache/solr/pkg/PackageListeningClassLoader.java
##
@@ -35,7 +35,7 @@
* This class would register a listener each package that is loaded through
this
* if any of those packages are updated , the onReload runnable is executed
* */
-public class MultiPackageListener implements SolrClassLoader ,
PackageListeners.Listener {
+public class PackageListeningClassLoader implements SolrClassLoader ,
PackageListeners.Listener {
Review comment:
Good name.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1669: SOLR-14151 Make schema components load from packages
dsmiley commented on a change in pull request #1669: URL: https://github.com/apache/lucene-solr/pull/1669#discussion_r455510065 ## File path: solr/core/src/java/org/apache/solr/core/SolrCore.java ## @@ -191,6 +191,11 @@ private String name; private String logid; // used to show what name is set + /** + * A unique id to differentiate multiple instances of the same core + * If we reload a core, the name remains same , but the id will be new + */ + public final UUID uniqueId = UUID.randomUUID(); Review comment: Okay... but the AtomicLong incrementAndGet technique is _very_ common for for an internal-id use case (I could list others in Lucene/Solr). I have not seen a UUID used yet for this. Up to you. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley opened a new pull request #1675: SOLR-14652: SolrCore should hold its own CoreDescriptor
dsmiley opened a new pull request #1675: URL: https://github.com/apache/lucene-solr/pull/1675 https://issues.apache.org/jira/browse/SOLR-14652 (minor refactoring) Also: * SolrCore's constructors don't need a "name" since it's guaranteed to always be the name in the coreDescriptor. I checked. * SolrCore's constructor shouldn't call coreContainer.solrCores.addCoreDescriptor(cd); because it's the container's responsibility to manage such things. I made SolrCores.putCore ensure the descriptor is added, and this is called by CoreContainer.registerCore which is called after new SolrCore instances are created. * solrCore.setName should only be called when we expect the name to change. Furthermore that shouldn't ever happen in SolrCloud so I added checks. * solrCore.setName calls coreMetricManager.afterCoreSetName() which is something that is really only related to a rename, not name initialization (from the constructor). I renamed that method and further only call it if the name did change from non-null. CC @sigram @ErickErickson you might want to do a code review based on your past interactions with the CoreContainer/CoreDescriptor/SolrCores/SolrCore relationship. I'm doubtful this deserves a CHANGES.txt entry; invisible to users and is relatively minor. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14652) SolrCore should hold its own CoreDescriptor
David Smiley created SOLR-14652:
---
Summary: SolrCore should hold its own CoreDescriptor
Key: SOLR-14652
URL: https://issues.apache.org/jira/browse/SOLR-14652
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: David Smiley
Assignee: David Smiley
SolrCore.getCoreDescriptor() surprisingly must do
{{coreContainer.getCoreDescriptor(name)}} instead of simply return a field on
itself. I think it's more sane that a SolrCore hold onto its own descriptor
making it unequivocally clear it will get it. I've seen a transient-core edge
case where it didn't, though I don't want to classify this issue as a bug fix
over that.
Also:
* SolrCore's constructors don't need a "name" since it's guaranteed to always
be the name in the coreDescriptor. I checked.
* SolrCore's constructor shouldn't call
{{coreContainer.solrCores.addCoreDescriptor(cd);}} because it's the container's
responsibility to manage such things. I made SolrCores.putCore ensure the
descriptor is added, and this is called by CoreContainer.registerCore which is
called after new SolrCore instances are created.
* solrCore.setName should only be called when we expect the name to change.
Furthermore that shouldn't ever happen in SolrCloud so I added checks.
* solrCore.setName calls {{coreMetricManager.afterCoreSetName()}} which is
something that is really only related to a _rename_, not name initialization
(from the constructor). I renamed that method and further only call it if the
name did change from non-null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1669: SOLR-14151 Make schema components load from packages
noblepaul commented on a change in pull request #1669: URL: https://github.com/apache/lucene-solr/pull/1669#discussion_r455476821 ## File path: solr/core/src/java/org/apache/solr/core/SolrCore.java ## @@ -191,6 +191,11 @@ private String name; private String logid; // used to show what name is set + /** + * A unique id to differentiate multiple instances of the same core + * If we reload a core, the name remains same , but the id will be new + */ + public final UUID uniqueId = UUID.randomUUID(); Review comment: UUID is cheap and there is no advantage in using something else. Cores are not created so frequently that we should care too much about it 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158834#comment-17158834
]
Mark Robert Miller commented on SOLR-14636:
---
Oh baby, for a while I kept saying these tests are still slow while they were
getting much much faster then the current tests - the current tests being darn
varyingly slow even after years and years of speeding them up - but now I will
stop saying that. These tests are close to fast. An order of magnitude faster
than I have ever seen for any similar software. That is, if this branch and
master raced, master is in a wheel chair with no wheels and I have a space
ship.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158825#comment-17158825 ] ASF subversion and git services commented on SOLR-13939: Commit b394bf7d2d69647a5d414a35c0cf4de5b314b449 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b394bf7 ] SOLR-13939: Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort. Attmept to fix Windows disk full issues > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158826#comment-17158826 ] ASF subversion and git services commented on SOLR-13939: Commit 9c2e7819eecca48230ba623ab34cb9baf64901f5 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9c2e781 ] SOLR-13939: Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort. Attmept to fix Windows disk full issues > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158792#comment-17158792 ] Erick Erickson edited comment on SOLR-13939 at 7/16/20, 12:06 AM: -- As per the mailing list response, I think I've found the "smoking gun", I'll push a change in a bit. In ShardLeaderElectionContextBase.java a number of calls like: new Path(leaderPath).getParent().toString(); were replaced with Paths.get(leaderPath).getParent().toString(); But the first is a call to a hadoop class that has special Windows handling to add a leading slash (not even a backslash!) and the nio Paths class doesn't do anything similar. I think it's wrong to rely on this behavior from org.apache.hadoop.fs.Path in a class having nothing at all to do with hdfs, (we're constructing Zookeeper paths) but in the interest of getting Windows working again I'll just revert that file. I've added comments so we won't trip up here again unknowingly. Since I don't have a Windows machine to test with, I'll fix/push later this evening UTC-5 and we'll have to see tomorrow whether it fixes the various Jenkins jobs. was (Author: erickerickson): As per the mailing list response, I think I've found the "smoking gun", I'll push a change in a bit. In ShardLeaderElectionContextBase.java a number of calls like: new Path(leaderPath).getParent().toString(); were replaced with Paths.get(leaderPath).getParent().toString(); But the first is a call to a hadoop class that has special Windows handling to add a leading slash (not even a backslash!) and the nio Paths class doesn't do anything similar. I think it's wrong to rely on this behavior from org.apache.hadoop.fs.Path in a class having nothing at all to do with hdfs, (we're constructing Zookeeper paths) but in the interest of getting Windows working again I'll just revert that file. I've added comments so we won't trip up here again unknowingly. Since I don't have a Windows machine to test with, I'll fix/push and we'll have to see tomorrow whether it's really the fix. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158792#comment-17158792 ] Erick Erickson commented on SOLR-13939: --- As per the mailing list response, I think I've found the "smoking gun", I'll push a change in a bit. In ShardLeaderElectionContextBase.java a number of calls like: new Path(leaderPath).getParent().toString(); were replaced with Paths.get(leaderPath).getParent().toString(); But the first is a call to a hadoop class that has special Windows handling to add a leading slash (not even a backslash!) and the nio Paths class doesn't do anything similar. I think it's wrong to rely on this behavior from org.apache.hadoop.fs.Path in a class having nothing at all to do with hdfs, (we're constructing Zookeeper paths) but in the interest of getting Windows working again I'll just revert that file. I've added comments so we won't trip up here again unknowingly. Since I don't have a Windows machine to test with, I'll fix/push and we'll have to see tomorrow whether it's really the fix. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158746#comment-17158746 ] Erick Erickson commented on SOLR-13939: --- [~uschindler] I just looked over that code and don't see any changes I can imagine caused this. That may just mean I lack imagination though. The changes are several, but almost all annotations (SuppressWarnings and Deprecated). The other major change is using Collections.emptyList() rather than Collections.EMPTY_LIST which avoids unchecked warnings. Unfortunately I don't have a Windows box to test on, but I'll see what I can see by backing up to the commit before either of these and examining the size of the output as I add them back in. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reopened SOLR-13939: -- > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1669: SOLR-14151 Make schema components load from packages
dsmiley commented on a change in pull request #1669:
URL: https://github.com/apache/lucene-solr/pull/1669#discussion_r455386922
##
File path: solr/core/src/java/org/apache/solr/schema/IndexSchema.java
##
@@ -188,6 +190,7 @@ public IndexSchema(String name, InputSource is, Version
luceneVersion, SolrResou
protected IndexSchema(Version luceneVersion, SolrResourceLoader loader,
Properties substitutableProperties) {
this.luceneVersion = Objects.requireNonNull(luceneVersion);
this.loader = loader;
+this.solrClassLoader = loader.getCore() == null? loader:
loader.getCore().getSchemaPluginsLoader();
Review comment:
Okay; lets get this done.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158734#comment-17158734
]
David Smiley commented on SOLR-14557:
-
Looks like a bug to me Mikhail. I trust you to fix is appropriately. Too bad
no detailed peer review from those you at-mentioned but don't let that stop the
bug from getting fixed.
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158730#comment-17158730 ] Uwe Schindler edited comment on SOLR-13756 at 7/15/20, 9:49 PM: I don't remember. Wasn't this fixed by fixing the broken redirects? The easy test is to clean your IVY cache and run the build of an old version of Lucene/Solr. Newer versions use HTTPS already. was (Author: thetaphi): I don't remember. Wasn't this fixed by fixing the broken redirects? > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug >Reporter: Chongchen Chen >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158730#comment-17158730 ] Uwe Schindler commented on SOLR-13756: -- I don't remember. Wasn't this fixed by fixing the broken redirects? > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug >Reporter: Chongchen Chen >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158725#comment-17158725 ] Uwe Schindler edited comment on SOLR-13939 at 7/15/20, 9:47 PM: Hi, since c346881ad6a4ff61d6776a2a41e5c506f217ef2c was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit (SOLR-11262) done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ was (Author: thetaphi): Hi, since c346881ad6a4ff61d6776a2a41e5c506f217ef2c was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158729#comment-17158729 ] Uwe Schindler edited comment on SOLR-11262 at 7/15/20, 9:46 PM: This is one of 2 commits which caused Windows builds to consume all disk space. I tend to think it's not this one, because it does not change I/O anywhere or forgets to close files in almost all Solr tests, but it would be good to verify this. I tend to think that SOLR-13939 caused this, I just want to be sure. That's what I found out: Since 8c9c0640cfe558a8c65f2ef50113f38cb7ef66d6 was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ If it's caused not by this, just close the issue, maybe run a complete Ant-based Windows build to verify! was (Author: thetaphi): This is one of 2 commits which caused Windows builds to consume all disk space. I tend to think it's not this one, because it does not change I/O anywhere or forgets to close files in almost all Solr tests, but it would be good to verify this. I tend to think that SOLR-11262 caused this, I just want to be sure. That's what I found out: Since 8c9c0640cfe558a8c65f2ef50113f38cb7ef66d6 was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ If it's caused not by this, just close the issue, maybe run a complete Ant-based Windows build to verify! > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Munendra S N >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-11262.patch > > Time Spent: 1h > Remaining Estimate: 0h > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158729#comment-17158729 ] Uwe Schindler edited comment on SOLR-11262 at 7/15/20, 9:46 PM: This is one of 2 commits which caused Windows builds to consume all disk space. I tend to think it's not this one, because it does not change I/O anywhere or forgets to close files in almost all Solr tests, but it would be good to verify this. I tend to think that SOLR-11262 caused this, I just want to be sure. That's what I found out: Since 8c9c0640cfe558a8c65f2ef50113f38cb7ef66d6 was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ If it's caused not by this, just close the issue, maybe run a complete Ant-based Windows build to verify! was (Author: thetaphi): This is one of 2 commits which caused Windows builds to consume all disk space. I tend to think it's not this one, because it does not change I/O anywhere or forgets to close files in almost all Solr tests, but it would be good to verify this. That's what I found out: Since 8c9c0640cfe558a8c65f2ef50113f38cb7ef66d6 was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ If it's caused not by this, just close the issue, maybe run a complete Ant-based Windows build to verify! > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Munendra S N >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-11262.patch > > Time Spent: 1h > Remaining Estimate: 0h > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Reopened] (SOLR-11262) XML writer does not implement PushWriter
[ https://issues.apache.org/jira/browse/SOLR-11262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reopened SOLR-11262: -- This is one of 2 commits which caused Windows builds to consume all disk space. I tend to think it's not this one, because it does not change I/O anywhere or forgets to close files in almost all Solr tests, but it would be good to verify this. That's what I found out: Since 8c9c0640cfe558a8c65f2ef50113f38cb7ef66d6 was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ If it's caused not by this, just close the issue, maybe run a complete Ant-based Windows build to verify! > XML writer does not implement PushWriter > > > Key: SOLR-11262 > URL: https://issues.apache.org/jira/browse/SOLR-11262 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Assignee: Munendra S N >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-11262.patch > > Time Spent: 1h > Remaining Estimate: 0h > > While implementing points support for the terms component in a streaming > manner (via PushWriter/MapWriter) I discovered that the XML response writer > does not implement this interface. > This means that any code using PushWriter (via MapWriter or IteratorWriter) > will be broken if one tries to use XML response format. This may easily go > unnoticed if one is not using XML response format in testing (JSON or binary > is frequently used). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14651) Metrics history could disable itself better
[ https://issues.apache.org/jira/browse/SOLR-14651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158728#comment-17158728 ] David Smiley commented on SOLR-14651: - In the PR it works that way – "metricHistory" a boolean sys prop +for tests+. At least some tests since I realized other tests initialize the metrics configuration differently, which may explain why no tests failed when I defaulted it this way. > Metrics history could disable itself better > --- > > Key: SOLR-14651 > URL: https://issues.apache.org/jira/browse/SOLR-14651 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The MetricsHistoryHandler should disable itself better than it does. It will > create a SolrRrdBackendFactory (which has an ExecutorService / thread pool) > when it should not when the plugin is disabled. Furthermore, I think this > should be disabled by default in tests, as it's excessive machinery that > don't matter to 99.9% of tests. This will help our tests run more > efficiently. > While working on other issues, I also occasionally saw a thread leak failure > with the RRD being the leaked threads. I see that in "close", we don't > _wait_ for the executor to actually shut down but it should. > CC [~ab] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158725#comment-17158725 ] Uwe Schindler edited comment on SOLR-13939 at 7/15/20, 9:41 PM: Hi, since c346881ad6a4ff61d6776a2a41e5c506f217ef2c was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). That's the first build failing in both 8.x and master: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/9090/ was (Author: thetaphi): Hi, since c346881ad6a4ff61d6776a2a41e5c506f217ef2c was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158711#comment-17158711 ] Erick Erickson edited comment on SOLR-13973 at 7/15/20, 9:41 PM: - +1 to "doing it the modern way". IMO ExtractingRequestHandler was never intended to be used in production; we've been suggesting for _years_ that it be used for PoC but not in prod and users should "do something outside Solr". This seems like a chance to make it something that could be friendlier to production usage. At a quick glance, tika-server will be on-prem, we should make that plain in the docs... One other thing, and this isn't specific to Tika so [~ichattopadhyaya] and [~noble.paul] pay attention too ;). Currently, trunk is maintaining two sets of dependency files, one for gradle and one for ant. Moving Tika to a package (and this I assume holds true for other packages) will remove dependencies and both should be changed until we go to gradle-only. Ant still uses lucene/ivy-versions.properties. Gradle uses versions.props. When you change versions, you often have to execute "./gradlew --write-locks", see "gradlew helpAnt". was (Author: erickerickson): +1 to "doing it the modern way". IMO ExtractingRequestHandler was never intended to be used in production; we've been suggesting for _years_ that it be used for PoC but not in prod and users should "do something outside Solr". This seems like a chance to make it something that could be friendlier to production usage. At a quick glance, tika-server will be on-prem, we should make that plain in the docs... One other thing, and this isn't specific to Tika so [~ichattopadhyaya] and [~noble.paul] pay attention too ;). Currently, trunk is maintaining two sets of dependency files, one for gradle and one for ant. Moving Tika to a package (and this I assume holds true for other packages) will remove dependencies and both should be changed until we go to ant-only. Ant still uses lucene/ivy-versions.properties. Gradle uses versions.props. When you change versions, you often have to execute "./gradlew --write-locks", see "gradlew helpAnt". > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158722#comment-17158722 ] Jan Høydahl commented on SOLR-13973: +1 to "modern way", i.e. Tika Server. But there are many ways Tika could be integrated - as an ExtractingRequestHandler, as an UpdateRequestProcessor, as a standalone server etc. So there could be more than one package here to suit different needs? One could be a 'solr-cell-package' that walks like SolrCell and quacks like SolrCell, but delegates the extraction to a TikaServer. Another could be an 'attachment-processor', that reads a base64 encoded field in a SolrInputDocument, sends it to TikaServer for extraction, and writes the text to another field. The input field could alternatively be a file system path, an S3 location or another URI. So I think a quick survey of user needs makes sense. Perhaps even a simple Tika integration in SolrJ would make sense, making it super simple to do the extration on client side, which is probably what most users should consider anyway. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158725#comment-17158725 ] Uwe Schindler commented on SOLR-13939: -- Hi, since c346881ad6a4ff61d6776a2a41e5c506f217ef2c was committed it looks like all windows builds fail to finish and instead consume all disk space of the virtual machine. The master branch starting from that commit, but also the 8.x branch consume all available space and then fail with tons of errors. There was a second commit done on the same day, so I am not which one is the cause, but tons of failed tests and 18 Gigabytes of checkout on Windows is a desaster. I had to stop Jenkins Windows builds. Would it be possible to revert this as a test? Or maybe you have an idea. Ideally, please test the build on Windows 10 (with ANT). > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-13939. --- Fix Version/s: 8.7 Resolution: Fixed Given that almost all of this final misc bit is for things that should not be changed (XmlCorrector and TestVirtualMethod) and the only other change that might possibly affect a test is in a test that hasn't failed in over 18 months, I'm calling it done. [~dweiss] But your name is all over it ;). Turns out that when you reverted my commit from a long time ago (as we discussed), your name got attached. Sorry for the noise. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Fix For: 8.7 > > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158723#comment-17158723 ] Tim Allison commented on SOLR-13973: For ease of use with SolrJ and several other use cases(?), we could add a tika-client in the Tika project? > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158719#comment-17158719 ] Tim Allison commented on SOLR-13973: I cannot express the joy that will come to me, whether I'm the one to do it or not, to take out the kitchensink of dependencies that Tika has forced on Solr. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158719#comment-17158719 ] Tim Allison edited comment on SOLR-13973 at 7/15/20, 9:35 PM: -- I cannot express the joy that will come to me, whether I'm the one to do it or not, to take out the kitchensink of dependencies that Tika has forced on Solr. If we do want a forwarding option within tika-server, please chime in on TIKA-3093. Otherwise, please let me know how I can help. I suspect [~epugh] has a better sense of how to get started, and I stand by to help him. was (Author: talli...@mitre.org): I cannot express the joy that will come to me, whether I'm the one to do it or not, to take out the kitchensink of dependencies that Tika has forced on Solr. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13756) ivy cannot download org.restlet.ext.servlet jar
[ https://issues.apache.org/jira/browse/SOLR-13756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158712#comment-17158712 ] Erick Erickson commented on SOLR-13756: --- [~uschindler] [~jbernste] what's the status of this? > ivy cannot download org.restlet.ext.servlet jar > --- > > Key: SOLR-13756 > URL: https://issues.apache.org/jira/browse/SOLR-13756 > Project: Solr > Issue Type: Bug >Reporter: Chongchen Chen >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > I checkout the project and run `ant idea`, it will try to download jars. But > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > will return 404 now. > [ivy:retrieve] public: tried > [ivy:retrieve] > https://repo1.maven.org/maven2/org/restlet/jee/org.restlet.ext.servlet/2.3.0/org.restlet.ext.servlet-2.3.0.jar > [ivy:retrieve]:: > [ivy:retrieve]:: FAILED DOWNLOADS:: > [ivy:retrieve]:: ^ see resolution messages for details ^ :: > [ivy:retrieve]:: > [ivy:retrieve]:: > org.restlet.jee#org.restlet;2.3.0!org.restlet.jar > [ivy:retrieve]:: > org.restlet.jee#org.restlet.ext.servlet;2.3.0!org.restlet.ext.servlet.jar > [ivy:retrieve]:: -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158711#comment-17158711 ] Erick Erickson commented on SOLR-13973: --- +1 to "doing it the modern way". IMO ExtractingRequestHandler was never intended to be used in production; we've been suggesting for _years_ that it be used for PoC but not in prod and users should "do something outside Solr". This seems like a chance to make it something that could be friendlier to production usage. At a quick glance, tika-server will be on-prem, we should make that plain in the docs... One other thing, and this isn't specific to Tika so [~ichattopadhyaya] and [~noble.paul] pay attention too ;). Currently, trunk is maintaining two sets of dependency files, one for gradle and one for ant. Moving Tika to a package (and this I assume holds true for other packages) will remove dependencies and both should be changed until we go to ant-only. Ant still uses lucene/ivy-versions.properties. Gradle uses versions.props. When you change versions, you often have to execute "./gradlew --write-locks", see "gradlew helpAnt". > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158708#comment-17158708
]
Mark Robert Miller edited comment on SOLR-14636 at 7/15/20, 9:02 PM:
-
My feel is that this is so head and shoulders beyond master, there is not much
that can be done piecemeal in that direction.
This is a jenga tower on a rubik's cube. The work to figure out the right build
and make it all come together is heavily intertwined. This is a process, not a
task or a plan or an intelligent design. The code leads me, I don't lead the
code.
My initial goal was to help out a couple pals get some easy wins on current
problems. Everytime I start pulling on that sweater thread, I end up here.
Because the current system is ungodly unstable and buggy - what seem like easy
wins always lead to more instability and fails in some corner. Speed is the
light, and the cockroaches roam free. It's whack a mole. I got sick of whacking.
was (Author: markrmiller):
My feel is that this is so head and shoulders beyond master, there is not much
that can be done piecemeal in that direction.
This is a jenga tower on a rubik's cube. The work to figure out the right build
and make it all come together is heavily intertwined. This a process, not a
task or a plan or an intelligent design. The code leads me, I don't lead the
code.
My initial goal was to help out a couple pals get some easy wins on current
problems. Everytime I start pulling on that sweater thread, I end up here.
Because the current system is ungodly unstable and buggy - what seem like easy
wins always lead to more instability and fails in some corner. Speed is the
light, and the cockroaches roam free. It's whack a mole. I got sick of whacking.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158708#comment-17158708
]
Mark Robert Miller commented on SOLR-14636:
---
My feel is that this is so head and shoulders beyond master, there is not much
that can be done piecemeal in that direction.
This is a jenga tower on a rubik's cube. The work to figure out the right build
and make it all come together is heavily intertwined. This a process, not a
task or a plan or an intelligent design. The code leads me, I don't lead the
code.
My initial goal was to help out a couple pals get some easy wins on current
problems. Everytime I start pulling on that sweater thread, I end up here.
Because the current system is ungodly unstable and buggy - what seem like easy
wins always lead to more instability and fails in some corner. Speed is the
light, and the cockroaches roam free. It's whack a mole. I got sick of whacking.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14651) Metrics history could disable itself better
[ https://issues.apache.org/jira/browse/SOLR-14651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158706#comment-17158706 ] Jan Høydahl commented on SOLR-14651: It should also be possible to disable it with a simple system property, not having to upload a clusterprop to zk or edit solr.xml. > Metrics history could disable itself better > --- > > Key: SOLR-14651 > URL: https://issues.apache.org/jira/browse/SOLR-14651 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The MetricsHistoryHandler should disable itself better than it does. It will > create a SolrRrdBackendFactory (which has an ExecutorService / thread pool) > when it should not when the plugin is disabled. Furthermore, I think this > should be disabled by default in tests, as it's excessive machinery that > don't matter to 99.9% of tests. This will help our tests run more > efficiently. > While working on other issues, I also occasionally saw a thread leak failure > with the RRD being the leaked threads. I see that in "close", we don't > _wait_ for the executor to actually shut down but it should. > CC [~ab] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mayya-sharipova commented on a change in pull request #1610: LUCENE-9384: Backport for field sort optimization
mayya-sharipova commented on a change in pull request #1610:
URL: https://github.com/apache/lucene-solr/pull/1610#discussion_r455321149
##
File path: lucene/core/src/java/org/apache/lucene/search/SortField.java
##
@@ -408,6 +428,7 @@ public boolean equals(Object o) {
&& other.reverse == this.reverse
&& Objects.equals(this.comparatorSource, other.comparatorSource)
&& Objects.equals(this.missingValue, other.missingValue)
+ && other.skipNonCompetitiveDocs == this.skipNonCompetitiveDocs
Review comment:
@jpountz Thank you for your feedback. Alternatively we can add
`setCanUsePoints` parameter to `Sort` object instead of `SortField`? What do
you think?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158692#comment-17158692
]
Mikhail Khludnev edited comment on SOLR-14557 at 7/15/20, 8:25 PM:
---
it seems to me that quite essential case like {{defType=lucene=
\{!lucene}(space matters)}} is broken. WDYT?
was (Author: mkhludnev):
it seems to me that quite essential case like {{defType=lucene=
{!lucene}(space matters)}} is broken. WDYT?
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158692#comment-17158692
]
Mikhail Khludnev commented on SOLR-14557:
-
it seems to me that quite essential case like {{defType=lucene=
{!lucene}(space matters)}} is broken. WDYT?
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14557) Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
[
https://issues.apache.org/jira/browse/SOLR-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-14557:
Summary: Unable to parse local params followed by parenthesis like
{!lucene}(gigabyte) (was: eDisMax parser unable to parse {!lucene}(gigabyte))
> Unable to parse local params followed by parenthesis like {!lucene}(gigabyte)
> -
>
> Key: SOLR-14557
> URL: https://issues.apache.org/jira/browse/SOLR-14557
> Project: Solr
> Issue Type: Bug
> Components: query parsers
>Reporter: Mikhail Khludnev
>Priority: Major
> Labels: painful
> Attachments: SOLR-14557.patch, SOLR-14557.patch, SOLR-14557.patch
>
>
> h2. Solr 4.5
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
>
> goes like
> {code}
> \{!lucene}(foo)
> content:foo
> LuceneQParser
> {code}
> fine
> h2. Solr 8.2
> with luceneMatchVersion=4.5 following SOLR-11501 I know it's a grey zone but
> it's a question of migrating existing queries.
> {{/select?defType=edismax=\{!lucene}(foo)=true}}
> goes like
> {code}
> "querystring":"\{!lucene}(foo)",
> "parsedquery":"+DisjunctionMaxQuery(((Project.Address:lucene
> Project.Address:foo) | (Project.OwnerType:lucene Project.OwnerType:foo)
> "QParser":"ExtendedDismaxQParser",
> {code}
> blah...
> but removing braces in 8.2 works perfectly fine
> {code}
> "querystring":"\{!lucene}foo",
> "parsedquery":"+content:foo",
> "parsedquery_toString":"+content:foo",
> "QParser":"ExtendedDismaxQParser",
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-11501) Depending on the parser, QParser should not parse local-params
[
https://issues.apache.org/jira/browse/SOLR-11501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158689#comment-17158689
]
Mikhail Khludnev commented on SOLR-11501:
-
ok. Regarding [^SOLR-11501-breaker.patch], {{defType=edismax=*
_query_={!lucene df=text_sw}(gigabyte)}} worked before, because edismax
didn't attempted to parse local params here, parser was switched early, and
{{QParser.prarseLocalParams()}} just stripped the prefix.
Now, edismax tries to parse it and fails. Followup SOLR-14557.
> Depending on the parser, QParser should not parse local-params
> --
>
> Key: SOLR-11501
> URL: https://issues.apache.org/jira/browse/SOLR-11501
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 7.2
>
> Attachments: SOLR-11501-breaker.patch,
> SOLR_11501_limit_local_params_parsing.patch,
> SOLR_11501_limit_local_params_parsing.patch
>
>
> Solr should not parse local-params (and thus be able to switch the query
> parser) in certain circumstances. _Perhaps_ it is when the QParser.getParser
> is passed "lucene" for the {{defaultParser}}? This particular approach is
> just a straw-man; I suspect certain valid embedded queries could no longer
> work if this is done incorrectly. Whatever the solution, I don't think we
> should assume 'q' is special, as it's valid and useful to build up queries
> containing user input in other ways, e.g. {{q= +field:value +\{!dismax
> v=$qq\}=user input}} and we want to protect the user input there
> similarly from unwelcome query parsing switching.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158683#comment-17158683 ] Ishan Chattopadhyaya commented on SOLR-13973: - Thanks [~epugh]. Let me know how I can help with the package manager parts. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158678#comment-17158678 ] Tim Allison commented on SOLR-13973: I think [~epugh] just volunteered for this! > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14608) Faster sorting for the /export handler
[ https://issues.apache.org/jira/browse/SOLR-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158674#comment-17158674 ] ASF subversion and git services commented on SOLR-14608: Commit ee9c3d083c60850c3e48d301356329cf0f017c86 in lucene-solr's branch refs/heads/jira/SOLR-14608-export from Joel Bernstein [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ee9c3d0 ] SOLR-14608: Works with one string value sort field. > Faster sorting for the /export handler > -- > > Key: SOLR-14608 > URL: https://issues.apache.org/jira/browse/SOLR-14608 > Project: Solr > Issue Type: New Feature >Reporter: Joel Bernstein >Assignee: Andrzej Bialecki >Priority: Major > > The largest cost of the export handler is the sorting. This ticket will > implement an improved algorithm for sorting that should greatly increase > overall throughput for the export handler. > *The current algorithm is as follows:* > Collect a bitset of matching docs. Iterate over that bitset and materialize > the top level oridinals for the sort fields in the document and add them to > priority queue of size 3. Then export the top 3 docs, turn off the > bits in the bit set and iterate again until all docs are sorted and sent. > There are two performance bottlenecks with this approach: > 1) Materializing the top level ordinals adds a huge amount of overhead to the > sorting process. > 2) The size of priority queue, 30,000, adds significant overhead to sorting > operations. > *The new algorithm:* > Has a top level *merge sort iterator* that wraps segment level iterators that > perform segment level priority queue sorts. > *Segment level:* > The segment level docset will be iterated and the segment level ordinals for > the sort fields will be materialized and added to a segment level priority > queue. As the segment level iterator pops docs from the priority queue the > top level ordinals for the sort fields are materialized. Because the top > level ordinals are materialized AFTER the sort, they only need to be looked > up when the segment level ordinal changes. This takes advantage of the sort > to limit the lookups into the top level ordinal structures. This also > eliminates redundant lookups of top level ordinals that occur during the > multiple passes over the matching docset. > The segment level priority queues can be kept smaller than 30,000 to improve > performance of the sorting operations because the overall batch size will > still be 30,000 or greater when all the segment priority queue sizes are > added up. This allows for batch sizes much larger then 30,000 without using a > single large priority queue. The increased batch size means fewer iterations > over the matching docset and the decreased priority queue size means faster > sorting operations. > *Top level:* > A top level iterator does a merge sort over the segment level iterators by > comparing the top level ordinals materialized when the segment level docs are > popped from the segment level priority queues. This requires no extra memory > and will be very performant. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158654#comment-17158654 ] David Eric Pugh commented on SOLR-13973: Part of the goal of removing things out of core Solr is to foster innovation and get some new ideas. A chance to rethink the old ways of doing things! I suspect much of what is in https://lucene.apache.org/solr/guide/8_2/uploading-data-with-solr-cell-using-apache-tika.html could be done using a outside of Solr and then some UpdateRequestProcessors once the extracted text hits Solr. For example, instead of using the the literal.field_name capablity, just use a DefaultValueUpdateProcessorFactory instead. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13973) Deprecate Tika
[
https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158639#comment-17158639
]
Tim Allison edited comment on SOLR-13973 at 7/15/20, 7:15 PM:
--
I've been toying with adding a forwarding capability to tika-server
(TIKA-3093). So, if you curl a document to tika-server {{/tika2solr}}, we'd
use our tika parsing stuff in tika-server and the extracted text to Solr. This
would keep the dangerous part (tika parsing a document) out of the client code.
was (Author: talli...@mitre.org):
I've been toying with adding a forwarding capability to tika-server. So, if
you curl a document to tika-server {{/tika2solr}}, we'd use our tika parsing
stuff in tika-server and the extracted text to Solr. This would keep the
dangerous part (tika parsing a document) out of the client code.
> Deprecate Tika
> --
>
> Key: SOLR-13973
> URL: https://issues.apache.org/jira/browse/SOLR-13973
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.7
>
>
> Solr's primary responsibility should be to focus on search and scalability.
> Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us
> down. I propose that we deprecate it going forward.
> Tika can be run outside Solr. Going forward, if someone wants to use these,
> it should be possible to bring them into third party packages and installed
> via package manager.
> Plan is to just to throw warnings in logs and add deprecation notes in
> reference guide for now. Removal can be done in 9.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[
https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158639#comment-17158639
]
Tim Allison commented on SOLR-13973:
I've been toying with adding a forwarding capability to tika-server. So, if
you curl a document to tika-server {{/tika2solr}}, we'd use our tika parsing
stuff in tika-server and the extracted text to Solr. This would keep the
dangerous part (tika parsing a document) out of the client code.
> Deprecate Tika
> --
>
> Key: SOLR-13973
> URL: https://issues.apache.org/jira/browse/SOLR-13973
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 8.7
>
>
> Solr's primary responsibility should be to focus on search and scalability.
> Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us
> down. I propose that we deprecate it going forward.
> Tika can be run outside Solr. Going forward, if someone wants to use these,
> it should be possible to bring them into third party packages and installed
> via package manager.
> Plan is to just to throw warnings in logs and add deprecation notes in
> reference guide for now. Removal can be done in 9.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158629#comment-17158629 ] Tim Allison edited comment on SOLR-13973 at 7/15/20, 7:06 PM: -- [~ichattopadhyaya], thank you for the ping! Y, I might be able to find some time to work on this over the next few weeks. How do I start? Do I have the freedom to start from greenfields (use tika-server), or do we need seamless migration with the same capabilities? was (Author: talli...@mitre.org): Y, I might be able to find some time to work on this over the next few weeks. How do I start? Do I have the freedom to start from greenfields (use tika-server), or do we need seamless migration with the same capabilities? > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158629#comment-17158629 ] Tim Allison commented on SOLR-13973: Y, I might be able to find some time to work on this over the next few weeks. How do I start? Do I have the freedom to start from greenfields (use tika-server), or do we need seamless migration with the same capabilities? > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9428) merge index failed with checksum failed (hardware problem?)
[
https://issues.apache.org/jira/browse/LUCENE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158614#comment-17158614
]
Robert Muir commented on LUCENE-9428:
-
I agree with Adrien, and when testing the RAM i recommend booting into
something like memtest86 to do it. It is pretty thorough and will find problems
that other checkers miss.
> merge index failed with checksum failed (hardware problem?)
> ---
>
> Key: LUCENE-9428
> URL: https://issues.apache.org/jira/browse/LUCENE-9428
> Project: Lucene - Core
> Issue Type: Bug
> Environment: lucene version: 5.5.4
> jdk version : jdk1.8-1.8.0_231-fcs
> kernel version: kernel-3.10.0-957.21.3.el7.x86_64
>Reporter: AllenL
>Priority: Major
>
> Recently, a procedure using ElasticSearch appeared merge Index Failed with
> the following exception information
>
> {code:java}
> [2020-07-03 13:37:34,113][ERROR][index.engine ] [Deathbird]
> [st-sess][4] failed to merge
> [2020-07-03 13:37:34,113][ERROR][index.engine ] [Deathbird]
> [st-sess][4] failed to mergeorg.apache.lucene.index.CorruptIndexException:
> checksum failed (hardware problem?) : expected=31f090d9 actual=d9697caa
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/var/lib/elasticsearch/17412c54-f974-11e9-9eef-80615f029e06/nodes/0/indices/st-sess/4/index/_3jm_Lucene50_0.tim")))
>
> at org.apache.lucene.codecs.CodecUtil.checkFooter(CodecUtil.java:334) at
> org.apache.lucene.codecs.CodecUtil.checksumEntireFile(CodecUtil.java:451)
> at
> org.apache.lucene.codecs.blocktree.BlockTreeTermsReader.checkIntegrity(BlockTreeTermsReader.java:333)
>
> at
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.checkIntegrity(PerFieldPostingsFormat.java:317)
>
> at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:96)
> at org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:193)
> at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:95)
> at org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4086)
> at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3666)
> at
> org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:588)
>
> at
> org.elasticsearch.index.engine.ElasticsearchConcurrentMergeScheduler.doMerge(ElasticsearchConcurrentMergeScheduler.java:94)
>
> at
> org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:626)
> [2020-07-03 13:37:34,203][WARN ][index.engine ] [Deathbird]
> [st-sess][4] failed engine [merge
> failed]org.apache.lucene.index.MergePolicy$MergeException:
> org.apache.lucene.index.CorruptIndexException: checksum failed (hardware
> problem?) : expected=31f090d9 actual=d9697caa
> (resource=BufferedChecksumIndexInput(MMapIndexInput(path="/var/lib/elasticsearch/shterm-17412c54-f974-11e9-9eef-80615f029e06/nodes/0/indices/st-sess/4/index/_3jm_Lucene50_0.tim")))
>
> at
> org.elasticsearch.index.engine.InternalEngine$EngineMergeScheduler$1.doRun(InternalEngine.java:1237)
>
> at
> org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:37)
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>
> at java.lang.Thread.run(Thread.java:748){code}
>
> The exception shows that it may be a hardware problem. Try to check the
> hardware and find no exception. Check the command as follows：
> # check device /dev/sda, /dev/sdb; but finds no hardware errors
> using command: smartctl --xall /dev/sdx
> # check message log /var/log/messages, no hardware problem happend
> # The system has a state detection script, i get the system load recorded is
> normal, IOwait is very low
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-12661) Request with fl=[elevated] returns NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-12661.
-
Resolution: Cannot Reproduce
> Request with fl=[elevated] returns NullPointerException
> ---
>
> Key: SOLR-12661
> URL: https://issues.apache.org/jira/browse/SOLR-12661
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.4
>Reporter: Georgy Khotyan
>Priority: Major
>
> Request with fl=[elevated] returns NullPointerException when Solr 7.4 used.
> It works with all older versions.
> Example:
> [http://localhost:8983/solr/my-core/select?q=*:*=true=1,2,3=true=[elevated]
> Is it a bug of 7.4 version?
> Exception:
> { "error":\\{ "trace":"java.lang.NullPointerException\n\tat
> org.apache.solr.response.transform.BaseEditorialTransformer.getKey(BaseEditorialTransformer.java:72)\n\tat
>
> org.apache.solr.response.transform.BaseEditorialTransformer.transform(BaseEditorialTransformer.java:52)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:120)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)\n\tat
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)\n\tat
>
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)\n\tat
>
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)\n\tat
>
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)\n\tat
>
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:806)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:535)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
> java.lang.Thread.run(Thread.java:748)\n", "code":500}
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Closed] (SOLR-12661) Request with fl=[elevated] returns NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-12661.
---
> Request with fl=[elevated] returns NullPointerException
> ---
>
> Key: SOLR-12661
> URL: https://issues.apache.org/jira/browse/SOLR-12661
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.4
>Reporter: Georgy Khotyan
>Priority: Major
>
> Request with fl=[elevated] returns NullPointerException when Solr 7.4 used.
> It works with all older versions.
> Example:
> [http://localhost:8983/solr/my-core/select?q=*:*=true=1,2,3=true=[elevated]
> Is it a bug of 7.4 version?
> Exception:
> { "error":\\{ "trace":"java.lang.NullPointerException\n\tat
> org.apache.solr.response.transform.BaseEditorialTransformer.getKey(BaseEditorialTransformer.java:72)\n\tat
>
> org.apache.solr.response.transform.BaseEditorialTransformer.transform(BaseEditorialTransformer.java:52)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:120)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)\n\tat
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)\n\tat
>
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)\n\tat
>
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)\n\tat
>
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)\n\tat
>
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:806)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:535)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
> java.lang.Thread.run(Thread.java:748)\n", "code":500}
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands,
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158608#comment-17158608 ] David Smiley commented on SOLR-13939: - Do not change XmlOffsetCorrector. That's related to SOLR-13990 (move to Alto XML) which is it's own issue and will happen when it's ready. I recommend disregarding little one-off changes from Mark's old branch. I don't like miscellaneous change issues/PR that have no real focus / subject. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158602#comment-17158602
]
Ishan Chattopadhyaya commented on SOLR-14636:
-
bq. Practically speaking, we'll never get to a holy grail of perfection, and
that's quite alright.
Practically speaking, I totally expect this branch to reach the holy grail of
(what I considered to be) perfection very soon.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9431) UnifiedHighlighter: Make WEIGHT_MATCHES the default
[ https://issues.apache.org/jira/browse/LUCENE-9431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-9431: - Fix Version/s: master (9.0) Priority: Blocker (was: Major) Filing as blocker to help us not forget. It ought to be a minor change. > UnifiedHighlighter: Make WEIGHT_MATCHES the default > --- > > Key: LUCENE-9431 > URL: https://issues.apache.org/jira/browse/LUCENE-9431 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: David Smiley >Priority: Blocker > Fix For: master (9.0) > > > This mode uses Lucene's modern mechanism of exposing information that > previously required complicated highlighting machinery. It's also likely to > generally work better out-of-the-box and with custom queries. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9431) UnifiedHighlighter: Make WEIGHT_MATCHES the default
David Smiley created LUCENE-9431: Summary: UnifiedHighlighter: Make WEIGHT_MATCHES the default Key: LUCENE-9431 URL: https://issues.apache.org/jira/browse/LUCENE-9431 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: David Smiley This mode uses Lucene's modern mechanism of exposing information that previously required complicated highlighting machinery. It's also likely to generally work better out-of-the-box and with custom queries. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12754) Solr UnifiedHighlighter support flag WEIGHT_MATCHES
[ https://issues.apache.org/jira/browse/SOLR-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158597#comment-17158597 ] David Smiley commented on SOLR-12754: - It's false by default in Lucene, but true by default in Solr. I'll file an issue for 9.0 to graduate this mode Lucene side. > Solr UnifiedHighlighter support flag WEIGHT_MATCHES > --- > > Key: SOLR-12754 > URL: https://issues.apache.org/jira/browse/SOLR-12754 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 7.6, 8.0 > > Attachments: SOLR-12754.patch, SOLR-12754.patch > > > Solr's should support the WEIGHT_MATCHES flag of the UnifiedHighlighter. It > supports best/perfect highlighting accuracy, and nicer phrase snippets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158594#comment-17158594
]
David Smiley commented on SOLR-14636:
-
{quote}we should just keep improving this reference branch until there's
absolutely nothing left to improve
{quote}
ROTFL! I hope we've all learned as software engineers that code can keep being
improved forever, particularly in any non-trivial code base. Practically
speaking, we'll never get to a holy grail of perfection, and that's quite
alright. Focus on what matters the most, and then you're left with minor
matters.
A thought occurred to me: maybe the work on tests on this branch will mostly be
committable to master _before_ the rest of the changes. There will be some
entanglements, I'm sure, so this won't be a perfectly achievable thing but
something that might be _mostly_ do-able. I'd be okay with a large commit only
to tests that makes them better. Mark has done this before, as git blame
reminds me. Then the non-test changes could be brought in piecemeal while
retaining passing tests. Mark; do you think this is possible and makes sense?
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12754) Solr UnifiedHighlighter support flag WEIGHT_MATCHES
[ https://issues.apache.org/jira/browse/SOLR-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158593#comment-17158593 ] Jason Baik commented on SOLR-12754: --- [~dsmiley] Very minor, but org/apache/lucene/search/uhighlight/UnifiedHighlighter.java:1146 still says "False by default". > Solr UnifiedHighlighter support flag WEIGHT_MATCHES > --- > > Key: SOLR-12754 > URL: https://issues.apache.org/jira/browse/SOLR-12754 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 7.6, 8.0 > > Attachments: SOLR-12754.patch, SOLR-12754.patch > > > Solr's should support the WEIGHT_MATCHES flag of the UnifiedHighlighter. It > supports best/perfect highlighting accuracy, and nicer phrase snippets. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14646) Ref Guide: Support STEM notation
[ https://issues.apache.org/jira/browse/SOLR-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cassandra Targett resolved SOLR-14646. -- Resolution: Fixed > Ref Guide: Support STEM notation > > > Key: SOLR-14646 > URL: https://issues.apache.org/jira/browse/SOLR-14646 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14646.patch > > > SOLR-11217 broached this idea a couple years ago, but at that time we were > hamstrung by an inability to support STEM notations in the PDF. That's gone > now, so we can use the same magic I figured out back then to support it in > the HTML version. This will in essence add MathJax.js to each page to convert > the math notations on the fly. > The documentation for MinHash that's been languishing in SOLR-12879 relies on > this support. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-8319) NPE when creating pivot
[ https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158575#comment-17158575 ] Yunus edited comment on SOLR-8319 at 7/15/20, 5:49 PM: --- Solr: 6.6.2 Hello guys just to add to the topic. First I would like to thank you [~igiguere]. I have now some hope of fixing this issue myself by patching it if necessary. I have the same problem as reported in https://issues.apache.org/jira/browse/SOLR-8921 . Our system use distributed Solr and our application use faceting on text fields. Faceting on them can return a lot of terms so we used a limit of 50. After testing multiple requests I noticed that playing on facet.limit allowed me to get back values and not a NPE. So I read back again the doc on faceting and google a lot until I found : [https://stackoverflow.com/a/36779784] As sugested in the post, I added over-request parameters [https://lucene.apache.org/solr/guide/6_6/faceting.html#Faceting-Over-RequestParameters] and it is working correctly now. I do not undestand why It has an effect on my request :/ this topic is a bit complicated for me. I hope it can help to bring some light on the problem. was (Author: ybviavoo): Solr: 6.6.2 Hello guys just to add to the topic. First I would like to thank you [~igiguere]. I have now some hope of fixing this issue myself by patching it if necessary. I have the same problem as reported in https://issues.apache.org/jira/browse/SOLR-8921 . Our system use distributed Solr and our application use faceting on text fields. Faceting on them can return a lot of terms so we used a limit of 50. After testing multiple requests I noticed that playing on facet.limit allowed me to get back values and not a NPE. So I read back again the doc on faceting and google a lot until I found : [https://stackoverflow.com/a/36779784] As sugested in the post, I added over-request parameters [https://lucene.apache.org/solr/guide/6_6/faceting.html#Faceting-Over-RequestParameters] and it is working correctly now. I hope it can help to bring some light on the problem. > NPE when creating pivot > --- > > Key: SOLR-8319 > URL: https://issues.apache.org/jira/browse/SOLR-8319 > Project: Solr > Issue Type: Bug >Reporter: Neil Ireson >Priority: Major > Attachments: SOLR-8319.patch > > > I get a NPE, the trace is shown at the end. > The problem seems to be this line in the getSubset method: > Query query = ft.getFieldQuery(null, field, pivotValue); > Which takes a value from the index and then analyses it to create a query. I > believe the problem is that when my analysis process is applied twice it > results in a null query. OK this might be seen as my issue because of dodgy > analysis, I thought it might be because I have the wrong order with > LengthFilterFactory before EnglishPossessiveFilterFactory and > KStemFilterFactory, i.e.: > > > > So that "cat's" -> "cat" -> "", however any filter order I tried still > resulted in a NPE, and perhaps there is a viable case where parsing a term > twice results in a null query. > The thing is I don't see why when the query term comes from the index it has > to undergo any analysis. If the term is from the index can it not simply be > created using a TermQuery, which I would imagine would also be faster. I > altered the "getFieldQuery" line above to the following and that has fixed my > NPE issue. > Query query = new TermQuery(new Term(field.getName(), pivotValue)); > So far this hasn't caused any other issues but perhaps that is due to my use > of Solr, rather than actually fixing an issue. > o.a.s.c.SolrCore java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91) > at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130) > at > org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375) > at > org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at
[jira] [Commented] (SOLR-8319) NPE when creating pivot
[ https://issues.apache.org/jira/browse/SOLR-8319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158575#comment-17158575 ] Yunus commented on SOLR-8319: - Solr: 6.6.2 Hello guys just to add to the topic. First I would like to thank you [~igiguere]. I have now some hope of fixing this issue myself by patching it if necessary. I have the same problem as reported in https://issues.apache.org/jira/browse/SOLR-8921 . Our system use distributed Solr and our application use faceting on text fields. Faceting on them can return a lot of terms so we used a limit of 50. After testing multiple requests I noticed that playing on facet.limit allowed me to get back values and not a NPE. So I read back again the doc on faceting and google a lot until I found : [https://stackoverflow.com/a/36779784] As sugested in the post, I added over-request parameters [https://lucene.apache.org/solr/guide/6_6/faceting.html#Faceting-Over-RequestParameters] and it is working correctly now. I hope it can help to bring some light on the problem. > NPE when creating pivot > --- > > Key: SOLR-8319 > URL: https://issues.apache.org/jira/browse/SOLR-8319 > Project: Solr > Issue Type: Bug >Reporter: Neil Ireson >Priority: Major > Attachments: SOLR-8319.patch > > > I get a NPE, the trace is shown at the end. > The problem seems to be this line in the getSubset method: > Query query = ft.getFieldQuery(null, field, pivotValue); > Which takes a value from the index and then analyses it to create a query. I > believe the problem is that when my analysis process is applied twice it > results in a null query. OK this might be seen as my issue because of dodgy > analysis, I thought it might be because I have the wrong order with > LengthFilterFactory before EnglishPossessiveFilterFactory and > KStemFilterFactory, i.e.: > > > > So that "cat's" -> "cat" -> "", however any filter order I tried still > resulted in a NPE, and perhaps there is a viable case where parsing a term > twice results in a null query. > The thing is I don't see why when the query term comes from the index it has > to undergo any analysis. If the term is from the index can it not simply be > created using a TermQuery, which I would imagine would also be faster. I > altered the "getFieldQuery" line above to the following and that has fixed my > NPE issue. > Query query = new TermQuery(new Term(field.getName(), pivotValue)); > So far this hasn't caused any other issues but perhaps that is due to my use > of Solr, rather than actually fixing an issue. > o.a.s.c.SolrCore java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) > at > org.apache.solr.util.ConcurrentLRUCache.get(ConcurrentLRUCache.java:91) > at org.apache.solr.search.FastLRUCache.get(FastLRUCache.java:130) > at > org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:1296) > at > org.apache.solr.handler.component.PivotFacetProcessor.getSubset(PivotFacetProcessor.java:375) > at > org.apache.solr.handler.component.PivotFacetProcessor.doPivots(PivotFacetProcessor.java:305) > at > org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:228) > at > org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:170) > at > org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:262) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:277) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068) > at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:669) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:462) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:214) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:179) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at >
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158574#comment-17158574
]
Ishan Chattopadhyaya commented on SOLR-14636:
-
bq. What do you or others think?
When the time is right, we can focus on the right way forward (i.e. the "end
game"). Till then, we should just keep improving this reference branch until
there's absolutely nothing left to improve. Focusing on design documents or
commit messages etc. is okay, but IMHO it can wait until the time is right.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] ctargett merged pull request #22: Add 8.6 to available Ref Guide versions
ctargett merged pull request #22: URL: https://github.com/apache/lucene-site/pull/22 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-site] ctargett opened a new pull request #22: Add 8.6 to available Ref Guide versions
ctargett opened a new pull request #22: URL: https://github.com/apache/lucene-site/pull/22 Updates Ref Guide page to add 8.6. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158556#comment-17158556 ] Ishan Chattopadhyaya commented on SOLR-13973: - [~tallison], would you like to take a stab at turning this into a package? If so, I can help. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158554#comment-17158554 ] Ishan Chattopadhyaya commented on SOLR-13973: - Right, I should've been more precise. I mean Solr Cell here. Apache Tika, as a standalone project will continue to work, of course :-) > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158545#comment-17158545 ] Tomas Eduardo Fernandez Lobbe commented on SOLR-13973: -- I guess you mean ExtractingRequestHandler? Apache Tika will continue as normal. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14646) Ref Guide: Support STEM notation
[ https://issues.apache.org/jira/browse/SOLR-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158543#comment-17158543 ] ASF subversion and git services commented on SOLR-14646: Commit b214d90209d5870f2d65b3ae2c2a9568651413a5 in lucene-solr's branch refs/heads/branch_8x from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b214d90 ] SOLR-14646: Add STEM notation support for the Ref Guide > Ref Guide: Support STEM notation > > > Key: SOLR-14646 > URL: https://issues.apache.org/jira/browse/SOLR-14646 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14646.patch > > > SOLR-11217 broached this idea a couple years ago, but at that time we were > hamstrung by an inability to support STEM notations in the PDF. That's gone > now, so we can use the same magic I figured out back then to support it in > the HTML version. This will in essence add MathJax.js to each page to convert > the math notations on the fly. > The documentation for MinHash that's been languishing in SOLR-12879 relies on > this support. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14646) Ref Guide: Support STEM notation
[ https://issues.apache.org/jira/browse/SOLR-14646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158537#comment-17158537 ] ASF subversion and git services commented on SOLR-14646: Commit c57a54bba54a6bae52255a56db945342b6b29fba in lucene-solr's branch refs/heads/master from Cassandra Targett [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c57a54b ] SOLR-14646: Add STEM notation support for the Ref Guide > Ref Guide: Support STEM notation > > > Key: SOLR-14646 > URL: https://issues.apache.org/jira/browse/SOLR-14646 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Cassandra Targett >Assignee: Cassandra Targett >Priority: Minor > Fix For: 8.7 > > Attachments: SOLR-14646.patch > > > SOLR-11217 broached this idea a couple years ago, but at that time we were > hamstrung by an inability to support STEM notations in the PDF. That's gone > now, so we can use the same magic I figured out back then to support it in > the HTML version. This will in essence add MathJax.js to each page to convert > the math notations on the fly. > The documentation for MinHash that's been languishing in SOLR-12879 relies on > this support. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9430) Explainable ConstantScoreQuery
[ https://issues.apache.org/jira/browse/LUCENE-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158519#comment-17158519 ] Uwe Schindler commented on LUCENE-9430: --- There's no need for the additional boolean in constructor or isExplainable (). Just add the fix for the explain method to make it give more details. > Explainable ConstantScoreQuery > -- > > Key: LUCENE-9430 > URL: https://issues.apache.org/jira/browse/LUCENE-9430 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Jehyun Lee >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Developer cannot check the result of detailed explain with ConstantScoreQuery. > If the developer want to check it, then must be change the query. > > The result is the same as ConstantScoreQuery, > but if you can check the detailed explain, it will help in development and > debug. > > So, I make the Pull Request for this :) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jeng832 opened a new pull request #1674: [LUCENE-9430] Explainable ConstantScoreQuery
jeng832 opened a new pull request #1674: URL: https://github.com/apache/lucene-solr/pull/1674 Developer cannot check the result of detailed explain with ConstantScoreQuery. If the developer want to check it, then must be change the query. The result is the same as ConstantScoreQuery, but if you can check the detailed explain, it will help in development and debug. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9430) Explainable ConstantScoreQuery
Jehyun Lee created LUCENE-9430: -- Summary: Explainable ConstantScoreQuery Key: LUCENE-9430 URL: https://issues.apache.org/jira/browse/LUCENE-9430 Project: Lucene - Core Issue Type: Improvement Reporter: Jehyun Lee Developer cannot check the result of detailed explain with ConstantScoreQuery. If the developer want to check it, then must be change the query. The result is the same as ConstantScoreQuery, but if you can check the detailed explain, it will help in development and debug. So, I make the Pull Request for this :) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158516#comment-17158516
]
David Smiley commented on SOLR-14636:
-
As the changes to Solr increase ever more in this branch ("reference_impl"),
I'm worried it will be for naught because it'll become even harder to bring
back into master. Can you bring focused changes to master branch with discrete
issues? There's probably some low hanging fruit in there (e.g.
closer-related). I know a challenge is that some of the changes, good things
in their own right, reveal problems in tests causing failures that require
further changes... and repeat such in a loop of pain. Perhaps then we need a
new branch in which many tests are ignored or fail. In a sense, you have this
branch already, "reference_impl", but there is no code review. Perhaps, when
you reach substantial success, you do extensive rebasing of your branch to
squash related changes together, to thus facilitate review and _eventually_ a
nicer history so we can see what was changed why. I encourage you to actually
not wait to do this branch rebase cleanup but to do it often. What do you or
others think? I'm basically asking you to think of the end-game. I don't want
eventually see one massive crazy commit on master. I imagine possible a
massive merge commit from another branch, even though usually we discourage
merge commits, I think it makes sense here.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zenogantner commented on pull request #1673: LUCENE-9429 missing semicolon in overview.html
zenogantner commented on pull request #1673: URL: https://github.com/apache/lucene-solr/pull/1673#issuecomment-658867018 The change is trivial. Please let me know if it is okay to not have done the above checklist items in this case. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] zenogantner opened a new pull request #1673: LUCENE-9429 missing semicolon in overview.html
zenogantner opened a new pull request #1673: URL: https://github.com/apache/lucene-solr/pull/1673 # Description Add a missing semicolon in the documentation. # Solution self-explanatory # Tests Does not apply. # 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. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158511#comment-17158511
]
Mark Robert Miller commented on SOLR-14636:
---
Stability incoming!
This is my Sistine Chapel, I will never put more time or effort into anything
else, nor will anything else be as good. The ramp up to be able to get this
done was insane.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> *tests***:
> * *core*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *solrj*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *test-framework*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: near {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: near {color:#00875a}*solid*{color}
> with *{color:#de350b}ignores{color}*
> * *contrib/extraction*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: near {color:#00875a}*solid*{color}
> with {color:#de350b}*ignores*{color}
> * *contrib/langid*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: near {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9429) missing semicolon in overview.html
Zeno Gantner created LUCENE-9429: Summary: missing semicolon in overview.html Key: LUCENE-9429 URL: https://issues.apache.org/jira/browse/LUCENE-9429 Project: Lucene - Core Issue Type: Bug Components: general/javadocs Affects Versions: 8.6 Reporter: Zeno Gantner [https://lucene.apache.org/core/8_6_0/core/index.html] Line: Directory directory = FSDirectory.open(indexPath) should end with a semicolon. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley opened a new pull request #1672: SOLR-14651: Metrics History could disable better
dsmiley opened a new pull request #1672: URL: https://github.com/apache/lucene-solr/pull/1672 * SolrRrdBackendFactory should not be created if history is disabled * Disable MetricsHistoryHandler by default in tests * Await shutdown of all executors Interestingly, all tests passed with the history handler disabled. Isn't that a problem @sigram ? Somewhat related: I'm also inclined to make a little refactor in CoreContainer.shutdown such that `IOUtils.closeQuietly(metricsHistoryHandler.getSolrClient());` can move _into_ metricsHistoryHandler.close() 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14651) Metrics history could disable itself better
David Smiley created SOLR-14651: --- Summary: Metrics history could disable itself better Key: SOLR-14651 URL: https://issues.apache.org/jira/browse/SOLR-14651 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: metrics Reporter: David Smiley Assignee: David Smiley The MetricsHistoryHandler should disable itself better than it does. It will create a SolrRrdBackendFactory (which has an ExecutorService / thread pool) when it should not when the plugin is disabled. Furthermore, I think this should be disabled by default in tests, as it's excessive machinery that don't matter to 99.9% of tests. This will help our tests run more efficiently. While working on other issues, I also occasionally saw a thread leak failure with the RRD being the leaked threads. I see that in "close", we don't _wait_ for the executor to actually shut down but it should. CC [~ab] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158243#comment-17158243 ] Erick Erickson commented on SOLR-14066: --- As far as DIH is concerned, it's very simple to write a client that > queries the database and/or file system > sends the results to Solr Here's an example: https://lucidworks.com/post/indexing-with-solrj/ Ditto with Tika, also in the example. There are quite a number of sound reasons to move those operations off Solr. I've always considered them good for getting started, but not production-strength solutions. Helping with migration to a package and ongoing maintenance of that package is certainly the best way to demonstrate that the functionality is valuable enough to keep available. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158209#comment-17158209 ] Ishan Chattopadhyaya commented on SOLR-13973: - Velocity is deprecated in https://issues.apache.org/jira/browse/SOLR-14065, so I changed this issue to only deal with Tika deprecation. > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-13973: Description: Solr's primary responsibility should be to focus on search and scalability. Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us down. I propose that we deprecate it going forward. Tika can be run outside Solr. Going forward, if someone wants to use these, it should be possible to bring them into third party packages and installed via package manager. Plan is to just to throw warnings in logs and add deprecation notes in reference guide for now. Removal can be done in 9.0. was: Solr's primary responsibility should be to focus on search and scalability. Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us down. I propose that we deprecate it going forward. Tika can be run outside Solr, and no one needs to run velocity (if they do, they can consume JSON and do whatever transformations they need to do). Going forward, if someone wants to use these, it should be possible to bring them into third party packages and installed via package manager. Plan is to just to throw warnings in logs and add deprecation notes in reference guide for now. Removal can be done later (9x or 10x). > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr. Going forward, if someone wants to use these, > it should be possible to bring them into third party packages and installed > via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done in 9.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13973) Deprecate Tika
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-13973: Summary: Deprecate Tika (was: Deprecate Tika and Velocity) > Deprecate Tika > -- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr, and no one needs to run velocity (if they do, > they can consume JSON and do whatever transformations they need to do). Going > forward, if someone wants to use these, it should be possible to bring them > into third party packages and installed via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done later (9x or 10x). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13973) Deprecate Tika and Velocity
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-13973: Fix Version/s: 8.7 > Deprecate Tika and Velocity > --- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Major > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr, and no one needs to run velocity (if they do, > they can consume JSON and do whatever transformations they need to do). Going > forward, if someone wants to use these, it should be possible to bring them > into third party packages and installed via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done later (9x or 10x). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13973) Deprecate Tika and Velocity
[ https://issues.apache.org/jira/browse/SOLR-13973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ishan Chattopadhyaya updated SOLR-13973: Priority: Blocker (was: Major) > Deprecate Tika and Velocity > --- > > Key: SOLR-13973 > URL: https://issues.apache.org/jira/browse/SOLR-13973 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.7 > > > Solr's primary responsibility should be to focus on search and scalability. > Having to deal with the problems (CVEs) of Velocity, Tika etc. can slow us > down. I propose that we deprecate it going forward. > Tika can be run outside Solr, and no one needs to run velocity (if they do, > they can consume JSON and do whatever transformations they need to do). Going > forward, if someone wants to use these, it should be possible to bring them > into third party packages and installed via package manager. > Plan is to just to throw warnings in logs and add deprecation notes in > reference guide for now. Removal can be done later (9x or 10x). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158206#comment-17158206 ] Ishan Chattopadhyaya commented on SOLR-14066: - Thanks [~sniff]. bq. DIH is deprecated, but I could not find what is the recommended way of importing from DB now. I think you should tell users what they should use instead. [~Krzysiek_85], I've sent out an e-mail on this (and other deprecations): https://www.mail-archive.com/solr-user@lucene.apache.org/msg151728.html. Please let us know if there are any specific questions in this regard. Please keep in mind that removal of DIH is scheduled for 9.x, so users have plenty of time to try out the community packages before the feature is removed from Solr completely. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158188#comment-17158188 ] Dawid Weiss commented on SOLR-13939: I didn't write this and I don't know why he removed it - it's testing something and it works, right? I'd leave it in. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-13939: -- Attachment: SOLR-13939-misc.patch Status: Open (was: Open) This is the last bit of code to bring over and I'd like some opinions: [~mdrob] [~anshum1] There are some changes to XmlOffsetCorrector, but I see that there were some problems recently (Mike reverted and Anshum is looking). Should I skip any changes here? [~dweiss] Mark completely removed TestVirtualMethod, WDYT? It was put in in for a reason, if it's obsolete I can take it out. > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13939-misc.patch, SOLR-13939.patch, eoe_merged.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158177#comment-17158177 ] Erich Siffert commented on SOLR-14066: -- [Ishan Chattopadhyaya|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=ichattopadhyaya] thanks for the info! I will try the dih plugin as soon as I setup everything and I've updated my environment - but that will be next week, most probably in about 2 weeks earliest. Will then report back my findings. Thanx again! > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158172#comment-17158172 ] Ishan Chattopadhyaya commented on SOLR-14066: - bq. I think you should tell users what they should use instead. I'll send out an email to that effect shortly. Please excuse the delay, I'm encountering some access issues with some internal Apache systems. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158169#comment-17158169 ] Noble Paul commented on SOLR-14066: --- You'll be able to use the plugin with all your databases. We will publish instructions to do so > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158170#comment-17158170 ] Ishan Chattopadhyaya commented on SOLR-14066: - [~sniff], while the package comes with out of the box support for mariadb, I think adding your other connector jars in server/lib directory should work as it usually does. Please try that out and let us know how it goes. > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14066) Deprecate DIH and migrate to a community supported package
[ https://issues.apache.org/jira/browse/SOLR-14066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158163#comment-17158163 ] Erich Siffert commented on SOLR-14066: -- I completely agree with Krzysztof Debski - we have a similar setup/config where we feed/index Solre cores from different dbs - and actually the db is the master where info, docs etc. is/are maintained (but not searchable, that's where Solr comes into place!). So we need some tool where we can populate Solr cores with a DB as source... (and the dataimporthandler at [https://github.com/rohitbemax/dataimporthandler] provides only support for Maria DB - we currently have: Postgresql, Oracle, MS SQL Server and XML files as sources... > Deprecate DIH and migrate to a community supported package > -- > > Key: SOLR-14066 > URL: https://issues.apache.org/jira/browse/SOLR-14066 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Blocker > Fix For: 8.6 > > Attachments: image-2019-12-14-19-58-39-314.png > > Time Spent: 50m > Remaining Estimate: 0h > > DIH doesn't need to remain inside Solr anymore. Plan is to deprecate DIH in > 8.6, remove from 9.0. A community supported version of DIH (which can be used > with Solr's package manager) can be found here > https://github.com/rohitbemax/dataimporthandler. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1668: SOLR-13939: Extract any non-gradle related patches (deprecations, URL…
ErickErickson closed pull request #1668: URL: https://github.com/apache/lucene-solr/pull/1668 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158157#comment-17158157 ] ASF subversion and git services commented on SOLR-13939: Commit 481f9d1624e5a774668bc031f6ea74293759bed5 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=481f9d1 ] SOLR-13939: Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort (thread leaks) > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13939.patch, eoe_merged.patch > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13939) Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort
[ https://issues.apache.org/jira/browse/SOLR-13939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158156#comment-17158156 ] ASF subversion and git services commented on SOLR-13939: Commit f3de646560eefaf2d4f6bf7d9e147e7a84181e91 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f3de646 ] SOLR-13939: Extract any non-gradle related patches (deprecations, URL fixes, etc.) from gradle effort (thread leaks) > Extract any non-gradle related patches (deprecations, URL fixes, etc.) from > gradle effort > - > > Key: SOLR-13939 > URL: https://issues.apache.org/jira/browse/SOLR-13939 > Project: Solr > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13939.patch, eoe_merged.patch > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14648) Creating TLOG with pure multiple PULL replica, leading to 0 doc count
[ https://issues.apache.org/jira/browse/SOLR-14648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158133#comment-17158133 ] Erick Erickson commented on SOLR-14648: --- [~sayan.das] Hmmm, I suppose we could automatically check the version stamp on all the PULL replicas, they should be comparable. [~tflobbe] Right, I think I'd prioritize things this way: 1> don't create a new TLOG replica if there's no leader. You can fix this manually, but it's be something like 1.1> copy the index from some selected PULL replica somewhere 1.2> nuke the collection 1.3> create a single TLOG replica 1.4> shut down Solr, copy the saved index back and start Solr 1.5> build out the additional PULL replicas 1.6> yuck. but at least it doesn't leave you with nothing. 2> Implement the expert flag to get you out of this mess automatically. I'll add parenthetically that running with a single TLOG replica has no HA/DR built in by definition, it's not a good practice. We shouldn't nuke a collection even so of course. > Creating TLOG with pure multiple PULL replica, leading to 0 doc count > - > > Key: SOLR-14648 > URL: https://issues.apache.org/jira/browse/SOLR-14648 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: 8.3.1 >Reporter: Sayan Das >Priority: Major > > With only PULL replica whenever we create a new TLOG as leader fresh > replication happens, resulting in flushing the older indexes from existing > PULL replicas > Steps to replicate: > # Create 1 NRT or 1 TLOG replica as leader with multiple PULL replicas > # Index few documents and let it replicate in all the replicas > # Delete all the TLOG/NRT replica leaving PULL types > # Create a new TLOG/NRT as leader, once recovery completes it replaces all > the older indexes > In ideal scenario it should have replicated from any one of the PULL replicas > that has latest indexes after that TLOG/NRT replica should be registered as > leader -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] jpountz commented on a change in pull request #1610: LUCENE-9384: Backport for field sort optimization
jpountz commented on a change in pull request #1610:
URL: https://github.com/apache/lucene-solr/pull/1610#discussion_r454999807
##
File path: lucene/core/src/java/org/apache/lucene/search/SortField.java
##
@@ -394,6 +399,21 @@ public String toString() {
return buffer.toString();
}
+
+ /**
+ * For numeric sort fields, setting this field, indicates that
+ * the same numeric data has been indexed with two fields: doc values and
points and
+ * that these fields have the same name.
+ * This allows to use sort optimization and skip non-competitive documents.
+ */
+ public void setSkipNonCompetitiveDocs() {
Review comment:
IMO `setCanUsePoints` is good enough since this is a "SortField" so it
should be obvious that this is for sorting?
##
File path: lucene/core/src/java/org/apache/lucene/search/SortField.java
##
@@ -408,6 +428,7 @@ public boolean equals(Object o) {
&& other.reverse == this.reverse
&& Objects.equals(this.comparatorSource, other.comparatorSource)
&& Objects.equals(this.missingValue, other.missingValue)
+ && other.skipNonCompetitiveDocs == this.skipNonCompetitiveDocs
Review comment:
I wonder if we should actually take it into account for equals/hashcode
as this could disable index sorting optimizations, which check for equality of
the index-time and search-time SortField instances.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12661) Request with fl=[elevated] returns NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158109#comment-17158109
]
Erick Erickson commented on SOLR-12661:
---
[~dsmiley] Think we can close this?
> Request with fl=[elevated] returns NullPointerException
> ---
>
> Key: SOLR-12661
> URL: https://issues.apache.org/jira/browse/SOLR-12661
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.4
>Reporter: Georgy Khotyan
>Priority: Major
>
> Request with fl=[elevated] returns NullPointerException when Solr 7.4 used.
> It works with all older versions.
> Example:
> [http://localhost:8983/solr/my-core/select?q=*:*=true=1,2,3=true=[elevated]
> Is it a bug of 7.4 version?
> Exception:
> { "error":\\{ "trace":"java.lang.NullPointerException\n\tat
> org.apache.solr.response.transform.BaseEditorialTransformer.getKey(BaseEditorialTransformer.java:72)\n\tat
>
> org.apache.solr.response.transform.BaseEditorialTransformer.transform(BaseEditorialTransformer.java:52)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:120)\n\tat
> org.apache.solr.response.DocsStreamer.next(DocsStreamer.java:57)\n\tat
> org.apache.solr.response.TextResponseWriter.writeDocuments(TextResponseWriter.java:275)\n\tat
>
> org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:161)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209)\n\tat
>
> org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325)\n\tat
>
> org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120)\n\tat
>
> org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71)\n\tat
>
> org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.writeResponse(HttpSolrCall.java:806)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:535)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:382)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:326)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1751)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:582)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:534)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:283)\n\tat
> org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)\n\tat
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)\n\tat
>
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)\n\tat
> java.lang.Thread.run(Thread.java:748)\n", "code":500}
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To
[jira] [Updated] (SOLR-14650) Default autoscaling policy rules are ineffective
[
https://issues.apache.org/jira/browse/SOLR-14650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated SOLR-14650:
Fix Version/s: 8.7
> Default autoscaling policy rules are ineffective
>
>
> Key: SOLR-14650
> URL: https://issues.apache.org/jira/browse/SOLR-14650
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Affects Versions: 8.6
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Fix For: 8.7
>
>
> There's a faulty logic in {{Assign.usePolicyFramework()}} that makes the
> default policy (added in SOLR-12845) ineffective - that is, in the absence of
> any user-provided modifications to the policy rules the code reverts to
> LEGACY assignment.
> The logic in this method is convoluted and opaque, it's difficult for users
> to be sure what strategy is used when - instead we should make this choice
> explicit.
> (BTW, the default ruleset is probably too expensive for large clusters
> anyway, given the unresolved performance problems in the policy engine).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
