[
https://issues.apache.org/jira/browse/SOLR-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541175#comment-17541175
]
ASF subversion and git services commented on SOLR-16205:
--------------------------------------------------------
Commit c38ef272d7bcae7425e00fc8649de6f351440d0b in solr's branch
refs/heads/main from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=c38ef272d7b ]
SOLR-16205: Simplify v2 API span-population logic (#873)
Prior to this commit, V2HttpCall populated the "operationName" of
tracing spans differently depending on whether the API was implemented
as an AnnotatedApi or not. A special code path for AnnotatedApi's had
the operationName come primarily from the path value specified on the
@Endpoint annotation.
This works well for AnnotatedApis registered at the CoreContainer level,
but actually produces the wrong path for AnnotatedApis registered on
individual cores. This commit removes this optimized code path, so that
per-core AnnotatedApis produce spans consistent with everything else.
> 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
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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]
