[GitHub] [accumulo] ctubbsii opened a new issue, #2623: Enable tracing in the shell using best practices for client code

[GitBox <gi...@apache.org>]

ctubbsii opened a new issue, #2623:
URL: https://github.com/apache/accumulo/issues/2623

   **Is your feature request related to a problem? Please describe.**
   
   In #2363, the TraceUtil class gained an `enable()` method and a `disable()` method to turn tracing on and off dynamically for the shell. However, this is not public API and this is not best practice for clients to enable tracing from the client side.
   
   In #2611, a change was made that enables client side spans in Accumulo's own library when the user's client code encapsulates their calls to Accumulo APIs inside a valid span of their own. This is demonstrated in apache/accumulo-example#96
   
   A comment was made, https://github.com/apache/accumulo/pull/2611#issuecomment-1090806198 , suggesting that this is how the shell should operate as well.
   
   **Describe the solution you'd like**
   The shell should start a valid span when `trace on` is specified in the shell, and stop the span when `trace off` is specified. This should replace the `TraceUtil` enable/disable methods, and any other residual code that could be cleaned up as a result. Care should be taken to only start one new span in the shell, and not create more than one if one is already started and `trace on` is called multiple times. Likewise `trace off` called multiple times should not result in an error, even though there is no open span to close.
   
   **Describe alternatives you've considered**
   The alternative is to leave the code as-is, and explicitly enable and disable it inside the shell using non-public APIs.
   
   **Additional context**
   This should allow traces to be emitted on the client side, even if tracing is not set up on the server-side. The server-side should not break if tracing is not set up there. It is understood that traces on the server-side may not be sent to the same exporter as those on the client (or any at all), because tracing may be configured differently on the server-side than on the client. This may prevent clients from gaining insight into operations that occur on the server-side, but that's okay.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [accumulo] ctubbsii commented on issue #2623: Enable tracing in the shell using best practices for client code

[GitBox <gi...@apache.org>]

ctubbsii commented on issue #2623:
URL: https://github.com/apache/accumulo/issues/2623#issuecomment-1095751826

   I'm marking this as a good first issue, only because there's already an example that shows client-side best practices for this. So, it should be relatively easy to implement.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [accumulo] dlmarion closed issue #2623: Enable tracing in the shell using best practices for client code

[GitBox <gi...@apache.org>]

dlmarion closed issue #2623: Enable tracing in the shell using best practices for client code
URL: https://github.com/apache/accumulo/issues/2623


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@accumulo.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org