[
https://issues.apache.org/jira/browse/SOLR-16656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated SOLR-16656:
--------------------------------
Description:
I think there was a regression introduced in SOLR-15790 where the rid param is
no longer logged correctly.
Solr 8 logs, rid=-1 logged with final query after distributed results were
collected:
{noformat}
.... INFO (qtp1482246673-23) [c:gettingstarted s:shard1 r:core_node3
x:gettingstarted_shard1_replica_n1] o.a.s.c.S.Request
[gettingstarted_shard1_replica_n1] webapp=/solr path=/select
params={q=*:*&indent=true&q.op=OR&_=1675975274863} rid=-1 hits=0 status=0
QTime=3
{noformat}
Solr 9 logs:
{noformat}
.... INFO (qtp351877391-20) [c:gettingstarted s:shard2 r:core_node7
x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request webapp=/solr path=/select
params={q=*:*&indent=true&q.op=OR&useParams=&_=1675975376183} hits=0 status=0
QTime=6
{noformat}
I narrowed down the issue to a problem with the SearchHandler. the part that
determines if the rid param should be added does not match with the lifecycle
of the ResponseBuilder.
basically the decision to add the param is done in tagRequestWithRequestId [0]
based on the rb.isDistrib flag which will only be computed later in
getAndPrepShardHandler [1], so at the moment where this is supposed to be
added, it's always false. this param will never be logged.
Even though it's just logging, I see this as a potential regression. I think
having this info logged is very valuable.
[0]
https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L631
[1]
https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L280
was:
I think there was a regression introduced in SOLR-15790 where the rid param is
no longer logged correctly.
Solr 8 logs, rid=-1 logged with final query after distributed results were
collected:
.... INFO (qtp1482246673-23) [c:gettingstarted s:shard1 r:core_node3
x:gettingstarted_shard1_replica_n1] o.a.s.c.S.Request
[gettingstarted_shard1_replica_n1] webapp=/solr path=/select
params={q=*:*&indent=true&q.op=OR&_=1675975274863} rid=-1 hits=0 status=0
QTime=3
Solr 9 logs:
.... INFO (qtp351877391-20) [c:gettingstarted s:shard2 r:core_node7
x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request webapp=/solr path=/select
params={q=*:*&indent=true&q.op=OR&useParams=&_=1675975376183} hits=0 status=0
QTime=6
I narrowed down the issue to a problem with the SearchHandler. the part that
determines if the rid param should be added does not match with the lifecycle
of the ResponseBuilder.
basically the decision to add the param is done in tagRequestWithRequestId [0]
based on the rb.isDistrib flag which will only be computed later in
getAndPrepShardHandler [1], so at the moment where this is supposed to be
added, it's always false. this param will never be logged.
Even though it's just logging, I see this as a potential regression. I think
having this info logged is very valuable.
[0]
https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L631
[1]
https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L280
> rid parameter missing from query logs in Solr 9.x
> -------------------------------------------------
>
> Key: SOLR-16656
> URL: https://issues.apache.org/jira/browse/SOLR-16656
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Alex Deparvu
> Priority: Minor
>
> I think there was a regression introduced in SOLR-15790 where the rid param
> is no longer logged correctly.
> Solr 8 logs, rid=-1 logged with final query after distributed results were
> collected:
> {noformat}
> .... INFO (qtp1482246673-23) [c:gettingstarted s:shard1 r:core_node3
> x:gettingstarted_shard1_replica_n1] o.a.s.c.S.Request
> [gettingstarted_shard1_replica_n1] webapp=/solr path=/select
> params={q=*:*&indent=true&q.op=OR&_=1675975274863} rid=-1 hits=0 status=0
> QTime=3
> {noformat}
> Solr 9 logs:
> {noformat}
> .... INFO (qtp351877391-20) [c:gettingstarted s:shard2 r:core_node7
> x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request webapp=/solr
> path=/select params={q=*:*&indent=true&q.op=OR&useParams=&_=1675975376183}
> hits=0 status=0 QTime=6
> {noformat}
> I narrowed down the issue to a problem with the SearchHandler. the part that
> determines if the rid param should be added does not match with the lifecycle
> of the ResponseBuilder.
> basically the decision to add the param is done in tagRequestWithRequestId
> [0] based on the rb.isDistrib flag which will only be computed later in
> getAndPrepShardHandler [1], so at the moment where this is supposed to be
> added, it's always false. this param will never be logged.
> Even though it's just logging, I see this as a potential regression. I think
> having this info logged is very valuable.
> [0]
> https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L631
> [1]
> https://github.com/apache/solr/blob/47b7f6c75a43256c41abf4db1e5c0efafc15625e/solr/core/src/java/org/apache/solr/handler/component/SearchHandler.java#L280
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
