[jira] [Commented] (SOLR-14341) Move a collection's configSet name to state.json
[
https://issues.apache.org/jira/browse/SOLR-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299009#comment-17299009
]
Nazerke Seidan commented on SOLR-14341:
---
I have written some stuff in this doc
[https://docs.google.com/document/d/1I9eKlmRXs6aGYCAyZ9Ih956ukC74YUbGpV-WOhkyKIk/edit?usp=sharing]
in order to get some inputs from you in particular backward compatibility
concern.
[~janhoy], [~houston], [~noble.paul] mentioning you as you are a watcher and
you might have some ideas, thanks.
> Move a collection's configSet name to state.json
>
>
> Key: SOLR-14341
> URL: https://issues.apache.org/jira/browse/SOLR-14341
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It's a bit odd that a collection's state.json knows everything about a
> collection except for perhaps the most important pointer -- the configSet
> name. Presently the configSet name is retrieved via
> {{ZkStateReader.getConfigName(collectionName)}} which looks at the zk path
> {{/collections/collectionName}} (an intermediate node) interpreted as a
> trivial JSON object. Combining the configSet name into state.json is simpler
> and also more efficient since many calls to grab the configset name _already_
> need the state.json (via a DocCollection object).
--
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-14341) Move a collection's configSet name to state.json
[
https://issues.apache.org/jira/browse/SOLR-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286080#comment-17286080
]
Nazerke Seidan edited comment on SOLR-14341 at 2/17/21, 6:52 PM:
-
Created a PR although many tests do fail now, working on that. I would like to
get some reviews.
https://github.com/apache/lucene-solr/pull/2391
was (Author: nazerke):
Created a PR
[https://github.com/apache/lucene-solr/pull/2391|https://github.com/apache/lucene-solr/pull/2391)]
although many tests do fail now, working on that. I would like to get some
reviews.
> Move a collection's configSet name to state.json
>
>
> Key: SOLR-14341
> URL: https://issues.apache.org/jira/browse/SOLR-14341
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
>
> It's a bit odd that a collection's state.json knows everything about a
> collection except for perhaps the most important pointer -- the configSet
> name. Presently the configSet name is retrieved via
> {{ZkStateReader.getConfigName(collectionName)}} which looks at the zk path
> {{/collections/collectionName}} (an intermediate node) interpreted as a
> trivial JSON object. Combining the configSet name into state.json is simpler
> and also more efficient since many calls to grab the configset name _already_
> need the state.json (via a DocCollection object).
--
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-14341) Move a collection's configSet name to state.json
[
https://issues.apache.org/jira/browse/SOLR-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286080#comment-17286080
]
Nazerke Seidan edited comment on SOLR-14341 at 2/17/21, 6:51 PM:
-
Created a PR
[https://github.com/apache/lucene-solr/pull/2391|https://github.com/apache/lucene-solr/pull/2391)]
although many tests do fail now, working on that. I would like to get some
reviews.
was (Author: nazerke):
Created a PR ([https://github.com/apache/lucene-solr/pull/2391)] although many
tests do fail now, working on that. I would like to get some reviews.
> Move a collection's configSet name to state.json
>
>
> Key: SOLR-14341
> URL: https://issues.apache.org/jira/browse/SOLR-14341
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
>
> It's a bit odd that a collection's state.json knows everything about a
> collection except for perhaps the most important pointer -- the configSet
> name. Presently the configSet name is retrieved via
> {{ZkStateReader.getConfigName(collectionName)}} which looks at the zk path
> {{/collections/collectionName}} (an intermediate node) interpreted as a
> trivial JSON object. Combining the configSet name into state.json is simpler
> and also more efficient since many calls to grab the configset name _already_
> need the state.json (via a DocCollection object).
--
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-14341) Move a collection's configSet name to state.json
[
https://issues.apache.org/jira/browse/SOLR-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17286080#comment-17286080
]
Nazerke Seidan commented on SOLR-14341:
---
Created a PR ([https://github.com/apache/lucene-solr/pull/2391)] although many
tests do fail now, working on that. I would like to get some reviews.
> Move a collection's configSet name to state.json
>
>
> Key: SOLR-14341
> URL: https://issues.apache.org/jira/browse/SOLR-14341
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
>
> It's a bit odd that a collection's state.json knows everything about a
> collection except for perhaps the most important pointer -- the configSet
> name. Presently the configSet name is retrieved via
> {{ZkStateReader.getConfigName(collectionName)}} which looks at the zk path
> {{/collections/collectionName}} (an intermediate node) interpreted as a
> trivial JSON object. Combining the configSet name into state.json is simpler
> and also more efficient since many calls to grab the configset name _already_
> need the state.json (via a DocCollection object).
--
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-15011) /admin/logging handler should be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279109#comment-17279109 ] Nazerke Seidan commented on SOLR-15011: --- The test is basically setting a level to only one node with "nodes=all" param. Then in the loop, every node's log level is tested if they have the same log level since it should distribute to all nodes. If the nodes param is not specified or specified with a garbage input, the log level won't be distributed. As we literally look for "nodes=all" param. Only the JmxReporter logger will change its log level which is 5th in the list com.codahale.metrics.jmx.JmxReporter > /admin/logging handler should be able to configure logs on all nodes > > > Key: SOLR-15011 > URL: https://issues.apache.org/jira/browse/SOLR-15011 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: master (9.0) > > Time Spent: 3.5h > Remaining Estimate: 0h > > The LoggingHandler registered at /admin/logging can configure log levels for > the current node. This is nice but in SolrCloud, what's needed is an ability > to change the level for _all_ nodes in the cluster. I propose that this be a > parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI > could have a checkbox for it. I don't propose that the read operations be > changed -- they can continue to just look at the node you are hitting. -- 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-15011) /admin/logging handler should be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17279079#comment-17279079 ] Nazerke Seidan commented on SOLR-15011: --- yes, I will take a look today. > /admin/logging handler should be able to configure logs on all nodes > > > Key: SOLR-15011 > URL: https://issues.apache.org/jira/browse/SOLR-15011 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: master (9.0) > > Time Spent: 3.5h > Remaining Estimate: 0h > > The LoggingHandler registered at /admin/logging can configure log levels for > the current node. This is nice but in SolrCloud, what's needed is an ability > to change the level for _all_ nodes in the cluster. I propose that this be a > parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI > could have a checkbox for it. I don't propose that the read operations be > changed -- they can continue to just look at the node you are hitting. -- 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-14341) Move a collection's configSet name to state.json
[
https://issues.apache.org/jira/browse/SOLR-14341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17278865#comment-17278865
]
Nazerke Seidan commented on SOLR-14341:
---
Interested in this issue; started working on this.
> Move a collection's configSet name to state.json
>
>
> Key: SOLR-14341
> URL: https://issues.apache.org/jira/browse/SOLR-14341
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Reporter: David Smiley
>Priority: Major
>
> It's a bit odd that a collection's state.json knows everything about a
> collection except for perhaps the most important pointer -- the configSet
> name. Presently the configSet name is retrieved via
> {{ZkStateReader.getConfigName(collectionName)}} which looks at the zk path
> {{/collections/collectionName}} (an intermediate node) interpreted as a
> trivial JSON object. Combining the configSet name into state.json is simpler
> and also more efficient since many calls to grab the configset name _already_
> need the state.json (via a DocCollection object).
--
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-15124) Remove node/container level admin handlers from ImplicitPlugins.json (core level).
[ https://issues.apache.org/jira/browse/SOLR-15124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277959#comment-17277959 ] Nazerke Seidan commented on SOLR-15124: --- Thanks Mike for noticing the SolrCoreTest.testImplicitPlugins test which is failling now. I will update the PR. > Remove node/container level admin handlers from ImplicitPlugins.json (core > level). > -- > > Key: SOLR-15124 > URL: https://issues.apache.org/jira/browse/SOLR-15124 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: David Smiley >Priority: Blocker > Labels: newdev > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > There are many very old administrative RequestHandlers registered in a > SolrCore that are actually JVM / node / CoreContainer level in nature. These > pre-dated CoreContainer level handlers. We should (1) remove them from > ImplictPlugins.json, and (2) make simplifying tweaks to them to remove that > they work at the core level. For example LoggingHandler has two constructors > and a non-final Watcher because it works in these two modalities. It need > only have the one that takes a CoreContainer, and Watcher will then be final. > /admin/threads > /admin/properties > /admin/logging > Should stay because has core-level stuff: > /admin/plugins > /admin/mbeans > This one: > /admin/system -- SystemInfoHandler > returns "core" level information, and also node level stuff. I propose > splitting this one to a CoreInfoHandler to split the logic. Maybe a separate > issue. -- 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-15011) /admin/logging handler should be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270013#comment-17270013 ] Nazerke Seidan commented on SOLR-15011: --- [~dsmiley], I have created a PR. Please, take a look, thanks. > /admin/logging handler should be able to configure logs on all nodes > > > Key: SOLR-15011 > URL: https://issues.apache.org/jira/browse/SOLR-15011 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: David Smiley >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The LoggingHandler registered at /admin/logging can configure log levels for > the current node. This is nice but in SolrCloud, what's needed is an ability > to change the level for _all_ nodes in the cluster. I propose that this be a > parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI > could have a checkbox for it. I don't propose that the read operations be > changed -- they can continue to just look at the node you are hitting. -- 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-15011) /admin/logging handler should be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264953#comment-17264953 ] Nazerke Seidan commented on SOLR-15011: --- [~dsmiley], thanks I will have a look at it. > /admin/logging handler should be able to configure logs on all nodes > > > Key: SOLR-15011 > URL: https://issues.apache.org/jira/browse/SOLR-15011 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: David Smiley >Priority: Major > > The LoggingHandler registered at /admin/logging can configure log levels for > the current node. This is nice but in SolrCloud, what's needed is an ability > to change the level for _all_ nodes in the cluster. I propose that this be a > parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI > could have a checkbox for it. I don't propose that the read operations be > changed -- they can continue to just look at the node you are hitting. -- 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] [Issue Comment Deleted] (SOLR-7229) Allow DIH to handle attachments as separate documents
[ https://issues.apache.org/jira/browse/SOLR-7229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nazerke Seidan updated SOLR-7229: - Comment: was deleted (was: Hi Tim, I was wondering whether this project is still open or not? I would like to participate in GSoC'19 by contributing to solr community. ) > Allow DIH to handle attachments as separate documents > - > > Key: SOLR-7229 > URL: https://issues.apache.org/jira/browse/SOLR-7229 > Project: Solr > Issue Type: Improvement >Reporter: Tim Allison >Assignee: Alexandre Rafalovitch >Priority: Minor > Labels: gsoc2017 > > With Tika 1.7's RecursiveParserWrapper, it is possible to maintain metadata > of individual attachments/embedded documents. Tika's default handling was to > maintain the metadata of the container document and concatenate the contents > of all embedded files. With SOLR-7189, we added the legacy behavior. > It might be handy, for example, to be able to send an MSG file through DIH > and treat the container email as well each attachment as separate (child?) > documents, or send a zip of jpeg files and correctly index the geo locations > for each image file. -- 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-15012) Add a logging filter marker for /admin/ping requests to be silenced via log4j2.xml
[ https://issues.apache.org/jira/browse/SOLR-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17237269#comment-17237269 ] Nazerke Seidan edited comment on SOLR-15012 at 11/23/20, 10:19 AM: --- [~gus], you have added a filter marker to a logger (org.apache.solr.servlet.HttpSolrCall). Similarly, we could add a marker to the SolrCore logger. was (Author: nazerke): [~gus], you have added a filter marker to a logger (org.apache.solr.servlet.HttpSolrCall). Similarly, we could add a marker to the logger of SolrCore. > Add a logging filter marker for /admin/ping requests to be silenced via > log4j2.xml > -- > > Key: SOLR-15012 > URL: https://issues.apache.org/jira/browse/SOLR-15012 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nazerke Seidan >Priority: Minor > > While looking at logs, I have observed a lot of noise from /admin/ping > requests which is often called to ping core and all replicas coming from > org.apache.solr.core.SolrCore.Request. I think it makes sense to add a > marker to SolrCore. -- 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-15012) Add a logging filter marker for /admin/ping requests to be silenced via log4j2.xml
[ https://issues.apache.org/jira/browse/SOLR-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17237269#comment-17237269 ] Nazerke Seidan commented on SOLR-15012: --- [~gus], you have added a filter marker to a logger (org.apache.solr.servlet.HttpSolrCall). Similarly, we could add a marker to the logger of SolrCore. > Add a logging filter marker for /admin/ping requests to be silenced via > log4j2.xml > -- > > Key: SOLR-15012 > URL: https://issues.apache.org/jira/browse/SOLR-15012 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nazerke Seidan >Priority: Minor > > While looking at logs, I have observed a lot of noise from /admin/ping > requests which is often called to ping core and all replicas coming from > org.apache.solr.core.SolrCore.Request. I think it makes sense to add a > marker to SolrCore. -- 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-15012) Add a logging filter marker for /admin/ping requests to be silenced via log4j2.xml
[ https://issues.apache.org/jira/browse/SOLR-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nazerke Seidan updated SOLR-15012: -- Description: While looking at logs, I have observed a lot of noise from /admin/ping requests which is often called to ping core and all replicas coming from org.apache.solr.core.SolrCore.Request. I think it makes sense to add a marker to SolrCore. (was: While looking at logs, I have observed a lot of noise from /admin/ping requests which is often called to ping core and all replicas coming from org.apache.solr.core.SolrCore.Request. [~gus], you have added a filter marker to a logger (org.apache.solr.servlet.HttpSolrCall). I think it makes sense to add a marker to SolrCore. ) > Add a logging filter marker for /admin/ping requests to be silenced via > log4j2.xml > -- > > Key: SOLR-15012 > URL: https://issues.apache.org/jira/browse/SOLR-15012 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nazerke Seidan >Priority: Minor > > While looking at logs, I have observed a lot of noise from /admin/ping > requests which is often called to ping core and all replicas coming from > org.apache.solr.core.SolrCore.Request. I think it makes sense to add a > marker to SolrCore. -- 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-15012) Add a logging filter marker for /admin/ping requests to be silenced via log4j2.xml
Nazerke Seidan created SOLR-15012: - Summary: Add a logging filter marker for /admin/ping requests to be silenced via log4j2.xml Key: SOLR-15012 URL: https://issues.apache.org/jira/browse/SOLR-15012 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Nazerke Seidan While looking at logs, I have observed a lot of noise from /admin/ping requests which is often called to ping core and all replicas coming from org.apache.solr.core.SolrCore.Request. [~gus], you have added a filter marker to a logger (org.apache.solr.servlet.HttpSolrCall). I think it makes sense to add a marker to SolrCore. -- 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-14998) any Collections Handler actions should be logged at debug level
[ https://issues.apache.org/jira/browse/SOLR-14998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17232611#comment-17232611 ] Nazerke Seidan commented on SOLR-14998: --- PR: https://github.com/apache/lucene-solr/pull/2079 > any Collections Handler actions should be logged at debug level > --- > > Key: SOLR-14998 > URL: https://issues.apache.org/jira/browse/SOLR-14998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nazerke Seidan >Priority: Minor > > CLUSTERSTATUS is logged in CollectionsHandler at INFO level but the cluster > status is already logged in HttpSolrCall at INFO. In CollectionsHandler INFO > level should be set to DEBUG to avoid a lot of noise. -- 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-14998) any Collections Handler actions should be logged at debug level
[ https://issues.apache.org/jira/browse/SOLR-14998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nazerke Seidan updated SOLR-14998: -- Summary: any Collections Handler actions should be logged at debug level (was: CLUSTERSTATUS info level logging is redundant in CollectionsHandler ) > any Collections Handler actions should be logged at debug level > --- > > Key: SOLR-14998 > URL: https://issues.apache.org/jira/browse/SOLR-14998 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Nazerke Seidan >Priority: Minor > > CLUSTERSTATUS is logged in CollectionsHandler at INFO level but the cluster > status is already logged in HttpSolrCall at INFO. In CollectionsHandler INFO > level should be set to DEBUG to avoid a lot of noise. -- 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-14998) CLUSTERSTATUS info level logging is redundant in CollectionsHandler
[
https://issues.apache.org/jira/browse/SOLR-14998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231708#comment-17231708
]
Nazerke Seidan commented on SOLR-14998:
---
{{logs from CollectionsHandler: Invoked Collection Action :clusterstatus with
params action=CLUSTERSTATUS=javabin=2 and sendToOCPQueue=true}}
{{logs from HttpSolrCall:[admin] webapp=null path=/admin/collections
params=\{action=CLUSTERSTATUS=javabin=2} status=0 QTime=1}}
{{From the logs I see only action=CLUSTERSTATUS but it should be any
Collections handler actions }}
> CLUSTERSTATUS info level logging is redundant in CollectionsHandler
> -
>
> Key: SOLR-14998
> URL: https://issues.apache.org/jira/browse/SOLR-14998
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Nazerke Seidan
>Priority: Minor
>
> CLUSTERSTATUS is logged in CollectionsHandler at INFO level but the cluster
> status is already logged in HttpSolrCall at INFO. In CollectionsHandler INFO
> level should be set to DEBUG to avoid a lot of noise.
--
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-14998) CLUSTERSTATUS info level logging is redundant in CollectionsHandler
Nazerke Seidan created SOLR-14998: - Summary: CLUSTERSTATUS info level logging is redundant in CollectionsHandler Key: SOLR-14998 URL: https://issues.apache.org/jira/browse/SOLR-14998 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Nazerke Seidan CLUSTERSTATUS is logged in CollectionsHandler at INFO level but the cluster status is already logged in HttpSolrCall at INFO. In CollectionsHandler INFO level should be set to DEBUG to avoid a lot of noise. -- 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-14905) Update commons-io version to 2.8.0 due to security vulnerability
Nazerke Seidan created SOLR-14905:
-
Summary: Update commons-io version to 2.8.0 due to security
vulnerability
Key: SOLR-14905
URL: https://issues.apache.org/jira/browse/SOLR-14905
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: security
Affects Versions: 8.6.2
Reporter: Nazerke Seidan
The {{commons-io}} (version 2.6) package is vulnerable to Path Traversal. The
{{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
hostname value received from user input before processing client requests.
The issue has been fixed in 2.7 onward:
(https://issues.apache.org/jira/browse/IO-556,
https://issues.apache.org/jira/browse/IO-559)
--
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-14408) Refactor MoreLikeThisHandler Implementation
[ https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17203836#comment-17203836 ] Nazerke Seidan commented on SOLR-14408: --- Hello [~alessandro.benedetti], No worries:) Regarding the InterestingTerm class, I have browsed the codebase and couldn't find any similar class to that. I think it is ok. I hope we can progress quickly with the merge. > Refactor MoreLikeThisHandler Implementation > --- > > Key: SOLR-14408 > URL: https://issues.apache.org/jira/browse/SOLR-14408 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Nazerke Seidan >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The main goal of this refactoring is for readability and accessibility of > MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two > static subclasses and accessing them later in MoreLikeThisComponent. I > propose to have them as separate public classes. > cc: [~abenedetti], as you have had the recent commit for MLT, what do you > think about this? Anyway, the code is ready for review. > > > -- 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-14210) Add replica state option for HealthCheckHandler
[
https://issues.apache.org/jira/browse/SOLR-14210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139190#comment-17139190
]
Nazerke Seidan edited comment on SOLR-14210 at 6/18/20, 8:03 AM:
-
If Zk is down/unavailable, we can't get the status of the cores. I think this
should be configurable without Zk we should be able to ping the solr cores.
was (Author: seidan):
Wondering if Zk is down/unavailable, can we still get the status of the cores?
> Add replica state option for HealthCheckHandler
> ---
>
> Key: SOLR-14210
> URL: https://issues.apache.org/jira/browse/SOLR-14210
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.5
>Reporter: Houston Putman
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Attachments: docs.patch
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> h2. Background
> As was brought up in SOLR-13055, in order to run Solr in a more cloud-native
> way, we need some additional features around node-level healthchecks.
> {quote}Like in Kubernetes we need 'liveliness' and 'readiness' probe
> explained in
> [https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/n]
> determine if a node is live and ready to serve live traffic.
> {quote}
>
> However there are issues around kubernetes managing it's own rolling
> restarts. With the current healthcheck setup, it's easy to envision a
> scenario in which Solr reports itself as "healthy" when all of its replicas
> are actually recovering. Therefore kubernetes, seeing a healthy pod would
> then go and restart the next Solr node. This can happen until all replicas
> are "recovering" and none are healthy. (maybe the last one restarted will be
> "down", but still there are no "active" replicas)
> h2. Proposal
> I propose we make an additional healthcheck handler that returns whether all
> replicas hosted by that Solr node are healthy and "active". That way we will
> be able to use the [default kubernetes rolling restart
> logic|https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies]
> with Solr.
> To add on to [Jan's point
> here|https://issues.apache.org/jira/browse/SOLR-13055?focusedCommentId=16716559=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16716559],
> this handler should be more friendly for other Content-Types and should use
> bettter HTTP response statuses.
--
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-14210) Add replica state option for HealthCheckHandler
[
https://issues.apache.org/jira/browse/SOLR-14210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17139190#comment-17139190
]
Nazerke Seidan commented on SOLR-14210:
---
Wondering if Zk is down/unavailable, can we still get the status of the cores?
> Add replica state option for HealthCheckHandler
> ---
>
> Key: SOLR-14210
> URL: https://issues.apache.org/jira/browse/SOLR-14210
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.5
>Reporter: Houston Putman
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.6
>
> Attachments: docs.patch
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> h2. Background
> As was brought up in SOLR-13055, in order to run Solr in a more cloud-native
> way, we need some additional features around node-level healthchecks.
> {quote}Like in Kubernetes we need 'liveliness' and 'readiness' probe
> explained in
> [https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/n]
> determine if a node is live and ready to serve live traffic.
> {quote}
>
> However there are issues around kubernetes managing it's own rolling
> restarts. With the current healthcheck setup, it's easy to envision a
> scenario in which Solr reports itself as "healthy" when all of its replicas
> are actually recovering. Therefore kubernetes, seeing a healthy pod would
> then go and restart the next Solr node. This can happen until all replicas
> are "recovering" and none are healthy. (maybe the last one restarted will be
> "down", but still there are no "active" replicas)
> h2. Proposal
> I propose we make an additional healthcheck handler that returns whether all
> replicas hosted by that Solr node are healthy and "active". That way we will
> be able to use the [default kubernetes rolling restart
> logic|https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies]
> with Solr.
> To add on to [Jan's point
> here|https://issues.apache.org/jira/browse/SOLR-13055?focusedCommentId=16716559=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16716559],
> this handler should be more friendly for other Content-Types and should use
> bettter HTTP response statuses.
--
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-14408) Refactor MoreLikeThisHandler Implementation
[ https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126088#comment-17126088 ] Nazerke Seidan commented on SOLR-14408: --- [~alessandro.benedetti], wondering if you have taken a look at the PR. > Refactor MoreLikeThisHandler Implementation > --- > > Key: SOLR-14408 > URL: https://issues.apache.org/jira/browse/SOLR-14408 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Nazerke Seidan >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The main goal of this refactoring is for readability and accessibility of > MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two > static subclasses and accessing them later in MoreLikeThisComponent. I > propose to have them as separate public classes. > cc: [~abenedetti], as you have had the recent commit for MLT, what do you > think about this? Anyway, the code is ready for review. > > > -- 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-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113070#comment-17113070 ] Nazerke Seidan commented on SOLR-14384: --- [~mkhl] I think it is a good idea to add some more information to the description for the clarification purpose. I couldn't edit the description. > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- 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-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110598#comment-17110598 ] Nazerke Seidan edited comment on SOLR-14384 at 5/18/20, 8:42 PM: - Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I have refactored the code. was (Author: seidan): Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I refactored the code. > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- 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-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110598#comment-17110598 ] Nazerke Seidan commented on SOLR-14384: --- Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I refactored the code. > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- 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-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17105501#comment-17105501 ] Nazerke Seidan commented on SOLR-14384: --- [~mkhl] , I am working on this issue by introducing suggested stack idea ([~dsmiley] ). I noticed SolrRequestInfoSuspender extends SolrRequestInfo and removes the threadlocal later on. But SolrRequestInfoSuspender is no longer needed now as all SolrRequestInfos are stacked. What do you think if we remove SolrRequestInfoSuspender? > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- 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-14408) Refactor MoreLikeThisHandler Implementation
[ https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083995#comment-17083995 ] Nazerke Seidan edited comment on SOLR-14408 at 4/21/20, 1:27 PM: - [~alessandro.benedetti] I've linked the PR was (Author: seidan): just linked the PR > Refactor MoreLikeThisHandler Implementation > --- > > Key: SOLR-14408 > URL: https://issues.apache.org/jira/browse/SOLR-14408 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: MoreLikeThis >Reporter: Nazerke Seidan >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The main goal of this refactoring is for readability and accessibility of > MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two > static subclasses and accessing them later in MoreLikeThisComponent. I > propose to have them as separate public classes. > cc: [~abenedetti], as you have had the recent commit for MLT, what do you > think about this? Anyway, the code is ready for review. > > > -- 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-14408) Refactor MoreLikeThisHandler Implementation
[ https://issues.apache.org/jira/browse/SOLR-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17083995#comment-17083995 ] Nazerke Seidan commented on SOLR-14408: --- just linked the PR > Refactor MoreLikeThisHandler Implementation > --- > > Key: SOLR-14408 > URL: https://issues.apache.org/jira/browse/SOLR-14408 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: MoreLikeThis >Reporter: Nazerke Seidan >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The main goal of this refactoring is for readability and accessibility of > MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two > static subclasses and accessing them later in MoreLikeThisComponent. I > propose to have them as separate public classes. > cc: [~abenedetti], as you have had the recent commit for MLT, what do you > think about this? Anyway, the code is ready for review. > > > -- 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-14408) Refactor MoreLikeThisHandler Implementation
Nazerke Seidan created SOLR-14408: - Summary: Refactor MoreLikeThisHandler Implementation Key: SOLR-14408 URL: https://issues.apache.org/jira/browse/SOLR-14408 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: MoreLikeThis Reporter: Nazerke Seidan The main goal of this refactoring is for readability and accessibility of MoreLikeThisHandler class. Current MoreLikeThisHandler class consists of two static subclasses and accessing them later in MoreLikeThisComponent. I propose to have them as separate public classes. cc: [~abenedetti], as you have had the recent commit for MLT, what do you think about this? Anyway, the code is ready for review. -- 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
