[
https://issues.apache.org/jira/browse/SOLR-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539657#comment-17539657
]
Jason Gerlowski commented on SOLR-16205:
----------------------------------------
There are a few ways we could handle this:
* change core-level AA registration in a way that'd allow us to specify full
paths on AA's
* add a getCanonicalPath method to the Api or AnnotatedApi interface, and have
V2HttpCall use that
* leave the AA paths as-is, but add logic to V2HttpCall to detect when an AA is
registered at the core-level and add a path prefix based on that.
But maybe the simplest and best approach here is to get rid of the AnnotatedApi
special-case altogether, and always compute the full path from individual
segments as we do in the "normal" case
[here|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/api/V2HttpCall.java#L431].
Any chance you have thoughts on what makes the most sense here [~dsmiley]? I
think you added the AnnotatedApi special case in your work on SOLR-15392. Was
it an optimization just to save us some cycles? Do you expect it to be
significant enough that you'd have qualms if we ditched it?
> Span operationName for v2 APIs should include collection/core names
> -------------------------------------------------------------------
>
> Key: SOLR-16205
> URL: https://issues.apache.org/jira/browse/SOLR-16205
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: 9.0
> Reporter: Jason Gerlowski
> Priority: Minor
>
> HttpSolrCall and V2HttpSolrCall are responsible for populating the
> opentracing "spans" that track individual API calls. A big piece of this is
> assigning each span an "operationName", which typically consists of a HTTP
> verb and a normalized copy of the URL path (separated by a colon).
> It looks like the intention is that these URL paths should be complete. i.e.
> They're not just the request handler name or whatever follows the collection
> name, but the full URL path.
> But for some AnnotatedApis, we do end up using an incomplete path.
> The [span population
> logic|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/api/V2HttpCall.java#L429]
> for v2 APIs has a special check for AA instances - if the API call in
> question is an AA, we grab the first path off the AA "Endpoint" as a shortcut
> to save us the work of joining and normalizing each of the path segments held
> by the HttpSolrCall/V2HttpCall.
> This works great for AA's registered at the CoreContainer level: the
> annotations for those AA's include the full path (e.g.
> [ReloadCollectionAPI|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/admin/api/ReloadCollectionAPI.java]).
> But this _isn't_ the case for AA's registered at the individual-core level,
> the annotations on these AA's only includes the path segments that follows
> the core/collection name. (e.g.
> [RealTimeGetAPI|https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/admin/api/RealTimeGetAPI.java#L42]).
> As a result, core-level AA's produce spans with operationName's like
> {{get:/get}}, instead of the fuller {{get:/c/\{collection\}/get}}.
> I'm not sure this is a huge deal either way, but it'd be a nice consistency
> thing to straighten out.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
