[jira] [Commented] (LUCENE-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components
[ https://issues.apache.org/jira/browse/LUCENE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196722#comment-17196722 ] Dawid Weiss commented on LUCENE-9464: - The MatchHighlighter is fully functional - I think it may be useful for folks who don't want to assemble their own pipeline from lower-level components. Tests already have a number of examples as well [1]. https://github.com/apache/lucene-solr/blob/master/lucene/highlighter/src/test/org/apache/lucene/search/matchhighlight/TestMatchHighlighter.java As for marking these classes with lucene.experimental - sure, we can. I am not sure what it implies though. That the API is still unstable, right? Because the code itself is fairly well tested. > Add high(er)-level hit highlighter example that demonstrates and uses > low-level components > -- > > Key: LUCENE-9464 > URL: https://issues.apache.org/jira/browse/LUCENE-9464 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h > 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 #1770: SOLR-14763 SolrJ HTTP/2 Async API using CompletableFuture
dsmiley commented on a change in pull request #1770:
URL: https://github.com/apache/lucene-solr/pull/1770#discussion_r489203281
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -862,15 +1011,32 @@ public RouteException(ErrorCode errorCode,
NamedList throwables, Map<
}
List inputCollections =
collection == null ? Collections.emptyList() :
StrUtils.splitSmart(collection, ",", true);
-return requestWithRetryOnStaleState(request, 0, inputCollections);
+
+CompletableFuture> apiFuture = new CompletableFuture<>();
+final AtomicReference>> currentFuture
= new AtomicReference<>();
+apiFuture.exceptionally((error) -> {
+ if (apiFuture.isCancelled()) {
+currentFuture.get().cancel(true);
+ }
+ return null;
+});
+
+requestWithRetryOnStaleState(request, 0, inputCollections, isAsyncRequest,
apiFuture, currentFuture);
+
+return apiFuture;
}
/**
* As this class doesn't watch external collections on the client side,
* there's a chance that the request will fail due to cached stale state,
* which means the state must be refreshed from ZK and retried.
*/
- protected NamedList
requestWithRetryOnStaleState(@SuppressWarnings({"rawtypes"})SolrRequest
request, int retryCount, List inputCollections)
+ protected void requestWithRetryOnStaleState(SolrRequest request,
Review comment:
> Another option is to ditch currentFuture altogether, and add
apiFuture.exceptionally statements each time a request retry is sent out to
take care of cancelling that specific request's future. Only difference is
there will be one callback per request made instead of just one overall;
however, all but the most recent callback will be no-ops as their corresponding
request futures will have already failed (and spawned a retry request). And I
don't imagine there'd be too many retries so the number of callbacks shouldn't
cause any noticeable slowdown during cancellation.
That sounds like an acceptable trade-off. A comment could point out the
imperfection.
> Might be misunderstanding your suggestion, but assuming a request is made
asynchronously, the (api) future would be returned to the user before the
request (and potential request retries) are completed. Thus, I don't think the
caller can do the retry (as the caller will have finished execution before a
request fails and a retry is decided upon).
By "the caller", I still meant internally. Put differently, imagine if the
implementation was iterative instead of recursive before you came along to add
async. Maybe that would lead to something easier to understand/maintain? If
not then nevermind. It seems you've ruled it out so okay.
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] (LUCENE-9464) Add high(er)-level hit highlighter example that demonstrates and uses low-level components
[ https://issues.apache.org/jira/browse/LUCENE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196718#comment-17196718 ] David Smiley commented on LUCENE-9464: -- Maybe these classes, particularly so-called "example" classes should be marked lucene.experimental? Maybe example code should actually be in tests? I leave to your discretion. > Add high(er)-level hit highlighter example that demonstrates and uses > low-level components > -- > > Key: LUCENE-9464 > URL: https://issues.apache.org/jira/browse/LUCENE-9464 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Time Spent: 1h > 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] noblepaul opened a new pull request #1878: SOLR-14871 Use Annotations for v2 APIs in/cluster path
noblepaul opened a new pull request #1878: URL: https://github.com/apache/lucene-solr/pull/1878 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-14872) unable to restore solr backup
Anil Paladugu created SOLR-14872:
Summary: unable to restore solr backup
Key: SOLR-14872
URL: https://issues.apache.org/jira/browse/SOLR-14872
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: Backup/Restore
Affects Versions: 7.0.1
Environment: prod
Reporter: Anil Paladugu
hey , i'm unable to restore backup in to collection . i'm getting error like
below
[http://localhost:8983/solr/admin/collections?action=RESTORE&name=CountryCodes&location=/opt/solr&collection=concodes&numShards=2&replicationFactor=2&async|https://qa_solr.voltusone.com/solr/admin/collections?action=RESTORE&name=CountryCodes&location=/opt/solr&collection=concodes&numShards=2&replicationFactor=2&async]
result:
{ "responseHeader":\{ "status":0, "QTime":2}, "Operation restore caused
exception:":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
Solr cloud with available number of nodes:2 is insufficient for restoring a
collection with 2 shards, total replicas per shard 6 and maxShardsPerNode -1.
Consider increasing maxShardsPerNode value OR number of available nodes.",
"exception":\{ "msg":"Solr cloud with available number of nodes:2 is
insufficient for restoring a collection with 2 shards, total replicas per shard
6 and maxShardsPerNode -1. Consider increasing maxShardsPerNode value OR number
of available nodes.", "rspCode":400}, "status":\{ "state":"failed",
"msg":"found [1000] in failed tasks"}}
--
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-13181) NullPointerException in org.apache.solr.request.macro.MacroExpander
[
https://issues.apache.org/jira/browse/SOLR-13181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196710#comment-17196710
]
David Smiley commented on SOLR-13181:
-
I stumbled over this where I work and I see here there's this existing issue.
See the PR. I modified more lines and different than the one Cesar did as I
tried to grok the code and clarify what's going on.
> NullPointerException in org.apache.solr.request.macro.MacroExpander
> ---
>
> Key: SOLR-13181
> URL: https://issues.apache.org/jira/browse/SOLR-13181
> Project: Solr
> Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: David Smiley
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13181.patch, home.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?a=${${b}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> at java.lang.String.substring(String.java:1967)
> at
> org.apache.solr.request.macro.MacroExpander._expand(MacroExpander.java:150)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:101)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:65)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:51)
> at
> org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:159)
> at
> org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:167)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:196)
> [...]
> {noformat}
> Parameter [macro
> expansion|http://yonik.com/solr-query-parameter-substitution/] seems to take
> place in {{org.apache.solr.request.macro.MacroExpander._expand(String val)}}.
> From reading the code of the function it seems that macros are not expanded
> inside curly brackets {{${...}}}, and so the {{${b}}} inside
> {noformat}
> ${${b}}
> {noformat}
> should not be expanded. But the function seems to fail to detect this
> specific case and graciously refuse to expand it.
> A possible fix could be updating the {{idx}} variable when the {{StrParser}}
> detects that no valid identifier can be found inside the brackets. See
> attached file
> {{0001-Macro-expander-fail-gracefully-on-unsupported-syntax.patch}}.
> We found this bug using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz
> testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].
--
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 #1877: SOLR-13181: param macro expansion could throw
dsmiley opened a new pull request #1877: URL: https://github.com/apache/lucene-solr/pull/1877 StringIndexOutOfBoundsException on bad syntax TODO run tests etc. https://issues.apache.org/jira/browse/SOLR-13181 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] [Assigned] (SOLR-13181) NullPointerException in org.apache.solr.request.macro.MacroExpander
[
https://issues.apache.org/jira/browse/SOLR-13181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley reassigned SOLR-13181:
---
Assignee: David Smiley
> NullPointerException in org.apache.solr.request.macro.MacroExpander
> ---
>
> Key: SOLR-13181
> URL: https://issues.apache.org/jira/browse/SOLR-13181
> Project: Solr
> Issue Type: Bug
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html]. The
> attached file ({{home.zip}}) gives the contents of folder {{/tmp/home}} that
> you will obtain by following the steps below:
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> {noformat}
>Reporter: Cesar Rodriguez
>Assignee: David Smiley
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13181.patch, home.zip
>
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?a=${${b}}
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> at java.lang.String.substring(String.java:1967)
> at
> org.apache.solr.request.macro.MacroExpander._expand(MacroExpander.java:150)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:101)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:65)
> at
> org.apache.solr.request.macro.MacroExpander.expand(MacroExpander.java:51)
> at
> org.apache.solr.request.json.RequestUtil.processParams(RequestUtil.java:159)
> at
> org.apache.solr.util.SolrPluginUtils.setDefaults(SolrPluginUtils.java:167)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:196)
> [...]
> {noformat}
> Parameter [macro
> expansion|http://yonik.com/solr-query-parameter-substitution/] seems to take
> place in {{org.apache.solr.request.macro.MacroExpander._expand(String val)}}.
> From reading the code of the function it seems that macros are not expanded
> inside curly brackets {{${...}}}, and so the {{${b}}} inside
> {noformat}
> ${${b}}
> {noformat}
> should not be expanded. But the function seems to fail to detect this
> specific case and graciously refuse to expand it.
> A possible fix could be updating the {{idx}} variable when the {{StrParser}}
> detects that no valid identifier can be found inside the brackets. See
> attached file
> {{0001-Macro-expander-fail-gracefully-on-unsupported-syntax.patch}}.
> We found this bug using [Diffblue Microservices
> Testing|https://www.diffblue.com/labs/]. Find more information on this [fuzz
> testing
> campaign|https://www.diffblue.com/blog/2018/12/19/diffblue-microservice-testing-a-sneak-peek-at-our-early-product-and-results].
--
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] (SOLR-14871) Use Annotations for v2 APIs in/cluster path
Noble Paul created SOLR-14871: - Summary: Use Annotations for v2 APIs in/cluster path Key: SOLR-14871 URL: https://issues.apache.org/jira/browse/SOLR-14871 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Reporter: Noble Paul Assignee: Noble Paul We have custom json specs for each of these APIs. With the annotation framework , it can be made simple and readable and we can eliminate a lot of 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-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196679#comment-17196679
]
Noble Paul commented on SOLR-14151:
---
The main problems are
* Core reload is buggy. Most likely there are race conditions
* Schema API reloads the core
Solutions are
* avoid core reload for schema changes
* fix core reload
This feature does not do any core reload. Me and Erick have spent quite some
time trying to debug core reload issues. The chances are that we will never fix
them any way. A least this way we expose those issues
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
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-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196663#comment-17196663
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Maybe a core reload bug that the new code here is triggering? Anyways, I think
the safest is to revert until whatever bug this is hitting is resolved.
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
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-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196616#comment-17196616
]
Noble Paul commented on SOLR-14151:
---
The problem is actually not with this feature. The bug is with our core
reloading
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
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-14824) Simplify set of Ref Guide build parameters
[
https://issues.apache.org/jira/browse/SOLR-14824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-14824:
--
Attachment: SOLR-14824.patch
Status: Open (was: Open)
Starting point:
* rip out all "bare bones" related stuff
* change the "template" style to use groovy ScriptTemplateEngine convention
** eliminating hte need for a dummyAntProject
* reduce down the set of properties we need/replace
** move any that are only needed in the map so that they are *only* inited in
the map
Next Steps:
* rip out "solrGuideVersion" / "solr-guide-version"
** replace usages of "solr-guide-version" in templates with "solr-docs-version"
* change command line syntax to be {{-Pdraft=true|false}} (defaulting to true)
> Simplify set of Ref Guide build parameters
> --
>
> Key: SOLR-14824
> URL: https://issues.apache.org/jira/browse/SOLR-14824
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build, documentation
>Reporter: Cassandra Targett
>Priority: Minor
> Attachments: SOLR-14824.patch
>
>
> While trying to solve LUCENE-9495, I thought it might be a good idea to try
> to simplify the set of variables and properties used during the Ref Guide
> build.
> There are 3 areas to work on:
> 1. Remove the "barebones-html" build. With Gradle the build is self-contained
> and {{gradlew check}} and {{gradle precommit}} could just build the full docs
> and check them.
> 2. Remove some properties that only existed for a hypothetical need related
> to the now-removed PDF.
> 3. Change remaining properties to be defined directly in build.gradle instead
> of relying on ant properties functionality.
--
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-14870) gradle build does not validate ref-guide -> javadoc links
[
https://issues.apache.org/jira/browse/SOLR-14870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196608#comment-17196608
]
Chris M. Hostetter commented on SOLR-14870:
---
i _think_ the "gradle-esque" way to do this is to make the following changes to
{{solr-ref-guide/build.gradle}}
* add a distinct task, similar to buildSite, that sets up the
{{localJavadocs}} property in a {{doFirst}} block
* change {{check.dependsOn buildSite}} to depend on this new task instead of
{{buildSite}}
* add {{documentation.dependsOn}} that depends on this new task
[~dweiss] am i close?
> gradle build does not validate ref-guide -> javadoc links
> -
>
> Key: SOLR-14870
> URL: https://issues.apache.org/jira/browse/SOLR-14870
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> the ant build had (has on 8x) a feature that ensured we didn't have any
> broken links between the ref guide and the javadocs...
> {code}
> depends="javadocs,changes-to-html,process-webpages">
> inheritall="false">
>
>
>
>
> {code}
> ...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}}
> just did interanal validation of the strucure of the guide, but this hook
> ment that {{cd solr && ant documentation}} (or {{ant precommit}}) would first
> build the javadocs; then build the ref-guide; then validate _all_ links i
> nthe ref-guide, even those to (local) javadocs
> While the "local.javadocs" property logic _inside_ the
> solr-ref-guide/build.xml was ported to build.gradle, the logic to leverage
> this functionality from the "solr" project doesn't seem to have been
> preserved -- so currently, {{gradle check}} doesn't know/care if someone adds
> a nonsense javadoc link to the ref-guide (or removes a class/method whose
> javadoc is already currently to from the ref guide)
--
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] (SOLR-14870) gradle build does not validate ref-guide -> javadoc links
Chris M. Hostetter created SOLR-14870:
-
Summary: gradle build does not validate ref-guide -> javadoc links
Key: SOLR-14870
URL: https://issues.apache.org/jira/browse/SOLR-14870
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
the ant build had (has on 8x) a feature that ensured we didn't have any broken
links between the ref guide and the javadocs...
{code}
{code}
...by default {{cd solr/solr-ref-guide && ant bare-bones-html-validation}} just
did interanal validation of the strucure of the guide, but this hook ment that
{{cd solr && ant documentation}} (or {{ant precommit}}) would first build the
javadocs; then build the ref-guide; then validate _all_ links i nthe ref-guide,
even those to (local) javadocs
While the "local.javadocs" property logic _inside_ the solr-ref-guide/build.xml
was ported to build.gradle, the logic to leverage this functionality from the
"solr" project doesn't seem to have been preserved -- so currently, {{gradle
check}} doesn't know/care if someone adds a nonsense javadoc link to the
ref-guide (or removes a class/method whose javadoc is already currently to from
the ref guide)
--
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-6152) Pre-populating values into search parameters on the query page of solr admin
[ https://issues.apache.org/jira/browse/SOLR-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196597#comment-17196597 ] Jan Høydahl commented on SOLR-6152: --- Did a last test, and think I found a bug in the logic around defType. # Select defType=edismax and do a search # Switch back to defType=lucene and do a search (works) # Check 'indent off' and do a new search # Now, the dropdown returns to 'edismax' Another minor thing is the feature "Remove non-visible fields from the request-params". I see in the code that it is designed to only work for dismax/edismax. However, we also have invisible fields for 'hl', 'facet', 'spatial' and 'spellcheck', which could be hidden the same way. A third observation is that once you check e.g. 'hl', then it sticks in the URL forever (with hl=false when unchecked), instead of be removed (default false) when unchecked. For custom request handlers that set hl=true as default, this can actually be a way to disable hl, so perhaps it is not so bad after all? > Pre-populating values into search parameters on the query page of solr admin > > > Key: SOLR-6152 > URL: https://issues.apache.org/jira/browse/SOLR-6152 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 4.3.1 >Reporter: Dmitry Kan >Assignee: Jan Høydahl >Priority: Major > Attachments: SOLR-6152.patch, SOLR-6152.patch, SOLR-6152.patch, > SOLR-6152.patch, copy_url_to_clipboard.png, copy_url_to_clipboard_v2.png, > prefilling_and_extending_the_multivalue_parameter_fq.png, > prepoluate_query_parameters_query_page.bmp > > > In some use cases, it is highly desirable to be able to pre-populate the > query page of solr admin with specific values. > In particular use case of mine, the solr admin user must pass a date range > value without which the query would fail. > It isn't easy to remember the value format for non-solr experts, so I would > like to have a way of hooking that value "example" into the query page. > See the screenshot attached, where I have inserted the fq parameter with date > range into the Raw Query Parameters. -- 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-14828) reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState
[
https://issues.apache.org/jira/browse/SOLR-14828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196582#comment-17196582
]
Anshum Gupta commented on SOLR-14828:
-
+1 on converting this to {{INFO}} and ideally also changing the message to not
say that it 'failed' or at least saying it will be retried.
> reduce 'error' logging noise in
> BaseCloudSolrClient.requestWithRetryOnStaleState
>
>
> Key: SOLR-14828
> URL: https://issues.apache.org/jira/browse/SOLR-14828
> Project: Solr
> Issue Type: Task
> Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently -- e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java#L960-L961
> -- an error is logged even if request retrying will happen (and hopefully
> succeed).
> This task proposes to 'info' or 'warn' rather than 'error' log if the request
> will be retried.
--
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] ctargett edited a comment on pull request #1869: SOLR-14866 autowidth tables in ref guide
ctargett edited a comment on pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#issuecomment-693000958 So, the changes look fine enough to me, but I don't think they're actually needed. The `%autowidth.spread` works by setting a `spread` class on the `` element. This is the default, though, so it's set even without defining that attribute. The way it has been with `cols="30,70"`, or whatever it was for each table, overrode that by setting the `` element on each table to set the width of each column. I suspect if you just remove the `cols` parameter and TODO note, the table will look pretty close the way it does with the new `autospread` attribute. I figured this out by inspecting the HTML for tables that had been created after the conversion from Confluence (when these TODOs were introduced), such as the one on `aliases.adoc`, which don't have the TODO. I noticed that it gets `` (plus some other classes) and the `` is set to an equal % for each column. Which is basically which happens with the change here. It's also possible to avoid setting an explicit `options="header"` if all tables include an empty line between the first row and the subsequent rows. I'll leave that up to individual preference, though - the table in `aliases.adoc` does that, but others may not know to do that so an example of explicitly setting the header row isn't a negative. 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] ctargett commented on pull request #1869: SOLR-14866 autowidth tables in ref guide
ctargett commented on pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#issuecomment-693000958 So, the changes look fine enough to me, but I don't think they're actually needed. The `%autowidth.spread` works by setting a `spread` class on the element. This is the default, though, so it's set even without defining that attribute. The way it has been with `cols="30,70"`, or whatever it was for each table, overrode that by setting the `` element on each table to set the width of each column. I suspect if you just remove the `cols` parameter and TODO note, the table will look pretty close the way it does with the new `autospread` attribute. I figured this out by inspecting the HTML for tables that had been created after the conversion from Confluence (when these TODOs were introduced), such as the one on `aliases.adoc`, which don't have the TODO. I noticed that it gets `` (plus some other classes) and the `` is set to an equal % for each column. Which is basically which happens with the change here. It's also possible to avoid setting an explicit `options="header"` if all tables include an empty line between the first row and the subsequent rows. I'll leave that up to individual preference, though - the table in `aliases.adoc` does that, but others may not know to do that so an example of explicitly setting the header row isn't a negative. 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] tflobbe commented on a change in pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on a change in pull request #1861:
URL: https://github.com/apache/lucene-solr/pull/1861#discussion_r489001982
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
+ zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
+ getBytes(StandardCharsets.UTF_8), true);
+}
ZipInputStream zis = new ZipInputStream(inputStream,
StandardCharsets.UTF_8);
ZipEntry zipEntry = null;
while ((zipEntry = zis.getNextEntry()) != null) {
String filePathInZk = configPathInZk + "/" + zipEntry.getName();
+ if (filePathInZk.endsWith("/")) {
+filesToDelete.remove(filePathInZk.substring(0, filePathInZk.length()
-1));
+ } else {
+filesToDelete.remove(filePathInZk);
+ }
if (zipEntry.isDirectory()) {
-zkClient.makePath(filePathInZk, true);
+zkClient.makePath(filePathInZk, false, true);
Review comment:
Can that ever happen in a configset?
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] tflobbe commented on a change in pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
tflobbe commented on a change in pull request #1861:
URL: https://github.com/apache/lucene-solr/pull/1861#discussion_r489001572
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
Review comment:
As it currently stands, an overwrite never updates the "trusted" flag,
if it wasn't trusted before, it'll continue to be untrusted after the upgrade.
If it was trusted, only an authenticated request would be allowed. I see your
point that if "cleanup" is set to "true", an authenticated request could turn
the configset to trusted, is that what you are suggesting?
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] (LUCENE-9378) Configurable compression for BinaryDocValues
[
https://issues.apache.org/jira/browse/LUCENE-9378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196567#comment-17196567
]
Julie Tibshirani commented on LUCENE-9378:
--
Adding another datapoint in case it’s helpful: Elasticsearch uses binary doc
values to store high-dimensional float vectors (the `dense_vector` type). The
vectors are typically used to score documents. This is a very similar use case
to the one [~alexklibisz] describes.
In a best case scenario where we index random 100-dimensional float vectors (so
they don’t compress well), and scan over all documents (so we don’t decompress
data that’s not needed), we see a QPS drop of ~10%:
{{Algorithm QPS}}
{{Old version 66.989}}
{{New version 60.906}}
I would guess [~nicot]'s example also falls under the general category of
"storing/ loading numeric feature vectors"? For this type of data, it’s common
to take a specialized approach instead of applying a general compression
algorithm (like using a sparse vector representation, using fewer bytes for
each vector element, etc.)
> Configurable compression for BinaryDocValues
>
>
> Key: LUCENE-9378
> URL: https://issues.apache.org/jira/browse/LUCENE-9378
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Viral Gandhi
>Priority: Minor
> Attachments: hotspots-v76x.png, hotspots-v76x.png, hotspots-v76x.png,
> hotspots-v76x.png, hotspots-v76x.png, hotspots-v77x.png, hotspots-v77x.png,
> hotspots-v77x.png, hotspots-v77x.png, image-2020-06-12-22-17-30-339.png,
> image-2020-06-12-22-17-53-961.png, image-2020-06-12-22-18-24-527.png,
> image-2020-06-12-22-18-48-919.png, snapshot-v77x.nps, snapshot-v77x.nps,
> snapshot-v77x.nps, snapshots-v76x.nps, snapshots-v76x.nps, snapshots-v76x.nps
>
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> Lucene 8.5.1 includes a change to always [compress
> BinaryDocValues|https://issues.apache.org/jira/browse/LUCENE-9211]. This
> caused (~30%) reduction in our red-line QPS (throughput).
> We think users should be given some way to opt-in for this compression
> feature instead of always being enabled which can have a substantial query
> time cost as we saw during our upgrade. [~mikemccand] suggested one possible
> approach by introducing a *mode* in Lucene80DocValuesFormat (COMPRESSED and
> UNCOMPRESSED) and allowing users to create a custom Codec subclassing the
> default Codec and pick the format they want.
> Idea is similar to Lucene50StoredFieldsFormat which has two modes,
> Mode.BEST_SPEED and Mode.BEST_COMPRESSION.
> Here's related issues for adding benchmark covering BINARY doc values
> query-time performance - [https://github.com/mikemccand/luceneutil/issues/61]
--
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-14868) nested document 'remove' operation should "delete in place"
[ https://issues.apache.org/jira/browse/SOLR-14868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196565#comment-17196565 ] Chris M. Hostetter commented on SOLR-14868: --- Note that "delete by query" can be used as a work around to more efficiently delete some nested documents (w/o complete re-indexing the root document) but... * delete by query has it's own perf bottlenecks (distributed lock across all shards) * this exposes SOLR-14869 > nested document 'remove' operation should "delete in place" > --- > > Key: SOLR-14868 > URL: https://issues.apache.org/jira/browse/SOLR-14868 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chris M. Hostetter >Priority: Major > > Currently, if you use the "remove" atomic update operation for nested > documents, it completely re-indexes the "root" document and all remaining > child documents (after logically removing the specified child and i'ts > descendants) > ideally, unless this operation is combined with other atomic update > operations, "remove" should be done "in place" -- just using the IndexWriter > to mark the specified child document (and it's descendants) as deleted. > (The full Re-Indexing of the 'root' level document can be very slow for large > deeply nested documents) -- 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-14869) [child] transformer includes deleted documents
[
https://issues.apache.org/jira/browse/SOLR-14869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196564#comment-17196564
]
Chris M. Hostetter commented on SOLR-14869:
---
Assume we do the following with {{bin/solr -e cloud -noprompt}} ...
{noformat}
curl -X POST -H 'Content-type:application/json' --data-binary '{
"replace-field":{
"name":"_root_",
"type":"string",
"docValues":true }
}' http://localhost:8983/solr/gettingstarted/schema
curl -X POST 'http://localhost:8983/solr/gettingstarted/update?commit=true' -H
'Content-Type: application/json' --data-binary '[
{ "id": "P11!prod",
"name_s": "Swingline Stapler",
"description_t": "The Cadillac of office staplers ...",
"skus": [ { "id": "P11!S21",
"color_s": "RED",
"price_i": 42,
"manuals": [ { "id": "P11!D41",
"name_s": "Red Swingline Brochure",
"pages_i":1,
"content_t": "..."
} ]
},
{ "id": "P11!S31",
"color_s": "BLACK",
"price_i": 3
} ],
"manuals": [ { "id": "P11!D51",
"name_s": "Quick Reference Guide",
"pages_i":1,
"content_t": "How to use your stapler ..."
},
{ "id": "P11!D61",
"name_s": "Warranty Details",
"pages_i":42,
"content_t": "... lifetime guarantee ..."
} ]
},
{ "id": "P22!prod",
"name_s": "Mont Blanc Fountain Pen",
"description_t": "A Premium Writing Instrument ...",
"skus": [ { "id": "P22!S22",
"color_s": "RED",
"price_i": 89,
"manuals": [ { "id": "P22!D42",
"name_s": "Red Mont Blanc Brochure",
"pages_i":1,
"content_t": "..."
} ]
},
{ "id": "P22!S32",
"color_s": "BLACK",
"price_i": 67
} ],
"manuals": [ { "id": "P22!D52",
"name_s": "How To Use A Pen",
"pages_i":42,
"content_t": "Start by removing the cap ..."
} ]
} ]'
{noformat}
Then note the following...
{noformat}
$ curl
'http://localhost:8983/solr/gettingstarted/select?q=id:P11!prod&fl=id,[child],skus,manuals,[docid]'
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":18,
"params":{
"q":"id:P11!prod",
"fl":"id,[child],skus,manuals,[docid]"}},
"response":{"numFound":1,"start":0,"maxScore":0.9452007,"numFoundExact":true,"docs":[
{
"id":"P11!prod",
"skus":[
{
"id":"P11!S21",
"[docid]":1,
"manuals":[
{
"id":"P11!D41",
"[docid]":0}]},
{
"id":"P11!S31",
"[docid]":2}],
"manuals":[
{
"id":"P11!D51",
"[docid]":3},
{
"id":"P11!D61",
"[docid]":4}],
"[docid]":5}]
}}
$ curl -X POST 'http://localhost:8983/solr/gettingstarted/update?commit=true'
-H 'Content-Type: application/json' --data-binary '{"delete" : { "query":
"id:P11!D51" }}'
{
"responseHeader":{
"rf":2,
"status":0,
"QTime":73}}
$ curl 'http://localhost:8983/solr/gettingstarted/select?q=id:P11!D51'
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":22,
"params":{
"q":"id:P11!D51"}},
"response":{"numFound":0,"start":0,"maxScore":0.0,"numFoundExact":true,"docs":[]
}}
{noformat}
...nested document has been deleted, but requests to the parent using
{{\[child\]}} still return it...
{noformat}
$ curl
'http://localhost:8983/solr/gettingstarted/select?q=id:P11!prod&fl=id,[child],skus,manuals,[docid]'
{
"responseHeader":{
"zkConnected":true,
"status":0,
"QTime":18,
"params":{
"q":"id:P11!prod",
"fl":"id,[child],skus,manuals,[docid]"}},
"response":{"numFound":1,"start":0,"maxScore":0.9452007,"numFoundExact":true,"docs":[
{
"id":"P11!prod",
"skus":[
{
"id":"P11!S21",
"[docid]":1,
"manuals":[
{
"id":"P11!D41",
"[docid]":0}]},
{
"id":"P11!S31",
"[docid]":2}],
"manuals":[
{
"id":"P11!D51",
"[docid]":3},
{
"id":"P11!D61",
"[docid]":4}],
"[docid]":5}]
}}
{noformat}
> [child] transformer includes deleted documents
> --
>
> Key: SOLR-14869
>
[jira] [Created] (SOLR-14869) [child] transformer includes deleted documents
Chris M. Hostetter created SOLR-14869:
-
Summary: [child] transformer includes deleted documents
Key: SOLR-14869
URL: https://issues.apache.org/jira/browse/SOLR-14869
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Chris M. Hostetter
If you have nested documents that include "deleted" docs (ie: using "delete by
query") the {{\[child\]}} transformer still include those deleted docs i it's
output
--
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-14799) JWT authentication plugin should not require subject, unless set as principalClaim
[ https://issues.apache.org/jira/browse/SOLR-14799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-14799: Fix Version/s: 8.7 > JWT authentication plugin should not require subject, unless set as > principalClaim > -- > > Key: SOLR-14799 > URL: https://issues.apache.org/jira/browse/SOLR-14799 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher >Priority: Major > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > Some environments don't use "sub" (subject) claim with Solr, but rather rely > on a custom claim (such as "solrid") to be required. This ticket is about > making subject claim optional, and only required when principalClaim=sub -- 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-14799) JWT authentication plugin should not require subject, unless set as principalClaim
[ https://issues.apache.org/jira/browse/SOLR-14799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-14799: Priority: Blocker (was: Major) > JWT authentication plugin should not require subject, unless set as > principalClaim > -- > > Key: SOLR-14799 > URL: https://issues.apache.org/jira/browse/SOLR-14799 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erik Hatcher >Priority: Blocker > Fix For: 8.7 > > Time Spent: 40m > Remaining Estimate: 0h > > Some environments don't use "sub" (subject) claim with Solr, but rather rely > on a custom claim (such as "solrid") to be required. This ticket is about > making subject claim optional, and only required when principalClaim=sub -- 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-14868) nested document 'remove' operation should "delete in place"
[ https://issues.apache.org/jira/browse/SOLR-14868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196560#comment-17196560 ] Chris M. Hostetter commented on SOLR-14868: --- I created this issue mainly as a starting point for disucssion in case it spawned any idea from the folks with a good understanding of the nested documents logic as to how we could go about doing this in a more efficient way. Practically speaking, i'm not really sure if/how there is a good way to go about implementing this improvement to the current "remove" atomic update operation, given where/how the atomic update logic is handled in the update logic flow. An alternative approach might be to revisit the decision to prevent "delete by id" from being usable on "child" documents. I'm not even sure where/how this happens, but in theory whatever bit of code checks the ID value to see if it's _not_ a "root" id could -- instead of ignoring child ids -- pull the "root" "nest_path" of the specified ID out of DocValues and use them to build a "delete by query" for the both specified (child) doc and any descendants it has. > nested document 'remove' operation should "delete in place" > --- > > Key: SOLR-14868 > URL: https://issues.apache.org/jira/browse/SOLR-14868 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Chris M. Hostetter >Priority: Major > > Currently, if you use the "remove" atomic update operation for nested > documents, it completely re-indexes the "root" document and all remaining > child documents (after logically removing the specified child and i'ts > descendants) > ideally, unless this operation is combined with other atomic update > operations, "remove" should be done "in place" -- just using the IndexWriter > to mark the specified child document (and it's descendants) as deleted. > (The full Re-Indexing of the 'root' level document can be very slow for large > deeply nested documents) -- 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] (SOLR-14868) nested document 'remove' operation should "delete in place"
Chris M. Hostetter created SOLR-14868: - Summary: nested document 'remove' operation should "delete in place" Key: SOLR-14868 URL: https://issues.apache.org/jira/browse/SOLR-14868 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Chris M. Hostetter Currently, if you use the "remove" atomic update operation for nested documents, it completely re-indexes the "root" document and all remaining child documents (after logically removing the specified child and i'ts descendants) ideally, unless this operation is combined with other atomic update operations, "remove" should be done "in place" -- just using the IndexWriter to mark the specified child document (and it's descendants) as deleted. (The full Re-Indexing of the 'root' level document can be very slow for large deeply nested documents) -- 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] thelabdude closed pull request #1873: Reference impl gradle updates
thelabdude closed pull request #1873: URL: https://github.com/apache/lucene-solr/pull/1873 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] thelabdude commented on pull request #1873: Reference impl gradle updates
thelabdude commented on pull request #1873: URL: https://github.com/apache/lucene-solr/pull/1873#issuecomment-692981125 These commits have been pushed into the `reference_impl_dev` branch, this PR was mainly for comparison and review purposes, closing now. 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] [Resolved] (SOLR-14849) Investigate test failures in TestReRankQParserPlugin.testMinExactCount
[
https://issues.apache.org/jira/browse/SOLR-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe resolved SOLR-14849.
--
Fix Version/s: 8.6
master (9.0)
Resolution: Fixed
I haven't seen failures since this commit. I'll resolve the issue, we can
reopen if failures occur again
> Investigate test failures in TestReRankQParserPlugin.testMinExactCount
> --
>
> Key: SOLR-14849
> URL: https://issues.apache.org/jira/browse/SOLR-14849
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>
> I've seen a couple failures in Jenkins, such as:
> {noformat}
> FAILED: org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount
> Error Message:
> Exception during query
> Stack Trace:
> java.lang.RuntimeException: Exception during query
> at
> __randomizedtesting.SeedInfo.seed([D74824A60D443A78:A2C81E3EE299C40F]:0)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1016)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:976)
> at
> org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount(TestReRankQParserPlugin.java:675)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.Stateme
[jira] [Assigned] (SOLR-14849) Investigate test failures in TestReRankQParserPlugin.testMinExactCount
[
https://issues.apache.org/jira/browse/SOLR-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Eduardo Fernandez Lobbe reassigned SOLR-14849:
Assignee: Tomas Eduardo Fernandez Lobbe
> Investigate test failures in TestReRankQParserPlugin.testMinExactCount
> --
>
> Key: SOLR-14849
> URL: https://issues.apache.org/jira/browse/SOLR-14849
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Minor
> Fix For: master (9.0), 8.6
>
>
> I've seen a couple failures in Jenkins, such as:
> {noformat}
> FAILED: org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount
> Error Message:
> Exception during query
> Stack Trace:
> java.lang.RuntimeException: Exception during query
> at
> __randomizedtesting.SeedInfo.seed([D74824A60D443A78:A2C81E3EE299C40F]:0)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:1016)
> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:976)
> at
> org.apache.solr.search.TestReRankQParserPlugin.testMinExactCount(TestReRankQParserPlugin.java:675)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.T
[jira] [Commented] (SOLR-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196525#comment-17196525
]
ASF subversion and git services commented on SOLR-10471:
Commit 58d13608b45d5e412fa194d1b1a8a4ef43c0cf6a in lucene-solr's branch
refs/heads/SOLR-14866 from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=58d1360 ]
SOLR-10471: update default zk session timeout in bin/solr* scripts
* zkClientTimeout value is already set to 30s in solr.xml but
same update was missing from bin/solr* script
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-10471.patch, SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
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-9510) SortingStoredFieldsConsumer should use a format that has better random-access
[ https://issues.apache.org/jira/browse/LUCENE-9510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196521#comment-17196521 ] ASF subversion and git services commented on LUCENE-9510: - Commit 97a4af6890d3efc64bfb4a4d4dd6ffc02d8b7240 in lucene-solr's branch refs/heads/SOLR-14866 from Adrien Grand [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=97a4af6 ] LUCENE-9510: Don't pull a merge instance when flushing stored fields out-of-order. (#1872) With recent changes to stored fields that split blocks into several sub blocks, the merge instance has become much slower at random access since it would decompress all sub blocks when accessing a document. Since stored fields likely get accessed in random order at flush time when index sorting is enabled, it's better not to use the merge instance. On a synthetic benchmark that has one stored field and one numeric doc-value field that is used for sorting and fed with random values, this made indexing more than 4x faster. > SortingStoredFieldsConsumer should use a format that has better random-access > - > > Key: LUCENE-9510 > URL: https://issues.apache.org/jira/browse/LUCENE-9510 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > We noticed some indexing rate regressions in Elasticsearch after upgrading to > a new Lucene snapshot. This is due to the fact that > SortingStoredFieldsConsumer is using the default codec to write stored fields > on flush. Compression doesn't matter much for this case since these are > temporary files that get removed on flush after the segment is sorted anyway > so we could switch to a format that has faster random access. -- 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-14725) Fix the update() stream docs
[ https://issues.apache.org/jira/browse/SOLR-14725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196519#comment-17196519 ] ASF subversion and git services commented on SOLR-14725: Commit 5edd4b21af09c1456b0485590d71c690db0a0b31 in lucene-solr's branch refs/heads/SOLR-14866 from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5edd4b2 ] SOLR-14725 update batchSize parameter docs for update() and delete() stream expressions (#1729) * batchSize is optional parameter with a default value * typo > Fix the update() stream docs > > > Key: SOLR-14725 > URL: https://issues.apache.org/jira/browse/SOLR-14725 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 8.6 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Minor > Fix For: 8.7 > > Time Spent: 20m > Remaining Estimate: 0h > > Ref guide specifies the batchSize is mandatory, but it's now optional with a > "sane default" of 250. Check other batchSize parameters. -- 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-9516) Remove DocConsumer and IndexingChain from Lucene
[ https://issues.apache.org/jira/browse/LUCENE-9516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196524#comment-17196524 ] ASF subversion and git services commented on LUCENE-9516: - Commit f655d97b54f426d9b590e7f853e8de43e50e5164 in lucene-solr's branch refs/heads/SOLR-14866 from Simon Willnauer [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f655d97 ] LUCENE-9516: Remove DocConsumer and IndexingChain from Lucene (#1867) This removes the ability to replace the IndexingChain / DocConsumer in Lucenes IndexWriter. The interface is not sufficient to efficiently replace the functionality with reasonable efforts. It also seems it's completely unused at this point and hasn't been maintained in years. > Remove DocConsumer and IndexingChain from Lucene > > > Key: LUCENE-9516 > URL: https://issues.apache.org/jira/browse/LUCENE-9516 > Project: Lucene - Core > Issue Type: Wish >Reporter: Simon Willnauer >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > > Disclaimer: This is a breaking change! > We allow today to replace the entire indexing chain which is a fundamental > part of our software. I personally don't know if there are any users of this > API. but given the complexity I personally don't think we should further > support this. If you are willing to implement this entire thing yourself I > really wonder if you are better off building lucene from the source. An > option like this on IWC might make users look into it while I am convinced > they shouldn't. It's too complex and nothing is made for reuse down there. I > wonder what others think but from my perspective it's time to remove it 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-14590) Add support for FeatureField in Solr
[
https://issues.apache.org/jira/browse/SOLR-14590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196523#comment-17196523
]
ASF subversion and git services commented on SOLR-14590:
Commit 7d62cad1a8f1ff03a4d50fc76f14fef058108054 in lucene-solr's branch
refs/heads/SOLR-14866 from Alexandre Rafalovitch
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d62cad ]
SOLR-14862: Update RefGuide page for support fied types (#1865)
Added mentions for BBoxField, NestPathField, RankField (and placehold for
QParser, from SOLR-14590), RptWithGeometrySpatialField
Moved Deprecated types into separate table to improve reading comprehension
Added some cross-references for more in-depth reading.
> Add support for FeatureField in Solr
>
>
> Key: SOLR-14590
> URL: https://issues.apache.org/jira/browse/SOLR-14590
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Assignee: Tomas Eduardo Fernandez Lobbe
>Priority: Major
> Fix For: master (9.0), 8.6
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> {{FeatureField}}’s allow users to store scoring factors in the index that are
> encoded as term frequencies. By doing this, {{FeatureFields}} can be used in
> combination with the {{minExactCount}} parameter to skip over non-competitive
> documents, and produce results faster. See LUCENE-8197
--
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-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196526#comment-17196526 ] ASF subversion and git services commented on LUCENE-9488: - Commit 3134f10a4255b5d766462251868a43e9bb9c03ce in lucene-solr's branch refs/heads/SOLR-14866 from Mike Drob [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3134f10 ] LUCENE-9488 Update release process to work with gradle (#1860) * Restore lucene/version.properties * Switch release wizard commands from ant to gradle equivalents * Remove remaining checks for ant * Remove checks for Java 8 * Update Copyright year * Minor bug fixes around determining next version for a major release > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196520#comment-17196520 ] ASF subversion and git services commented on SOLR-14789: Commit bc0b29eca3a3ebb616e7e9d6fcc4fde729b88b59 in lucene-solr's branch refs/heads/SOLR-14866 from Houston Putman [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bc0b29e ] SOLR-14789: Rename docker tests task, adding missing credit in CHANGES (#1871) > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the [dev mailing > list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] > and SOLR-11245. -- 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-14862) Update RefGuide page for field types included with Solr
[ https://issues.apache.org/jira/browse/SOLR-14862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196522#comment-17196522 ] ASF subversion and git services commented on SOLR-14862: Commit 7d62cad1a8f1ff03a4d50fc76f14fef058108054 in lucene-solr's branch refs/heads/SOLR-14866 from Alexandre Rafalovitch [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7d62cad ] SOLR-14862: Update RefGuide page for support fied types (#1865) Added mentions for BBoxField, NestPathField, RankField (and placehold for QParser, from SOLR-14590), RptWithGeometrySpatialField Moved Deprecated types into separate table to improve reading comprehension Added some cross-references for more in-depth reading. > Update RefGuide page for field types included with Solr > --- > > Key: SOLR-14862 > URL: https://issues.apache.org/jira/browse/SOLR-14862 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Major > Fix For: master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > Ref Guide seems to be missing a couple of types that we have in Solr on the > relevant page: > [https://lucene.apache.org/solr/guide/8_6/field-types-included-with-solr.html] > Examples are: > * SortableTextField > * BBoxField > * Some other Spatial types > Need to review the _org.apache.solr.schema_ package and update the guide. > Also, as there is quite a number of deprecated types now, it may be worth > moving them into a separate box below, to make it easier for new people to > scan the list and see what may be appropriate. > And cross-link the references where appropriate. Maybe including to Javadoc > as well. -- 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] epugh commented on a change in pull request #1869: SOLR-14866 autowidth tables in ref guide
epugh commented on a change in pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#discussion_r488942881 ## File path: solr/solr-ref-guide/src/performance-statistics-reference.adoc ## @@ -191,9 +187,7 @@ You can get the statistics shown in the table below with an API request such as The following statistics are available for each of the caches mentioned above: -// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed - -[cols="25,75",options="header"] +[%autowidth.spread,width="100%",options="header"] Review comment: Should we just keep the old format? 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] epugh commented on a change in pull request #1869: SOLR-14866 autowidth tables in ref guide
epugh commented on a change in pull request #1869:
URL: https://github.com/apache/lucene-solr/pull/1869#discussion_r488942550
##
File path: solr/solr-ref-guide/src/other-parsers.adoc
##
@@ -237,7 +237,7 @@ Comma separated list of tags for excluding queries from
parameters above. See ex
{!bool filter=foo should=bar}
-Parameters might also be multivalue references. The former example above is
equivlent to
Review comment:
okay, fixed the typo, but left spacing to match the other spacing.
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] epugh commented on a change in pull request #1869: SOLR-14866 autowidth tables in ref guide
epugh commented on a change in pull request #1869: URL: https://github.com/apache/lucene-solr/pull/1869#discussion_r488942138 ## File path: solr/solr-ref-guide/src/performance-statistics-reference.adoc ## @@ -191,9 +187,7 @@ You can get the statistics shown in the table below with an API request such as The following statistics are available for each of the caches mentioned above: -// TODO: Change column width to %autowidth.spread when https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed - -[cols="25,75",options="header"] +[%autowidth.spread,width="100%",options="header"] Review comment: There was another example where I decided the autowidth was worse than the manual spaced one, so I removed the TODO but left it as a`[cols=]` style. If you think it's better to keep the `[cols=]` let me know and I'll revert that change! 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] HoustonPutman commented on a change in pull request #1861: SOLR-10391: Add overwrite option to UPLOAD ConfigSet action
HoustonPutman commented on a change in pull request #1861:
URL: https://github.com/apache/lucene-solr/pull/1861#discussion_r488913454
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
+ zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
+ getBytes(StandardCharsets.UTF_8), true);
+}
ZipInputStream zis = new ZipInputStream(inputStream,
StandardCharsets.UTF_8);
ZipEntry zipEntry = null;
while ((zipEntry = zis.getNextEntry()) != null) {
String filePathInZk = configPathInZk + "/" + zipEntry.getName();
+ if (filePathInZk.endsWith("/")) {
+filesToDelete.remove(filePathInZk.substring(0, filePathInZk.length()
-1));
+ } else {
+filesToDelete.remove(filePathInZk);
+ }
if (zipEntry.isDirectory()) {
-zkClient.makePath(filePathInZk, true);
+zkClient.makePath(filePathInZk, false, true);
Review comment:
We might want to clear data that the znode has if it exists and has data.
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
Review comment:
If you are overwriting an untrusted configSet with a trusted configSet,
I din't think that will get updated here. I guess you would only want it if
CLEANUP is true, since only then are you sure that all of the content is
trusted.
So doing it in that if statement would probably work.
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/ConfigSetsHandler.java
##
@@ -170,21 +176,90 @@ private void handleConfigUploadRequest(SolrQueryRequest
req, SolrQueryResponse r
// Create a node for the configuration in zookeeper
boolean trusted = getTrusted(req);
-zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
-getBytes(StandardCharsets.UTF_8), true);
+Set filesToDelete = Collections.emptySet();
+if (overwritesExisting) {
+ if (!trusted) {
+ensureOverwritingUntrustedConfigSet(zkClient, configPathInZk);
+ }
+ if (req.getParams().getBool(ConfigSetParams.CLEANUP, false)) {
+filesToDelete = getAllConfigsetFiles(zkClient, configPathInZk);
+ }
+} else {
+ zkClient.makePath(configPathInZk, ("{\"trusted\": " +
Boolean.toString(trusted) + "}").
+ getBytes(StandardCharsets.UTF_8), true);
+}
ZipInputStream zis = new ZipInputStream(inputStream,
StandardCharsets.UTF_8);
ZipEntry zipEntry = null;
while ((zipEntry = zis.getNextEntry()) != null) {
String filePathInZk = configPathInZk + "/" + zipEntry.getName();
+ if (filePathInZk.endsWith("/")) {
+filesToDelete.remove(filePathInZk.substring(0, filePathInZk.length()
-1));
+ } else {
+filesToDelete.remove(filePathInZk);
+ }
if (zipEntry.isDirectory()) {
-zkClient.makePath(filePathInZk, true);
+zkClient.makePath(filePathInZk, false, true);
} else {
createZkNodeIfNotExistsAndSetData(zkClient, filePathInZk,
IOUtils.toByteArray(zis));
}
}
zis.close();
+deleteUnusedFiles(zkClient, filesToDelete);
+ }
+
+ private void deleteUnusedFiles(SolrZkClient zkClient, Set
filesToDelete) throws InterruptedException, KeeperException {
+if (!filesToDelete.isEmpty()) {
+ if (log.isInfoEnabled()) {
+log.info("Cleaning up {} unused files", filesToDelete.size());
+ }
+ if (log.isDebugEnabled()) {
+log.debug("Cleaning
[jira] [Commented] (LUCENE-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196499#comment-17196499 ] Mike Drob commented on LUCENE-9488: --- Thanks for the pointers, I'll address them in the next set of patches I put up for this. The release process was also consuming that file, which is why I thought I needed to put it back, but I'll figure out how we can consume the other files instead. Will tag all of you on the next review, this issue is by no means complete. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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] arafalov commented on a change in pull request #1869: SOLR-14866 autowidth tables in ref guide
arafalov commented on a change in pull request #1869:
URL: https://github.com/apache/lucene-solr/pull/1869#discussion_r488846561
##
File path: solr/solr-ref-guide/src/other-parsers.adoc
##
@@ -237,7 +237,7 @@ Comma separated list of tags for excluding queries from
parameters above. See ex
{!bool filter=foo should=bar}
-Parameters might also be multivalue references. The former example above is
equivlent to
Review comment:
This and next empty space seems not needed. But 'equivlent' spelling
could be fixed.
##
File path: solr/solr-ref-guide/src/performance-statistics-reference.adoc
##
@@ -191,9 +187,7 @@ You can get the statistics shown in the table below with an
API request such as
The following statistics are available for each of the caches mentioned above:
-// TODO: Change column width to %autowidth.spread when
https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed
-
-[cols="25,75",options="header"]
+[%autowidth.spread,width="100%",options="header"]
Review comment:
This one gets parameter wrapped-up in weird way. I wish there was a way
to mark column no-wrap specifically for this one. But it is ok otherwise.
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-14151) Make schema components load from packages
[
https://issues.apache.org/jira/browse/SOLR-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196426#comment-17196426
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-14151:
--
Thanks Noble, I appreciate you keep looking into this. I'm a bit worried with
this change. Looking through the Jenkins failures, I can see lots of failures
that seem to have started after these commits:
• FAILED: org.apache.solr.pkg.TestPackages.classMethod
• FAILED:
org.apache.solr.schema.PreAnalyzedFieldManagedSchemaCloudTest.testAdd2Fields
• FAILED:
org.apache.solr.schema.ManagedSchemaRoundRobinCloudTest.testAddFieldsRoundRobin
Maybe you should consider reverting until this gets more stable?
> Make schema components load from packages
> -
>
> Key: SOLR-14151
> URL: https://issues.apache.org/jira/browse/SOLR-14151
> Project: Solr
> Issue Type: Sub-task
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Labels: packagemanager
> Fix For: 8.7
>
> Time Spent: 12h 40m
> Remaining Estimate: 0h
>
> Example:
> {code:xml}
>
>
>
>generateNumberParts="0" catenateWords="0"
> catenateNumbers="0" catenateAll="0"/>
>
>
>
>
> {code}
> * When a package is updated, the entire {{IndexSchema}} object is refreshed,
> but the SolrCore object is not reloaded
> * Any component can be prefixed with the package name
> * The semantics of loading plugins remain the same as that of the components
> in {{solrconfig.xml}}
> * Plugins can be registered using schema API
--
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-9528) Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj
Dawid Weiss created LUCENE-9528: --- Summary: Clean up obsolete and commented-out cruft from StandardSyntaxParser.jj Key: LUCENE-9528 URL: https://issues.apache.org/jira/browse/LUCENE-9528 Project: Lucene - Core Issue Type: Sub-task Reporter: Dawid Weiss The indentation in that file is crazy. So are micro-optimizations which make reading the syntax parser much more difficult than it actually is. -- 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-9527) Upgrade javacc and regeneration tasks
Dawid Weiss created LUCENE-9527: --- Summary: Upgrade javacc and regeneration tasks Key: LUCENE-9527 URL: https://issues.apache.org/jira/browse/LUCENE-9527 Project: Lucene - Core Issue Type: Sub-task Reporter: Dawid Weiss -- 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-9526) Update javacc to the latest version
Dawid Weiss created LUCENE-9526: --- Summary: Update javacc to the latest version Key: LUCENE-9526 URL: https://issues.apache.org/jira/browse/LUCENE-9526 Project: Lucene - Core Issue Type: Task Reporter: Dawid Weiss We use an ancient version of javacc. We should upgrade the dependency, the JDK_VERSION constant in grammar specs (JDK_VERSION="1.5") and perhaps clean up those specs too - they contain things like Vector instances to hold lists, etc. -- 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-14503) Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
[
https://issues.apache.org/jira/browse/SOLR-14503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196404#comment-17196404
]
Munendra S N commented on SOLR-14503:
-
[~cjcowie]
Thanks for the patch. I tried in my local without the fix the test fails.
{code:java}
SolrZkClient(String zkServerAddress, int zkClientTimeout, int
zkClientConnectTimeout)
{code}
here, 2nd arg is Zk session timeout which can be configured by property
{{zkClientTimeout}}(name should probably improved so that it conveys actual
usage) and when not passed it is read from solr.xml.
In the current changes, we are still not using session timeout but I think that
should be okay for this particular usecase as we are immediately closing the
client. While scanning through the codebase, there might be other cases where
similar waitForZk might not be used. Would you be interested in fixing those
cases too?
I agree that, the current patch correctly fixes the SOLR-5129
> Solr does not respect waitForZk (SOLR_WAIT_FOR_ZK) property
> ---
>
> Key: SOLR-14503
> URL: https://issues.apache.org/jira/browse/SOLR-14503
> Project: Solr
> Issue Type: Bug
>Affects Versions: 7.1, 7.2, 7.2.1, 7.3, 7.3.1, 7.4, 7.5, 7.6, 7.7, 7.7.1,
> 7.7.2, 8.0, 8.1, 8.2, 7.7.3, 8.1.1, 8.3, 8.4, 8.3.1, 8.5, 8.4.1, 8.5.1
>Reporter: Colvin Cowie
>Priority: Minor
> Attachments: SOLR-14503.patch, SOLR-14503.patch
>
>
> When starting Solr in cloud mode, if zookeeper is not available within 30
> seconds, then core container intialization fails and the node will not
> recover when zookeeper is available.
>
> I believe SOLR-5129 should have addressed this issue, however it doesn't
> quite do so for two reasons:
> #
> [https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L297]
> it calls {{SolrZkClient(String zkServerAddress, int zkClientTimeout)}}
> rather than {{SolrZkClient(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout)}} so the DEFAULT_CLIENT_CONNECT_TIMEOUT of 30 seconds
> is used even when you specify a different waitForZk value
> # bin/solr contains script to set -DwaitForZk from the SOLR_WAIT_FOR_ZK
> environment property
> [https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L2148] but
> there is no corresponding assignment in bin/solr.cmd, while SOLR_WAIT_FOR_ZK
> appears in the solr.in.cmd as an example.
>
> I will attach a patch that fixes the above.
--
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] (LUCENE-9506) Gradle: split validateSourcePatterns into per-project and root-specific tasks (allow parallelism)
[ https://issues.apache.org/jira/browse/LUCENE-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9506. - Fix Version/s: master (9.0) Resolution: Fixed > Gradle: split validateSourcePatterns into per-project and root-specific tasks > (allow parallelism) > - > > Key: LUCENE-9506 > URL: https://issues.apache.org/jira/browse/LUCENE-9506 > Project: Lucene - Core > Issue Type: Task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > Fix For: master (9.0) > > Time Spent: 9h > 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] cpoerschke commented on a change in pull request #1825: SOLR-14828: reduce 'error' logging noise in BaseCloudSolrClient.requestWithRetryOnStaleState
cpoerschke commented on a change in pull request #1825:
URL: https://github.com/apache/lucene-solr/pull/1825#discussion_r488821736
##
File path:
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseCloudSolrClient.java
##
@@ -994,12 +991,15 @@ public RouteException(ErrorCode errorCode,
NamedList throwables, Map<
// and we could not get any information from the server
//it is probably not worth trying again and again because
// the state would not have been updated
- log.info("trying request again");
+ log.info("Request to collection {} failed due to ({}) {}, retry={}
maxRetries={} commError={} errorCode={} - retrying",
+ inputCollections, errorCode, rootCause, retryCount,
MAX_STALE_RETRIES, wasCommError, errorCode);
return requestWithRetryOnStaleState(request, retryCount + 1,
inputCollections);
}
} else {
log.info("request was not communication error it seems");
}
+ log.error("Request to collection {} failed due to ({}) {}, retry={}
maxRetries={} commError={} errorCode={} ",
Review comment:
```suggestion
log.info("Request to collection {} failed due to ({}) {}, retry={}
maxRetries={} commError={} errorCode={} ",
```
@noblepaul - is this what you had in mind when you wrote "switch this to
INFO" on the https://issues.apache.org/jira/browse/SOLR-14828 ticket? Or would
you prefer keeping the logging at line 973 only but as `INFO` instead of
`ERROR`?
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-14859) [* TO *] queries on DateRange fields miss results
[
https://issues.apache.org/jira/browse/SOLR-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196292#comment-17196292
]
Munendra S N commented on SOLR-14859:
-
{quote}the "defaults" in DateRangeField should be changed to be based on the
static FIELD_TYPE you pointed out (for both omitNorms and
omitTermFreqAndPositions)
DateRangeField.init() and DateRangeField.checkSchemaField() should log a
warning if someone tries to configure a fieldType or field that violates these
defaults{quote}
+1
{quote}I'm not sure what "response" you're talking about?{quote}
I was thinking about the response returned by add-field operation(If I'm not
wrong, omitNorm could be overridden for particular field) of the Schema API. If
there is no info about the *omitNorms being ignored for DateRangeField* is
specified in the response of add-field then, user might assume the operation
succeeded. So, I was thinking is failing a better option but I agree, it would
be too strong and log warning would be sufficient
> [* TO *] queries on DateRange fields miss results
> -
>
> Key: SOLR-14859
> URL: https://issues.apache.org/jira/browse/SOLR-14859
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.5
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-14859.patch, query-debug.png, reproduce.sh,
> schema.png
>
>
> "exists" queries ({{[* TO *]}}) on DateRange fields return 0 results
> regardless of docs in the index with values in that field.
> The issue appears to be that the query is converted into a
> {{NormsFieldExistsQuery}}, even though DateRangeField uses omitNorms=true by
> default. Probably introduced by SOLR-11746's changes to these optimizable
> range queries.
> I've attached a script to reproduce the issue (tested on Solr 8.6.2) and
> screenshots showing showing schema and query-parsing info for the
> reproduction.
--
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-14865) clarify index merge metrics configuration documentation
[
https://issues.apache.org/jira/browse/SOLR-14865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196285#comment-17196285
]
Christine Poerschke commented on SOLR-14865:
{quote}... the {{indexConfig}} section can be inspected but when doing so the
{{metrics}} content does not appear to be correctly reflected ...
{quote}
I've been looking into this some more today and it appears that the
{{16}} is actually not being correctly read
i.e. the {{// :NOTE: Unexpected Node names are ignored}} scenario at
[https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/core/src/java/org/apache/solr/util/DOMUtil.java#L179]
applies and {{16}} is the required usage
(though {{16}} would also work).
Have added an additional edit to the
[https://github.com/apache/lucene-solr/pull/1870] pull request.
[~ab], would you have a chance perhaps to double-check my analysis here? Thanks!
> clarify index merge metrics configuration documentation
> ---
>
> Key: SOLR-14865
> URL: https://issues.apache.org/jira/browse/SOLR-14865
> Project: Solr
> Issue Type: Task
> Components: metrics
>Reporter: Christine Poerschke
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The documentation – e.g.
> [https://lucene.apache.org/solr/guide/8_6/metrics-reporting.html#index-merge-metrics]
> – currently mentions that _"Basic metrics are always collected"_ but
> experimentally and from a quick look at the code – e.g.
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.2/solr/core/src/java/org/apache/solr/update/SolrIndexWriter.java#L146]
> – it appears that a {{metrics}} element needs to be configured and that it
> needs to have either a {{merge}} or a {{mergeDetails}} element configured as
> true.
--
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-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196241#comment-17196241
]
Shashank Shekhar edited comment on SOLR-14723 at 9/15/20, 4:26 PM:
---
Cool, so I will remove the class attribute from the caches mentioned above by
you. Then run the tests and proceed with debugging if the tests still fail on
my modified branch. Thank-you for the debugging tips. I think these will
definitely help.
After a closer look on all the files to be edited I think editing the _xml_s
via a python script makes more sense than manually editing them. There are
close to 45 files to be edited. The script can parse the xml, remove the class
attribute from the cache tags and write it back.
was (Author: shshnk28):
Cool, so I will remove the class attribute from the caches mentioned above by
you. Then run the tests and proceed with debugging if the tests still fail on
my modified branch. Thank-you for the debugging tips. I think these will
definitely help.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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] PuneethBikkumanla edited a comment on pull request #1858: LUCENE-6744: equals methods should compare classes directly, not use instanceof
PuneethBikkumanla edited a comment on pull request #1858: URL: https://github.com/apache/lucene-solr/pull/1858#issuecomment-692813025 > Are there any tests that can be added to show how instanceOf fails or inferior? I will add tests testing this. I actually traced through the code currently testing these classes, but there didn't seem to be any tests testing them individually. I'll look into how I can add tests into the existing framework or add new tests. 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] PuneethBikkumanla commented on pull request #1858: LUCENE-6744: equals methods should compare classes directly, not use instanceof
PuneethBikkumanla commented on pull request #1858: URL: https://github.com/apache/lucene-solr/pull/1858#issuecomment-692813025 > Are there any tests that can be added to show how instanceOf fails or inferior? I will look to add tests. I actually traced through the code currently testing these classes, but there didn't seem to be any tests testing them individually. I'll look into how I can add tests into the existing framework or add new test classes to test this behavior. 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-14859) [* TO *] queries on DateRange fields miss results
[
https://issues.apache.org/jira/browse/SOLR-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196263#comment-17196263
]
Chris M. Hostetter commented on SOLR-14859:
---
{quote}Warning in response saying this is not allowed and ignored or log
warning? ...
{quote}
I'm not sure what "response" you're talking about?
My understand (based on your diagnoses) is that the "root" of the problem has
noething to do with the request time query parsing: it's that
{{DateRangeField}} can be configured with -- and defaults to
{{omitNorms="false"}} even though the underlying (lucene) FieldType _always_
uses {{FIELD_TYPE.setOmitNorms(true);}}
What i'm saying is that:
* the "defaults" in {{DateRangeField}} should be changed to be based on the
static {{FIELD_TYPE}} you pointed out (for both {{omitNorms}} and
{{omitTermFreqAndPositions}})
* {{DateRangeField.init()}} and {{DateRangeField.init()}} should log a warning
if someone tries to configure a fieldType or field that violates these defaults
(And obviously the docs for {{DateRangeField}} should be updated as well)
> [* TO *] queries on DateRange fields miss results
> -
>
> Key: SOLR-14859
> URL: https://issues.apache.org/jira/browse/SOLR-14859
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.5
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-14859.patch, query-debug.png, reproduce.sh,
> schema.png
>
>
> "exists" queries ({{[* TO *]}}) on DateRange fields return 0 results
> regardless of docs in the index with values in that field.
> The issue appears to be that the query is converted into a
> {{NormsFieldExistsQuery}}, even though DateRangeField uses omitNorms=true by
> default. Probably introduced by SOLR-11746's changes to these optimizable
> range queries.
> I've attached a script to reproduce the issue (tested on Solr 8.6.2) and
> screenshots showing showing schema and query-parsing info for the
> reproduction.
--
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-14859) [* TO *] queries on DateRange fields miss results
[
https://issues.apache.org/jira/browse/SOLR-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196263#comment-17196263
]
Chris M. Hostetter edited comment on SOLR-14859 at 9/15/20, 3:56 PM:
-
{quote}Warning in response saying this is not allowed and ignored or log
warning? ...
{quote}
I'm not sure what "response" you're talking about?
My understand (based on your diagnoses) is that the "root" of the problem has
noething to do with the request time query parsing: it's that
{{DateRangeField}} can be configured with -- and defaults to
{{omitNorms="false"}} even though the underlying (lucene) FieldType _always_
uses {{FIELD_TYPE.setOmitNorms(true);}}
What i'm saying is that:
* the "defaults" in {{DateRangeField}} should be changed to be based on the
static {{FIELD_TYPE}} you pointed out (for both {{omitNorms}} and
{{omitTermFreqAndPositions}})
* {{DateRangeField.init()}} and {{DateRangeField.checkSchemaField()}} should
log a warning if someone tries to configure a fieldType or field that violates
these defaults
(And obviously the docs for {{DateRangeField}} should be updated as well)
was (Author: hossman):
{quote}Warning in response saying this is not allowed and ignored or log
warning? ...
{quote}
I'm not sure what "response" you're talking about?
My understand (based on your diagnoses) is that the "root" of the problem has
noething to do with the request time query parsing: it's that
{{DateRangeField}} can be configured with -- and defaults to
{{omitNorms="false"}} even though the underlying (lucene) FieldType _always_
uses {{FIELD_TYPE.setOmitNorms(true);}}
What i'm saying is that:
* the "defaults" in {{DateRangeField}} should be changed to be based on the
static {{FIELD_TYPE}} you pointed out (for both {{omitNorms}} and
{{omitTermFreqAndPositions}})
* {{DateRangeField.init()}} and {{DateRangeField.init()}} should log a warning
if someone tries to configure a fieldType or field that violates these defaults
(And obviously the docs for {{DateRangeField}} should be updated as well)
> [* TO *] queries on DateRange fields miss results
> -
>
> Key: SOLR-14859
> URL: https://issues.apache.org/jira/browse/SOLR-14859
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.5
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-14859.patch, query-debug.png, reproduce.sh,
> schema.png
>
>
> "exists" queries ({{[* TO *]}}) on DateRange fields return 0 results
> regardless of docs in the index with values in that field.
> The issue appears to be that the query is converted into a
> {{NormsFieldExistsQuery}}, even though DateRangeField uses omitNorms=true by
> default. Probably introduced by SOLR-11746's changes to these optimizable
> range queries.
> I've attached a script to reproduce the issue (tested on Solr 8.6.2) and
> screenshots showing showing schema and query-parsing info for the
> reproduction.
--
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] (LUCENE-9488) Update release process to work with Gradle.
[
https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196257#comment-17196257
]
Uwe Schindler edited comment on LUCENE-9488 at 9/15/20, 3:48 PM:
-
The release script also uses the wrong command line parameter to set release
version (multiple places in script):
bq. This must be {{-Dversion.release=%s}}, as gradle has some reserved meaning
of {{version}}.
I added this a review comment.
was (Author: thetaphi):
The release script also used the wrong command line version to set realease
version:
bq. This must be {{-Dversion.release=%s}}, as gradle has some reserved meaning
of {{version}}.
I added this a review comment.
> Update release process to work with Gradle.
> ---
>
> Key: LUCENE-9488
> URL: https://issues.apache.org/jira/browse/LUCENE-9488
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Reporter: Erick Erickson
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> The release process needs to reflect using Gradle rather than Ant. I suspect
> this will be a significant task, thus it has its own JIRA
--
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-9488) Update release process to work with Gradle.
[
https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196257#comment-17196257
]
Uwe Schindler commented on LUCENE-9488:
---
The release script also used the wrong command line version to set realease
version:
bq. This must be {{-Dversion.release=%s}}, as gradle has some reserved meaning
of {{version}}.
I added this a review comment.
> Update release process to work with Gradle.
> ---
>
> Key: LUCENE-9488
> URL: https://issues.apache.org/jira/browse/LUCENE-9488
> Project: Lucene - Core
> Issue Type: Improvement
> Components: general/build
>Reporter: Erick Erickson
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> The release process needs to reflect using Gradle rather than Ant. I suspect
> this will be a significant task, thus it has its own JIRA
--
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] uschindler commented on a change in pull request #1860: LUCENE-9488 Update release process to work with gradle
uschindler commented on a change in pull request #1860:
URL: https://github.com/apache/lucene-solr/pull/1860#discussion_r488771433
##
File path: dev-tools/scripts/buildAndPushRelease.py
##
@@ -108,37 +107,26 @@ def prepare(root, version, gpgKeyID, gpgPassword):
print(' Check DOAP files')
checkDOAPfiles(version)
- print(' ant -Dtests.badapples=false clean validate documentation-lint test')
- run('ant -Dtests.badapples=false clean validate documentation-lint test')
+ print(' ./gradlew -Dtests.badapples=false clean check')
+ run('./gradlew -Dtests.badapples=false clean check')
open('rev.txt', mode='wb').write(rev.encode('UTF-8'))
- print(' lucene prepare-release')
- os.chdir('lucene')
- cmd = 'ant -Dversion=%s' % version
+ print(' prepare-release')
+ cmd = './gradlew -Dversion=%s clean' % version
Review comment:
This must be `-Dversion.release=%s`, as gradle has some reserved meaning
of `version`.
##
File path: dev-tools/scripts/releaseWizard.yaml
##
@@ -1059,7 +1056,7 @@ groups:
logfile: checkout-release-tag.log
tee: true
- !Command
-cmd: ant documentation -Dversion={{ release_version }}
+cmd: "{{ gradle_cmd }} documentation -Dversion={{ release_version }}"
Review comment:
This must be `-Dversion.release=%s`, as gradle has some reserved meaning
of `version`.
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] (LUCENE-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196254#comment-17196254 ] Dawid Weiss commented on LUCENE-9488: - Thanks for having this under control, Uwe. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 3h 10m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196249#comment-17196249 ] Uwe Schindler commented on LUCENE-9488: --- bq. If such a file is needed, it should be generated (from within gradle) so that it's up-to-date. It's the other way round: Ant consumed that file and the release process was updating the release version in it when creating new branches and so on. Modifying or creating it is completely useless, as the file is ignored and not read at all. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 3h 10m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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-9474) Change Jenkins jobs to use Gradle for trunk
[ https://issues.apache.org/jira/browse/LUCENE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196246#comment-17196246 ] ASF subversion and git services commented on LUCENE-9474: - Commit 2806475ea99963ceeaff2de05c6648e72a09e1ae in lucene-solr's branch refs/heads/reference_impl_dev from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2806475 ] LUCENE-9474: Remove bad warning (we sometimes have non-existing directories in classpaths during compile). This warnings is not source-code related so shouldn't be enforced (Java 14) > Change Jenkins jobs to use Gradle for trunk > --- > > Key: LUCENE-9474 > URL: https://issues.apache.org/jira/browse/LUCENE-9474 > Project: Lucene - Core > Issue Type: Test > Components: general/build >Reporter: Erick Erickson >Assignee: Uwe Schindler >Priority: Major > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png, screenshot-5.png, screenshot-6.png > > > I rushed the gate and pushed LUCENE-9433 without coordinating, my apologies > for the confusion. > Meanwhile, Uwe has disabled Jenkins jobs for the weekend and we'll fix this > up Real Soon Now. -- 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-14854) Add root project name "lucene-solr" (avoid automatic root project naming)
[
https://issues.apache.org/jira/browse/SOLR-14854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196247#comment-17196247
]
ASF subversion and git services commented on SOLR-14854:
Commit ccabb7a0ea78a559c94e1ca7861bd49a60bb17af in lucene-solr's branch
refs/heads/reference_impl_dev from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ccabb7a ]
SOLR-14854: Add root project name lucene-solr (avoid automatic root project
naming)
> Add root project name "lucene-solr" (avoid automatic root project naming)
> -
>
> Key: SOLR-14854
> URL: https://issues.apache.org/jira/browse/SOLR-14854
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andras Salamon
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-14854.patch
>
>
> Gradle does not work if repository cloned into solr directory.
> {noformat}$ git clone https://github.com/apache/lucene-solr.git solr
> $ cd solr
> $ ./gradlew tasks
> FAILURE: Build failed with an exception.
> * What went wrong:
> A problem occurred configuring root project 'solr'.
> > A problem occurred configuring project ':solr'.
>> This plugin doesn't work if the root project shares both group and name
> with a subproject. Consider adding the following to settings.gradle:
> rootProject.name = 'solr-root'{noformat}
--
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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196248#comment-17196248 ] ASF subversion and git services commented on SOLR-14789: Commit c04ee3b87d684a75f920de3a1a4557d39b327ab0 in lucene-solr's branch refs/heads/reference_impl_dev from Houston Putman [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c04ee3b ] SOLR-14789: Rename docker tests task, adding missing credit in CHANGES (#1871) > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the [dev mailing > list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] > and SOLR-11245. -- 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-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196245#comment-17196245 ] Uwe Schindler commented on LUCENE-9488: --- Hi I added a review comment in this PR. You should have asked the Gradle maintainers for review :-) > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 3h 10m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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] uschindler commented on a change in pull request #1860: LUCENE-9488 Update release process to work with gradle
uschindler commented on a change in pull request #1860: URL: https://github.com/apache/lucene-solr/pull/1860#discussion_r488766685 ## File path: lucene/version.properties ## @@ -0,0 +1,10 @@ +# This file contains some version properties as used by various build files. Review comment: Please remove that file, it wont be used. If release scripts need to edit the version number after a release, /build.gradle is your friend. Theres also a version.base and that's the source of information. https://github.com/apache/lucene-solr/blob/master/build.gradle#L38 There is a reason why this file was removed, so dont restore 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-14723) Rremove the class atribute for the caches in the _default/example configsets
[
https://issues.apache.org/jira/browse/SOLR-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196241#comment-17196241
]
Shashank Shekhar commented on SOLR-14723:
-
Cool, so I will remove the class attribute from the caches mentioned above by
you. Then run the tests and proceed with debugging if the tests still fail on
my modified branch. Thank-you for the debugging tips. I think these will
definitely help.
> Rremove the class atribute for the caches in the _default/example configsets
>
>
> Key: SOLR-14723
> URL: https://issues.apache.org/jira/browse/SOLR-14723
> Project: Solr
> Issue Type: Improvement
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
> Labels: newdev
>
> In 8.x branch, the default and example configsets include LRUCache and
> FastLRUCache as the implementation for the various caches.
> {code:xml}
> size="512"
> initialSize="512"
> autowarmCount="0"/>
> {code}
> Those implementations are deprecated. We should remove the attribute
> completely and let the default take over (as it's in master), this should
> make upgrading configsets easier:
--
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] uschindler commented on a change in pull request #1860: LUCENE-9488 Update release process to work with gradle
uschindler commented on a change in pull request #1860: URL: https://github.com/apache/lucene-solr/pull/1860#discussion_r488766685 ## File path: lucene/version.properties ## @@ -0,0 +1,10 @@ +# This file contains some version properties as used by various build files. Review comment: Ülease remove that file, it wont be used. If release scripts need to edit the version number after a release, /build.gradle is your friend. Theres also a version.base and that's the source of information. https://github.com/apache/lucene-solr/blob/master/build.gradle#L38 There is a reason why this file was removed, so dont restore 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] (LUCENE-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196235#comment-17196235 ] Uwe Schindler commented on LUCENE-9488: --- No please don't addlucene/version.properties. This file was just there for ant, so the release manager can easily change the version after release. For Gradle, the only file you need to edit is root's build.gradle. The version number (main version) has to be inserted there. The same comment as in version.properties is also there, so the regex after release must just be updated slightly. So please revert and remove the file again, as it will run out of date. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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] (LUCENE-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196235#comment-17196235 ] Uwe Schindler edited comment on LUCENE-9488 at 9/15/20, 3:34 PM: - No please don't add lucene/version.properties. This file was just there for ant, so the release manager can easily change the version after release. For Gradle, the only file you need to edit is root's build.gradle. The version number (main version) has to be inserted there. The same comment as in version.properties is also there, so the regex after release must just be updated slightly. So please revert and remove the file again, as it will run out of date. was (Author: thetaphi): No please don't addlucene/version.properties. This file was just there for ant, so the release manager can easily change the version after release. For Gradle, the only file you need to edit is root's build.gradle. The version number (main version) has to be inserted there. The same comment as in version.properties is also there, so the regex after release must just be updated slightly. So please revert and remove the file again, as it will run out of date. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196229#comment-17196229 ] Dawid Weiss commented on LUCENE-9488: - I don't think lucene/version.properties should be restored. This duplicates information. If such a file is needed, it should be generated (from within gradle) so that it's up-to-date. > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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] madrob merged pull request #1860: LUCENE-9488 Update release process to work with gradle
madrob merged pull request #1860: URL: https://github.com/apache/lucene-solr/pull/1860 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] (LUCENE-9488) Update release process to work with Gradle.
[ https://issues.apache.org/jira/browse/LUCENE-9488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196219#comment-17196219 ] ASF subversion and git services commented on LUCENE-9488: - Commit 3134f10a4255b5d766462251868a43e9bb9c03ce in lucene-solr's branch refs/heads/master from Mike Drob [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3134f10 ] LUCENE-9488 Update release process to work with gradle (#1860) * Restore lucene/version.properties * Switch release wizard commands from ant to gradle equivalents * Remove remaining checks for ant * Remove checks for Java 8 * Update Copyright year * Minor bug fixes around determining next version for a major release > Update release process to work with Gradle. > --- > > Key: LUCENE-9488 > URL: https://issues.apache.org/jira/browse/LUCENE-9488 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Mike Drob >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > The release process needs to reflect using Gradle rather than Ant. I suspect > this will be a significant task, thus it has its own JIRA -- 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-14866) Ref Guide: make table widths automatic
[ https://issues.apache.org/jira/browse/SOLR-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Eric Pugh updated SOLR-14866: --- Summary: Ref Guide: make table widths automatic (was: Ref Guide no longer is published in PDF so doesn't need workaround) > Ref Guide: make table widths automatic > -- > > Key: SOLR-14866 > URL: https://issues.apache.org/jira/browse/SOLR-14866 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Trivial > Fix For: 8.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Ref Guide has around 22 TODO's to change table formatting with a bug in the > asciidoctor-pdf library is fixed: > TODO: Change column width to %autowidth.spread when > https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed > That bug is fixed, however this may be OBE since we no longer publish a PDF > version anyway. -- 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-14866) Ref Guide: make table widths automatic
[ https://issues.apache.org/jira/browse/SOLR-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196206#comment-17196206 ] David Eric Pugh commented on SOLR-14866: Much better issue title! > Ref Guide: make table widths automatic > -- > > Key: SOLR-14866 > URL: https://issues.apache.org/jira/browse/SOLR-14866 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Trivial > Fix For: 8.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Ref Guide has around 22 TODO's to change table formatting with a bug in the > asciidoctor-pdf library is fixed: > TODO: Change column width to %autowidth.spread when > https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed > That bug is fixed, however this may be OBE since we no longer publish a PDF > version anyway. -- 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-14859) [* TO *] queries on DateRange fields miss results
[
https://issues.apache.org/jira/browse/SOLR-14859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196205#comment-17196205
]
Munendra S N commented on SOLR-14859:
-
bq. "fail" is probably too strong ... we can probably just WARN if users try to
set a field/fieldType property that we know is (and has always been) ignored.
Warning in response saying this is not allowed and ignored or log warning? If
we are going with warning, I think it would be better to document this behavior
somewhere. Also, we might need to check if there are any other such fieldTypes
but it can be handled in different issue
> [* TO *] queries on DateRange fields miss results
> -
>
> Key: SOLR-14859
> URL: https://issues.apache.org/jira/browse/SOLR-14859
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
>Affects Versions: 8.5
>Reporter: Jason Gerlowski
>Priority: Major
> Attachments: SOLR-14859.patch, query-debug.png, reproduce.sh,
> schema.png
>
>
> "exists" queries ({{[* TO *]}}) on DateRange fields return 0 results
> regardless of docs in the index with values in that field.
> The issue appears to be that the query is converted into a
> {{NormsFieldExistsQuery}}, even though DateRangeField uses omitNorms=true by
> default. Probably introduced by SOLR-11746's changes to these optimizable
> range queries.
> I've attached a script to reproduce the issue (tested on Solr 8.6.2) and
> screenshots showing showing schema and query-parsing info for the
> reproduction.
--
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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14789: -- Description: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the [dev mailing list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] and SOLR-11245. was: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the [dev mailing > list|https://mail-archives.apache.org/mod_mbox/lucene-dev/202002.mbox/%3CCAD4GwrOSJX9x29S4a7e5g2j%3D9wsuMhYxFmNkrwrRHfnv0tPFOg%40mail.gmail.com%3E] > and SOLR-11245. -- 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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[ https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman updated SOLR-14789: -- Description: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. Discussion around this feature has taken place on the was: Migrate the docker image building and testing from the [https://github.com/docker-solr/docker-solr] repo into Solr. This is only applicable for 9.0+. Backporting Docker functionality to Solr 8x will be handled separately. This is meant to be a first pass migration and not solve all issues. The goal is: * Docker images be built in a flexible way that will allow for release and local builds to share the same business logic * Building and testing should be integrated with the gradle build * Maintain current usage documentation in their current form, but documentation on building images should go in the ref-guide. The usage documentation will be migrated separately. > Absorb and maintain docker-solr functionality for Solr 9.0+ > --- > > Key: SOLR-14789 > URL: https://issues.apache.org/jira/browse/SOLR-14789 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Docker >Affects Versions: master (9.0) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Blocker > Fix For: master (9.0) > > Time Spent: 4h 50m > Remaining Estimate: 0h > > Migrate the docker image building and testing from the > [https://github.com/docker-solr/docker-solr] repo into Solr. This is only > applicable for 9.0+. Backporting Docker functionality to Solr 8x will be > handled separately. > > This is meant to be a first pass migration and not solve all issues. The goal > is: > * Docker images be built in a flexible way that will allow for release and > local builds to share the same business logic > * Building and testing should be integrated with the gradle build > * Maintain current usage documentation in their current form, but > documentation on building images should go in the ref-guide. The usage > documentation will be migrated separately. > Discussion around this feature has taken place on the -- 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-14789) Absorb and maintain docker-solr functionality for Solr 9.0+
[
https://issues.apache.org/jira/browse/SOLR-14789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196202#comment-17196202
]
Houston Putman commented on SOLR-14789:
---
{quote}victim of poor JIRA management
{quote}
That's fair. I was trying to clean up the JIRA and break it up into logical
tasks, but I can see how that obfuscated the discussion. I'll update the ticket
to include links to relevant discussions.
{quote}Do we agree that we should use Alpine? Do we agree that we should
support something like "pre-create" collections? Have we done a security audit
of the merged code and are we sure that the containers are production ready and
secure? These are questions I'd have appreciated if we discussed before diving
straight into a code merge.
{quote}
So I think that these questions are much more easily addressed now. The
consensus from the various discussions on the topic was that the code should be
migrated to lucene-solr. Now that the (peer-reviewed) code lives in
lucene-solr, all of these implementation questions are relatively independent,
and can be addressed without blocking each other. If you look at the parent
issue, SOLR-14168, there are many tasks that are on the roadmap. The work on
these items can be done in manageable chunks. That PR was never meant to be a
"final product". This was to get us started so that we can more easily improve
it for the 9.0 release.
There are really good ideas around reducing the footprint of
{{/solr/docker/include/scripts}} (formerly {{docker-solr/scripts}}), but
working on and testing these ideas will be much easier having all of the code
in one place. For example, you can take functionality from docker/scripts and
add it to solr/bin, or solr itself, and have a one step build and test.
I think a security audit would be great, but wouldn't that also be necessary
when bringing it in as a separate repo? I honestly think that would be a very
valuable thing to add as a gradle task in this module. Can you create a Jira
under the parent ticket to get a security audit created? I'm by no means a
security expert, so while I'm happy to help with the work I should probably not
be defining the problem.
Side note, we don't use alpine for anything. Mike brought up this concern in
the PR and it was replaced with {{scratch}}.
{quote}non-essential to Solr's core
{quote}
I don't necessarily agree with this. It is clear that much of the world is
moving to containerized/serverless deployments. Using Solr in a container
should be a fully supported paradigm, just as we support unix and windows
systems through {{solr/bin}}. Also having the image as a part of the official
project will help us move Solr in the direction of being more docker
friendly/cloud native.
As for the increase in PRs/JIRA issues. I would hope that a lot of the
questions move to the mailing lists, which I have seen used already. There are
less than 15 PRs from docker-solr over the last year that are actually relevant
to it's current form in {{lucene-solr}}, so I don't think it's going to be a
large burden to deal with. If there are a large number of PRs, then that's even
better. We'll have an even greater docker image for the future!
> Absorb and maintain docker-solr functionality for Solr 9.0+
> ---
>
> Key: SOLR-14789
> URL: https://issues.apache.org/jira/browse/SOLR-14789
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Docker
>Affects Versions: master (9.0)
>Reporter: Houston Putman
>Assignee: Houston Putman
>Priority: Blocker
> Fix For: master (9.0)
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Migrate the docker image building and testing from the
> [https://github.com/docker-solr/docker-solr] repo into Solr. This is only
> applicable for 9.0+. Backporting Docker functionality to Solr 8x will be
> handled separately.
>
> This is meant to be a first pass migration and not solve all issues. The goal
> is:
> * Docker images be built in a flexible way that will allow for release and
> local builds to share the same business logic
> * Building and testing should be integrated with the gradle build
> * Maintain current usage documentation in their current form, but
> documentation on building images should go in the ref-guide. The usage
> documentation will be migrated separately.
--
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] janhoy commented on pull request #1860: LUCENE-9488 Update release process to work with gradle
janhoy commented on pull request #1860: URL: https://github.com/apache/lucene-solr/pull/1860#issuecomment-692761861 Sure, all progress is good progress 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-14866) Ref Guide no longer is published in PDF so doesn't need workaround
[ https://issues.apache.org/jira/browse/SOLR-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196194#comment-17196194 ] Cassandra Targett commented on SOLR-14866: -- I feel like the title of this could be more descriptive of the actual change? Like "Ref Guide: make table widths automatic"? The fact that it wasn't and it's no longer published in PDF is really only relevant for historic context in the description, and if for some reason I personally want to find this issue in the future, I'm not going to recognize it from the current title. > Ref Guide no longer is published in PDF so doesn't need workaround > -- > > Key: SOLR-14866 > URL: https://issues.apache.org/jira/browse/SOLR-14866 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Trivial > Fix For: 8.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Ref Guide has around 22 TODO's to change table formatting with a bug in the > asciidoctor-pdf library is fixed: > TODO: Change column width to %autowidth.spread when > https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed > That bug is fixed, however this may be OBE since we no longer publish a PDF > version anyway. -- 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-14866) Ref Guide no longer is published in PDF so doesn't need workaround
[ https://issues.apache.org/jira/browse/SOLR-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196194#comment-17196194 ] Cassandra Targett edited comment on SOLR-14866 at 9/15/20, 2:34 PM: I feel like the title of this could be more descriptive of the actual change? Like "Ref Guide: make table widths automatic"? The fact that they weren't because of the PDF and it's no longer published in PDF is really only relevant for historic context in the description, and if for some reason I personally want to find this issue in the future, I'm not going to recognize it from the current title. was (Author: ctargett): I feel like the title of this could be more descriptive of the actual change? Like "Ref Guide: make table widths automatic"? The fact that it wasn't and it's no longer published in PDF is really only relevant for historic context in the description, and if for some reason I personally want to find this issue in the future, I'm not going to recognize it from the current title. > Ref Guide no longer is published in PDF so doesn't need workaround > -- > > Key: SOLR-14866 > URL: https://issues.apache.org/jira/browse/SOLR-14866 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: documentation >Affects Versions: 8.6.2 >Reporter: David Eric Pugh >Assignee: David Eric Pugh >Priority: Trivial > Fix For: 8.7 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Ref Guide has around 22 TODO's to change table formatting with a bug in the > asciidoctor-pdf library is fixed: > TODO: Change column width to %autowidth.spread when > https://github.com/asciidoctor/asciidoctor-pdf/issues/599 is fixed > That bug is fixed, however this may be OBE since we no longer publish a PDF > version anyway. -- 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-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Munendra S N resolved SOLR-10471.
-
Fix Version/s: 8.7
Assignee: Munendra S N (was: Mark Miller)
Resolution: Fixed
Thanks [~markus17]
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Munendra S N
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-10471.patch, SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
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-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196188#comment-17196188
]
ASF subversion and git services commented on SOLR-10471:
Commit ba1b65e39d02314d33b5d5e1f7f490b3b81337cd in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ba1b65e ]
SOLR-10471: update default zk session timeout in bin/solr* scripts
* zkClientTimeout value is already set to 30s in solr.xml but
same update was missing from bin/solr* script
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10471.patch, SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
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-10471) Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
[
https://issues.apache.org/jira/browse/SOLR-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196183#comment-17196183
]
ASF subversion and git services commented on SOLR-10471:
Commit 58d13608b45d5e412fa194d1b1a8a4ef43c0cf6a in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=58d1360 ]
SOLR-10471: update default zk session timeout in bin/solr* scripts
* zkClientTimeout value is already set to 30s in solr.xml but
same update was missing from bin/solr* script
> Solr script always sets zkClientTimeout to 15000 if ZK_CLIENT_TIMEOUT unset
> ---
>
> Key: SOLR-10471
> URL: https://issues.apache.org/jira/browse/SOLR-10471
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.2.1, 7.0
>Reporter: Michael Braun
>Assignee: Mark Miller
>Priority: Minor
> Attachments: SOLR-10471.patch, SOLR-10471.patch
>
>
> Per SOLR-5565, ZooKeeper session timeout should have been raised to 30s. This
> was changed in the solr.xml example but it was not changed in the solr
> script, which has this:
> {code}
> if [ -z "$ZK_CLIENT_TIMEOUT" ]; then
> ZK_CLIENT_TIMEOUT="15000"
> fi
> {code}
> And for solr.cmd:
> {code}
> IF "%ZK_CLIENT_TIMEOUT%"=="" set "ZK_CLIENT_TIMEOUT=15000"
> {code}
> So regardless of what is in solr.xml, if ZK_CLIENT_TIMEOUT is not set, it
> will be overridden to 15,000. I'd think this should be raised to 30,000 or
> removed entirely to fall back on the solr.xml's behavior.
> [~markrmil...@gmail.com] is this correct?
--
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-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196156#comment-17196156 ] Mike Nibeck edited comment on SOLR-14597 at 9/15/20, 2:09 PM: -- Attaching initial patch for discussion and review. was (Author: nibeck): Patch attached to fix Unit Tests. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > Attachments: aqp_patch.patch > > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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] munendrasn commented on pull request #1864: SOLR-14850 ExactStatsCache NullPointerException when shards.tolerant=true
munendrasn commented on pull request #1864: URL: https://github.com/apache/lucene-solr/pull/1864#issuecomment-692740084 @Hronom Thanks for raising the PR against the master. I will look into it. In meantime, could you please a test to demonstrate the problem? 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] jpountz opened a new pull request #1876: LUCENE-9525: Better handle small documents with Lucene87StoredFieldsFormat.
jpountz opened a new pull request #1876: URL: https://github.com/apache/lucene-solr/pull/1876 Instead of configuring a dictionary size and a block size, the format now tries to have 10 sub blocks per bigger block, and adapts the size of the dictionary and of the sub blocks to this overall block size. 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-9525) Better handle small documents with the new Lucene87StoredFieldsFormat
Adrien Grand created LUCENE-9525: Summary: Better handle small documents with the new Lucene87StoredFieldsFormat Key: LUCENE-9525 URL: https://issues.apache.org/jira/browse/LUCENE-9525 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Stored fields configure a maximum number of fields per block, whose goal is to make sure that you don't decompress more than X documents to get access to a single one. However this has interesting effects with the new format. For instance we use 4kB of dictionary and blocks of 60kB for at most 512 documents per block. So if your documents are very small, say 10 bytes, the block will be 5120 bytes overall, and we'll first compress 4096 bytes independently, and then 5120-4096=1024 bytes with 4096 bytes of dictionary. In this case training the dictionary takes more time than actually compressing the data, and it's not even sure it's worth it since only 1024 bytes out of the 5120 bytes of the block get compressed with a preset dictionary. I'm considering adapting the dictionary size and the block size to the total block size in order to better handle such cases. -- 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-10655) refactor duplicate ref guide content into "snippet" files that can be included
[ https://issues.apache.org/jira/browse/SOLR-10655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196164#comment-17196164 ] Cassandra Targett commented on SOLR-10655: -- bq. this ticket could be worked now Sure, it could have been worked on at pretty much any point in the past 3 years after the initial push to move the Ref Guide into the source repo. But that statement sort of underestimates the various decisions, build changes, and content re-organization that would need to go into really realizing the overall vision this issue encapsulated. The TODO was left in those files because we wanted to be sure to document points of departure from what existed in the old Confluence Ref Guide during that conversion - it probably could be removed at this point. Or, since it's hurting no one and nothing, we could just leave it. > refactor duplicate ref guide content into "snippet" files that can be included > -- > > Key: SOLR-10655 > URL: https://issues.apache.org/jira/browse/SOLR-10655 > Project: Solr > Issue Type: Sub-task > Components: documentation >Reporter: Chris M. Hostetter >Priority: Major > > in cwiki, we were using the "excerpt" and "excerpt-include" macros to mirror > some content across multiple pages. > as part of the cwiki->adoc migration, these macros were just evaluated > durring export, and the content is now duplicated. > moving forward, we should refactor this duplicated content into "snippet" > files that can be included in multiple places. A few things we need to be > careful about when doing this: > * ensuring anchors and relative links are generated in such a way that they > are still unique per-section > * that some convention / page attributes are used such that the > BuildNavAndPDFBody code doesn't try to include them as "real" pages (or > errors that they have no parent) -- 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-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17196156#comment-17196156 ] Mike Nibeck commented on SOLR-14597: Patch attached to fix Unit Tests. > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > Attachments: aqp_patch.patch > > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Nibeck updated SOLR-14597: --- Attachment: aqp_patch.patch > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > Attachments: aqp_patch.patch > > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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 #1845: SOLR-14613: Autoscaling replacement using placement plugins
noblepaul commented on a change in pull request #1845:
URL: https://github.com/apache/lucene-solr/pull/1845#discussion_r488658448
##
File path: solr/solrj/src/resources/apispec/cluster.Commands.json
##
@@ -141,6 +141,21 @@
}
}
}
-}
+},
+"set-placement-plugin": {
Review comment:
I'll give patch
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] [Updated] (SOLR-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-14597: Affects Version/s: (was: 8.7) > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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-14597) Advanced Query Parser
[ https://issues.apache.org/jira/browse/SOLR-14597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gus Heck updated SOLR-14597: Affects Version/s: (was: 8.6) 8.7 > Advanced Query Parser > - > > Key: SOLR-14597 > URL: https://issues.apache.org/jira/browse/SOLR-14597 > Project: Solr > Issue Type: New Feature > Components: query parsers >Affects Versions: 8.7 >Reporter: Mike Nibeck >Assignee: Gus Heck >Priority: Major > > This JIRA ticket tracks the progress of SIP-9, the Advanced Query Parser that > is being donated by the Library of Congress. Full description of the feature > can be found on the SIP Page. > [https://cwiki.apache.org/confluence/display/SOLR/SIP-9+Advanced+Query+Parser] > Briefly, this parser provides a comprehensive syntax for users that use > search on a daily basis. It also reserves a smaller set of punctuators than > other parsers. This facilitates easier handling of acronyms and punctuated > patterns with meaning ( such as C++ or 401(k) ). The new syntax opens up some > advanced features while also preventing access to arbitrary features via > local parameters. This parser will be safe for accepting user queries > directly with minimal pre-parsing, but for use cases beyond it's established > features alternate query paths (using other parsers) will need to be supplied. > The code drop is being prepared and will be supplied as soon as we receive > guidance from the PMC regarding the proper process. Given that the Library > already has a signed CCLA we need to understand which of these (or other > processes) apply: > [http://incubator.apache.org/ip-clearance/ip-clearance-template.html] > and > [https://www.apache.org/licenses/contributor-agreements.html#grants] -- 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
