Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains three changes:
Flush events only when the buffer is full (#827, contributed by @danigutierrezayuso)
Previously the buffer size configuration didn't work as intended – requests to the collector were initiated right after the event was tracked regardless of the buffer size.
This change fixes that and only makes the request once the buffer size is reached.
Change default buffer option to single (#849)
As mentioned before, previously the buffer size was effectively equal to 1 (even though we stated it was 10). Fixing the above bug, we would now change the buffer size to 10.
Buffer size 1 is probably a better default for client side trackers to avoid losing events that don't make it to a request before an app is quit/uninstalled. Also the same is used on the JavaScript tracker.
This change sets the default buffer size to 1 (from a user's point of view there won't be a difference compared to previous versions).
Make network requests serially in network connection (#827)
This change tries to address a problem with duplicate events often showing up in the warehouse. It is possible that this is called by sending too many parallel requests at once which causes either the requests to fail or timeout and then be retried.
After doing some tests, I discovered that making parallel requests from the client has very little benefit. The total time it takes to send all the events is very close to what it would be if requests were made serially.
The new behaviour updates how the
emitRange
configuration is used – it now tells how many events should be added to one request. For this reason, I also lowered the default value to 25.When merging this PR, I will rebase the commits so that they show up individually in the release branch.