[
https://issues.apache.org/jira/browse/SOLR-15367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758741#comment-17758741
]
Chris M. Hostetter commented on SOLR-15367:
-------------------------------------------
{quote}We have the freedom in Solr 10 (being the next major release away) to
rip out anything we don't want without trying to support both. I say just rip
out "rid" and not make make this more complicated than it needs to be.
{quote}
While i generally agree with that sentiment, it wouldn't leave a very simple
"migration" path for anyone currently passing {{rid}} params to Solr. You'd
have to make an all or nothing cut over to sending tracing headers. Admittedly
if Alex backports his existing work to 9x then you can make that cutover during
any upgrade "before 10" but you still have to do it all at once across all of
your clients.
That said – i feel like Alex might be *OVERLY* concerned with backcompat and
flexibility of tweaking traceId vs rid. : )
Thinking outloud...
* A {{solr.disableRequestId}} _style_ system property makes sense to me as a
way for people who are happy with tracing to say "I don't want SearchHandler to
waste any CPU on this {{rid}} shit"
** (even if i dislike that name, but yes i understand that's based on
{{{}CommonParams.DISABLE_REQUEST_ID{}}})
* But I don't see why we need to make "traceAsRequestId" an optional setting...
** If rid logic isn't disabled, but no "rid" exists in the request params, and
a traceId _does_ exists for the request (either sent by the remote client, or
created locally) then let's just copy that traceId to the rid.
*** If there is something about this behavior you don't like, either disable
rid, or disable the default tracing, or send an explicit rid
*** Is there really anyone who is going to leave tracing enabled, *_and_*
leave rid enabled, *_and_* be harmed in some way by the traceIds getting
redundantly set as the rids if/when they don't explicitly send their own
{{rid}} param?
* Then we backport it all to 9x, and rip out all the rid stuff from main
So strawman of what the concrete changes would look like (on 9x)...
* {{SearchHandler.tagRequestWithRequestId()}}
** replace: {{...getBool(CommonParams.DISABLE_REQUEST_ID, false);}}
*** with: {{...getBool(CommonParams.DISABLE_REQUEST_ID,
Boolean.parseBoolean(System.getProperty(CommonParams.DISABLE_REQUEST_ID +
".default", "false")));}}
**** (that's my suggestion for a cleaner sysprop name - it still has "disable"
in it, but at least the name tries to indicate it's the "default" for a thing
that already exists)
* {{SearchHandler.getOrGenerateRequestId()}}
** if {{rid = req.getParams().get(CommonParams.REQUEST_ID)}} is non blank,
return {{rid}} immediately
** else if we have a tracer, and it has a traceId, return that immediately
** else return {{generateRid(req)}}
* {{CommonParams}}
** deprecate {{REQUEST_ID}} & {{DISABLE_REQUEST_ID}}
** link to docs on using tracing
(and meanwhile on main, none of this code would exist anymore)
> Convert "rid" functionality into a default Tracer
> -------------------------------------------------
>
> Key: SOLR-15367
> URL: https://issues.apache.org/jira/browse/SOLR-15367
> Project: Solr
> Issue Type: Improvement
> Components: tracing
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Solr's "rid" (request ID) functionality added in SOLR-14566 could be
> converted into a distributed-tracing OpenTracing Tracer (Solr
> TracerConfigurator) plugin, more or less. Such an implementation, enabled by
> default, would merely generate IDs and pass them along in a custom HTTP
> header. Solr's existing tracing support would then ensure that this ID is in
> MDC in the "t:" log prefix, and thus would fit in nicely. "rid" is kind of a
> cheap bolt-on by comparison, duplicative with tracing but far fewer features.
> Solr's tracing support is growing, supporting more Solr-to-Solr interaction
> than "rid" which is only in a search request.
--
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
