Spike: Investigate if we can send data concurrently
Opened this issue · 1 comments
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