Component
OpenTelemetry.PersistentStorage.FileSystem
Package Version
| Package Name |
Version |
| OpenTelemetry.Api |
1.18.0 |
| OpenTelemetry |
1.18.0 |
Runtime Version
.NET 12 + .NET 11
Description
When experimenting using OpenTelemetry in the .NET SDK, we noticed that telemetry did not get sent unless we waited 3 minutes, 10 seconds, before running another dotnet command.
This is a follow up to dotnet/sdk#55184.
Steps to Reproduce
|
this.FullPath += $"@{timestamp:yyyy-MM-ddTHHmmss.fffffffZ}.lock"; |
The way that the .lock file is written by the PersistentStorage is that it uses a timeframe added to the lock file using leasePeriodMilliseconds.
The problem is that the leases do not expire if the application closes.
While RemoveExpiredLease is called, it does not clean up these other leases.
Expected Result
A better pattern would be a RAII wrapper / Disposal pattern - when the process that created the lease dies, assuming that the Drainer was also attached to said process, it should not block subsequent executables from obtaining a lease.
I considered a Disposal pattern with the file, within the storage provider, but this does not work because the drainer is not aware of such context.
An improved disposable lease could wrap an OS-backed ownership lock, held throughout reading, uploading, and response handling:
Successful upload: delete the payload, then release ownership.
Completed but unsuccessful attempt: retain the payload and release ownership according to retry policy.
Process dies: OS ownership disappears; a later process can claim the retained payload.
Actual Result
We're using the Azure Exporter which sets leases to 3 minutes. https://github.com/Azure/azure-sdk-for-net/blob/Azure.Monitor.OpenTelemetry.Exporter_1.9.0/sdk/monitor/Azure.Monitor.OpenTelemetry.Exporter/src/Internals/TransmitFromStorageHandler.cs
This means that if I run dotnet --info and then dotnet foobar, the next command foobar wouldn't get a chance to actually drain anything from --info unless I waited over 3 minutes before the next command.
Additional Context
No response
Tip
No response
Component
OpenTelemetry.PersistentStorage.FileSystem
Package Version
Runtime Version
.NET 12 + .NET 11
Description
When experimenting using OpenTelemetry in the .NET SDK, we noticed that telemetry did not get sent unless we waited 3 minutes, 10 seconds, before running another
dotnetcommand.This is a follow up to dotnet/sdk#55184.
Steps to Reproduce
opentelemetry-dotnet-contrib/src/OpenTelemetry.PersistentStorage.FileSystem/FileBlob.cs
Line 75 in f3f051e
The way that the
.lockfile is written by thePersistentStorageis that it uses a timeframe added to the lock file usingleasePeriodMilliseconds.The problem is that the leases do not expire if the application closes.
While
RemoveExpiredLeaseis called, it does not clean up these other leases.Expected Result
A better pattern would be a RAII wrapper / Disposal pattern - when the process that created the lease dies, assuming that the Drainer was also attached to said process, it should not block subsequent executables from obtaining a lease.
I considered a Disposal pattern with the file, within the storage provider, but this does not work because the drainer is not aware of such context.
An improved disposable lease could wrap an OS-backed ownership lock, held throughout reading, uploading, and response handling:
Actual Result
We're using the Azure Exporter which sets leases to 3 minutes. https://github.com/Azure/azure-sdk-for-net/blob/Azure.Monitor.OpenTelemetry.Exporter_1.9.0/sdk/monitor/Azure.Monitor.OpenTelemetry.Exporter/src/Internals/TransmitFromStorageHandler.cs
This means that if I run
dotnet --infoand thendotnet foobar, the next commandfoobarwouldn't get a chance to actually drain anything from--infounless I waited over 3 minutes before the next command.Additional Context
No response
Tip
No response