I found this in opentelemetry/specification/trace/api:
If the language has support for implicitly propagated Context (see here), the API SHOULD also provide the following functionality:
Get the currently active span from the implicit context. This is equivalent to getting the implicit context, then extracting the Span from the context.
Set the currently active span to the implicit context. This is equivalent to getting the implicit context, then inserting the Span to the context.
But I didn't find the method to get the currently active span in java or go. Is there any language that support this feature?
Any help will be appreciated!
Yes, .NET supports it: global::OpenTelemetry.Trace.Tracer.CurrentSpan. This works, because there can be only one 'active' span in any given execution flow at a time. To be clear: there can be more than one span concurrently active, just not in the same execution flow; execution flows can fork, but each fork has only one active span at a time.
Also, .NET already has the equivalent of the OpenTelemetry API in its Activity API.
Tracer is a wrapper around ActivitySource.
TelemetrySpan is a wrapper around Activity.
You can also get the current System.Diagnostics.ActivityContext by accessing Activity.Current.Context.
The OpenTelemetry API's .NET reference implementation recommends that you just use the .NET framework's built-in Activity API directly. However, it also provides OpenTelemetry shims that wrap the Activity API.
For example, you can implicitly convert an OpenTelemetry.Trace.SpanContext to a System.Diagnostics.ActivityContext. And you can convert it back with new OpenTelemetry.Trace.SpanContext(activityContext).
I don't see a method to get a TelemetrySpan from a SpanContext; however. So global::OpenTelemetry.Trace.Tracer.CurrentSpan is probably your best bet.
Related
Issue related to AXON EXTENSION TRACING: TracingAutoConfiguration.configureEventHandler method printing same event (i.e. GenericDomainEventMessage) in log multiple times from given interceptor o.a.e.t.OpenTraceHandlerInterceptor.
How to avoid/stop multiple times printing for same event please suggest
click here for reference
The multiple log lines is not per definition wrong. As Lucas also states, the GenericDomainEventMesasge is the object which Axon uses (at all times) to wrap your events in. Without doing so, the framework cannot pull apart whether it is dealing with an Event, Command or Query messages to begin with.
Furthermore, as a TrackingEventProcessor can run in parallel, with multiple threads, you could see a bunch of loglines going through.
On any note, the given description at this stage is too minimal to deduce where the exact problem arises if it is a problem at all.
Hence, I would like to ask you to provide the following, based on which I/we can update this answer:
What version of Axon Framework are you using?
What version of Axon's Tracing Extension are you using?
What do your Event Handling classes look like?
Is there any specific configuration in place for these Event Handling classes?
I'm currently developing an app in Laravel. While trying to adhere to REST API guidelines I've come across a scenario that I'm not sure how to handle RESTfully.
I have a Lease resource that handles multiple actions:
Route::get('/lease/create', 'API\LeaseController#create');
Route::get('/lease/{leaseId}', 'API\LeaseController#show');
Route::post('/lease', 'API\LeaseController#store');
Route::patch('/lease/{leaseId}', 'API\LeaseController#update');
Route::delete('/lease/{leaseId}', 'API\LeaseController#destroy');
So far these are a 1:1 between the URI and the controller actions. Now I have additional operations that I need to perform on a Lease and this is where I'm not sure what the best way to handle this is.
1) A Lease can be renewed (clone existing lease with new start and end dates).
2) A Lease can be ended (status changed to Inactive, end date updated).
When I think about doing this RESTfully I look at these two additional operations as a post and a patch to existing endpoints (both would map to the store and update method on the controller and could use the existing URIs.
Should I continue to think about it that way and map them both to existing endpoints? My concern with that is how would I handle different responses? For example if after a renew operation completes I want to pass a message saying "This lease has been successfully renewed.", how would I differentiate between a renew operation and a regular store operation since they both hit the same end point?
Or should I create two new URI's, something like:
Route::patch('/lease/{leaseId}/end', 'API\LeaseController#updateLeaseEnd');
Route::post('/lease/{leaseId}/renew', 'API\LeaseController#storeLeaseRenew');
And control logic in two separate functions even though it would be somewhat redundant since they really are just additional stores and updates?
It looks like you are trying to fit a RPC style API into a RESTful style API, which is possible, but can be confusing. You could do like you were saying with using the PATCH method, but now you have an overloaded method that should only do a partial update, but now it might execute an action on the resource. That would be confusing.
One way I've seen this done is by using what is called a verb (not to be confused by the "HTTP Verb") in the URI. This is essentially what you were stating as your last option in the question.
Structure
https://api.domain.com/namespace/resource/_verb
https://api.domain.com/namespace/resource/{id}/_verb
Example
https://api.domain.com/namespace/lease/{id}/_end
https://api.domain.com/namespace/lease/{id}/_renew
The underscore is there to signify that this is not a resource, but rather an execution call.
Another option would be to separate your REST API from your RPC API. You could use the traditional SOAP web service or go with the new gRPC, by Google.
Is there any reason, other than semantics, to create different dispatch methods for view and server actions? All tutorials and examples I’ve seen (most notably this) ignore the source constant entirely when listening to dispatched payloads in favor of switching on the payload's action type.
I suppose there is a reason why this pattern is pervasive in flux examples, but I have yet to see a concrete example as to why this is useful. Presumably one could add an additional if or switch on the payload source to determine whether to act in stores, but no examples I've seen consider this constant at all. Any thoughts on this would be much appreciated.
Yes, this was cruft/cargo-culting that came over from a particular Flux project at Facebook, but there is no real reason to do this. If you do need to differentiate between server and view actions, you can just give them different types, or have another property of the action itself to help differentiate them.
When I get time, I plan to rewrite all the examples and documentation to reflect this.
I am currently using Neo4j over the REST interface and would love to use NewRelic to analyze which calls take the longest. It can happen that within a request/response cycle (or action/view) I need to call the DB more than once.
I tried using NewRelic for the first time, but it can only show me the many HTTP calls im making and how long they take, but not which call correlates to which part of the method.
I hope I have expressed my problem somewhat clearly, I would just love to be able to figure out which calls take the longest.
You can give different names to your various HTTP calls using New Relic's custom instrumentation (see the section "Tracing Blocks of Code"). You can wrap a block of Ruby with a call to trace_execution_scoped, a method provided in the Ruby agent API.
The names you give your different calls will show up in Transaction Traces and in the breakdown of where each of your Web Transactions spends time in aggregate.
I need to create asynchronously executing task (pure JS) that is creating and working with XPCOM components (using Components.classes and Components.interfaces).
However, Worker and ChromeWorker do not have access to Components. Also, I cannot pass to them an XPCOM component created in the main thread (postMessage), as XPCOM components are not serializable.
It seems that it can be possible with nsIThread and nsIThreadManager, but documentation states that
In versions of Gecko prior to 2.0, it is possible to create real asynchronous threads.
Although this can often be accomplished without serious adverse effects, it is far from safe
and often leads to unpredictable crashes. For this reason, as of Gecko 2.0, it is no longer
possible to pass JavaScript objects from one thread to another, making the Thread Manager
unuseable from JavaScript.
and I do not want to introduce any incompatibility with Gecko 2.0.
Are there other ways to do that?
P. S. I find (Chrome)Workers hardly usable at all, as they do not have access neither to the DOM nor to Components. Why one would ever want to use them?
No, most XPCOM components are not thread-safe so that working with them from a different thread would only lead to crashes (which is why Thread Manager was rendered inaccessible to scripts). If your task contains lots of computations - use Worker to move it off the main thread and postMessage to tell the main thread access XPCOM whenever necessary. If it is mainly accessing XPCOM then it will be no use of course. You will have to do the work on the main thread and split it into small chunks to make sure that the main thread isn't being blocked. You can use nsIEventTarget.dispatch() to schedule the next processing step, something like this:
var thread = Components.classes["#mozilla.org/thread-manager;1"]
.getService(Components.interfaces.nsIThreadManager)
.currentThread;
var currentStep = -1;
function nextStep()
{
currentStep++;
//
// Execute step currentStep here
//
// Schedule next step
thread.dispatch(nextStep, thread.DISPATCH_NORMAL);
}
nextStep();
Documentation:
nsIThreadManager
nsIThread
nsIEventTarget