swisslife-oss / thor-client Goto Github PK

The documentation repository has to be filled with content.

The tracing session does not contain any custom EventSources. There must be a way to configure custom prefixes in order to realize loading custom EventSources. The prefix refers to the assembly name. An assembly's name that starts with the prefix will be loaded into the tracing session.

Description

As of version 2.1 .Net core offers HTTP client factories to get fine-grained control over the creation of HTTP clients. This does not only mean to have a unique way of creating HTTP clients which in turn is good for enforcing best practice. But also helps by running code before and after each HTTP message request is executed. This is in particular good for tracing, because we need to create the activity before running the actual request and destroy the activity after receiving the response..

The goal of this Issue is to create a HTTP client factory that injects a tracing HTTP message handler into the HTTP client. Whereas the HTTP message handler does nothing else than creating a HTTP client activity, storing the activity id in a HTTP request header, executing the HTTP request, waiting for the HTTP response status and closing the HTTP client activity afterwards.

Acceptance Criteria

• A HTTP client factory that creates a HTTP client with a specific HTTP message handler
• The HTTP client and message handler must be reused
• Every request made by the HTTP client must create a HTTP client activity which encompasses the actual HTTP request
• The HTTP request must have a header (Thor-ActivityId) that contains the HTTP client activity id

In order to be able to pickup telemetry events, we have to implement a telemetry event sessions for Out-Of-Process scenarios.

ETW messages support a maximum message size of 64KB and does not support complex payloads. However, sometimes this limit exceeds in case of a SOAP message for example or it is needed to log a complex type like a POCO. Therefore a different mechanism is needed to ensure those gigantic messages or complex types can be traced as well.

Define and implement the behavior which should decide what is happening if the ConnectionString for the EventHub or the Blob Storage is not set properly for instance.

Integrate GenericHost into Clients and refine namespaces (Thor.Extensions and Thor.Hosting)

Implement middleware for aspnet core web projects.

Add possibility for the client in GenericHost to initialize services on startup.

In order to be able to pickup telemetry events, we have to implement a telemetry event sessions for In-Process scenarios.

Random exeption when disposing EventHubTransmitter:
System.ObjectDisposedException : The CancellationTokenSource has been disposed.
on line _disposeToken?.Dispose();

Also observed random exception in the same dispose method on:
_transmission?.Dispose(); with exception A task may only be disposed if it is in a completion state (RanToCompletion, Faulted or Canceled)

If config-section is or config values are missing, include specific section or value name in error message, instead of throwing null pointer exception. This helps to more quickly find and fix the issue (v.3.1.1)

Acceptance Criteria

• Attachments must be stored in Azure BLOB Storage
• Attachments must be stored in the same way as before (.Net classic) to avoid incompatibility issues on the server-side
• The Azure BLOB Storage connection string must be configurable through .Net core options

Resolve per convention entry assembly name prefix (e.g. MyProduct.MyaApp) and add it to allow prefixed on the session, to enable all application specific diagnostic sources without configuration.

Afterwords user can still use configuration for additional diagnostic sources which he wants to trace.

Maybe for resolver user can pass regex for extracting the prefix from assembly name, to don't have to strict convention on assembly name.

Readme needs content.