[jira] [Comment Edited] (SOLR-15367) Convert "rid" functionality into a default Tracer

["Chris M. Hostetter (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-15367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17442501#comment-17442501 ] 

Chris M. Hostetter edited comment on SOLR-15367 at 11/11/21, 11:23 PM:
-----------------------------------------------------------------------

{quote}"rid" supports a user-specified parameter of "rid". If we go with this issue, then it would only be supported as an HTTP header, whatever we choose to name it. That should be fine, I think.
{quote}
FWIW: I think there is some definite advantage to people being able to specify rid in the request params

EDIT: To elaborate...

Right now, for example, I have no idea how to tell someone using SolrJ how/where they might be able to set an HTTP header to do "distributed tracing" from their application to solr – or even what header to set (since AFAICT that depends on what Tracer implementation you are using and how it's configured) assuming there is an easy way I'm not familiar with to hook into the HttpRequest generation in the various solrj SolrClient impls to add your own customer header.

IIUC, even if a "solr client" application using SolrJ already uses an  Open-Tracing  Tracer impl on the "client side" there are no automatic hooks to populate the SolrRequests generated from solrj clients with the (are there?)

Even if we assume we solve all of that – and using SolrJ "just works" when you have a tracer configured in your client application – what if you don't want to have to care about having a Tracer in your client application just to decorate the SolrRequests? but you _do_ already have some global unique value to identify requests that you currently pass into {{rid}} params (I deal with some applications where these are composite keys built up from unique user ids) ... we _could_ add some new setter method on SolrRequest to let you "fake" that you have a (local) Tracer and populate that header – but just using SolrParams is really easy and convenient for this.

(and that's before we start worrying baout non-SolrJ client code)

All of which is to say that while I appreciate how much more robust the Tracer stuff is over the {{rid}} request param functionality – {{rid}} is brain dead simple to use, and I don't think we should remove if until/unless we have something equally brain dead simple to use.


was (Author: hossman):
{quote}"rid" supports a user-specified parameter of "rid". If we go with this issue, then it would only be supported as an HTTP header, whatever we choose to name it. That should be fine, I think.
{quote}
FWIW: I think there is some definite advantage to people being able to specify rid in the request params

> Convert "rid" functionality into a default Tracer
> -------------------------------------------------
>
>                 Key: SOLR-15367
>                 URL: https://issues.apache.org/jira/browse/SOLR-15367
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Major
>
> 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.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org