You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the story, please be clear on scope of the story.
Currently, ConnectionManager uses a primitive synchronization object to control access to the connect / disconnect / reconnect / send data methods. This has the side effect of only allowing a single call to SendDataRequest() at a time, even though there may be multiple event harvests occurring simultaneously.
This spike is to investigate whether a different locking mechanism (such as ReaderWriterLockSlim) could be used to allow multiple SendDataRequest() invocations in parallel, while still blocking send data when a connect / disconnect / reconnect operation is occurring.
There is a poc branch at https://github.com/newrelic/newrelic-dotnet-agent/tree/chore/connection-manager-locking-refactor that has an initial implementation, but questions came up as to how we could properly handle the case of (for example) a reconnect being required as the result of one SendDataRequest() invocation while another invocation was also in progress. Would there be a potential for sending duplicate data to NR or would the second request also possibly initiate a reconnect that we would need to handle if a reconnect was already in progress? There is also a question as to whether other language agents are sending data in parallel or not - if none are, there's probably a good reason for it.
Acceptance Criteria
Spike document that either shows that this idea is infeasible, or a milestone document to lay out how the feature could be implemented.
Estimates
Please provide initial t-shirt size
M
The text was updated successfully, but these errors were encountered:
Describe the story, please be clear on scope of the story.
Currently,
ConnectionManager
uses a primitive synchronization object to control access to the connect / disconnect / reconnect / send data methods. This has the side effect of only allowing a single call toSendDataRequest()
at a time, even though there may be multiple event harvests occurring simultaneously.This spike is to investigate whether a different locking mechanism (such as
ReaderWriterLockSlim
) could be used to allow multipleSendDataRequest()
invocations in parallel, while still blocking send data when a connect / disconnect / reconnect operation is occurring.There is a poc branch at https://github.com/newrelic/newrelic-dotnet-agent/tree/chore/connection-manager-locking-refactor that has an initial implementation, but questions came up as to how we could properly handle the case of (for example) a reconnect being required as the result of one
SendDataRequest()
invocation while another invocation was also in progress. Would there be a potential for sending duplicate data to NR or would the second request also possibly initiate a reconnect that we would need to handle if a reconnect was already in progress? There is also a question as to whether other language agents are sending data in parallel or not - if none are, there's probably a good reason for it.Acceptance Criteria
Spike document that either shows that this idea is infeasible, or a milestone document to lay out how the feature could be implemented.
Estimates
Please provide initial t-shirt size
M
The text was updated successfully, but these errors were encountered: