[
https://issues.apache.org/jira/browse/SOLR-15541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17382138#comment-17382138
]
Christine Poerschke edited comment on SOLR-15541 at 7/16/21, 3:26 PM:
----------------------------------------------------------------------
{quote}I'm not a fan of the duplicated information between params and allParams
in this approach.
{quote}
Yes, it's a bit ugly to duplicate the information and {{params}} vs.
{{allParams}} also isn't exactly helpful in terms of meaning and the
differences.
Thinking aloud, two alternatives, in no particular order:
* remove {{params}} and log {{allParams}} only (under the {{allParams}} name
or some other suitable name)
** the removal of {{params}} may present backwards compatibility type concerns?
** do we know for sure that {{params}} is a subset of {{allParams}} or could
elements in {{params}} have been removed and so not show in {{allParams}}?
* keep {{params}} and instead of {{allParams}} log {{deltaParams}} of some
sort (under the {{deltaParams}} name or some other suitable name)
** the keeping of {{params}} provides backwards compatibility
** {{deltaParams}} would identify as "+" parameters not present in {{params}}
because they came from handler configuration or were added by search components
** {{deltaParams}} would identify as "-" parameters that were present in the
original {{params}} but which are no longer present after processing of the
request
** {{deltaParams}} would identify as "-/+" parameters that were present in the
original {{params}} and which remain present but with a different value
was (Author: cpoerschke):
bq. I'm not a fan of the duplicated information between params and allParams in
this approach.
Yes, it's a big ugly to duplicate the information and {{params}} vs.
{{allParams}} also isn't exactly helpful in terms of meaning and the
differences.
Thinking aloud, two alternatives, in no particular order:
* remove {{params}} and log {{allParams}} only (under the {{allParams}} name or
some other suitable name)
** the removal of {{params}} may present backwards compatibility type concerns?
** do we know for sure that {{params}} is a subset of {{allParams}} or could
elements in {{params}} have been removed and so not show in {{allParams}}?
* keep {{params}} and instead of {{allParams}} log {{deltaParams}} of some sort
(under the {{deltaParams}} name or some other suitable name)
** the keeping of {{params}} provides backwards compatibility
** {{deltaParams}} would identify as "+" parameters not present in {{params}}
because they came from handler configuration or were added by search components
** {{deltaParams}} would identify as "-" parameters that were present in the
original {{params}} but which are no longer present after processing of the
request
** {{deltaParams}} would identify as "-/+" parameters that were present in the
original {{params}} and which remain present but with a different value
> opt-in support to INFO log all parameters on error
> --------------------------------------------------
>
> Key: SOLR-15541
> URL: https://issues.apache.org/jira/browse/SOLR-15541
> Project: Solr
> Issue Type: New Feature
> Reporter: Christine Poerschke
> Assignee: Christine Poerschke
> Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> * The
> [logParamsList|https://solr.apache.org/guide/8_9/common-query-parameters.html#logparamslist-parameter]
> parameter (available from Solr 4.7 onwards via SOLR-5672) is useful if full
> request logging on each of multiple shards is just 'too much' and/or if the
> content being logged is to be redacted e.g. to only log opaque request
> identifiers but not request details.
> ** A downside of reduced logging is that less detail is available when
> investigating issues.
> * The
> [echoParams|https://solr.apache.org/guide/8_9/common-query-parameters.html#echoparams-parameter]
> parameter controls what information about request parameters is included in
> the response header.
> ** With respect to investating of issues it's worth noting here that
> {{echoParams=explicit}} is the default value and that routine use of
> {{echoParams=all}} would return more details to the client but that details
> of within-Solr requests e.g. requests using the {{group.distributed.first}}
> and {{group.distributed.second}} [group
> parameters|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.9.0/solr/solrj/src/java/org/apache/solr/common/params/GroupParams.java#L60-L66]
> would _not_ be captured.
> This ticket proposes to add a new parameter, called (say)
> {{logAllParamsOnError}} whose use will result in all parameters being logged
> on error, irrespective of the presence or value of the {{logParamsList}}
> parameter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
