Related to discussion in PR #305 - event sending retry.
Since v0.10.0, when an event is added to the Emitter, there is an attempt to add it to the event buffer. If it fails because the event buffer is full, an error message is logged, and the event is lost. This means that older events would be prioritised in the event of network connection loss. We assume that eventually dropping events is better than crashing the whole app.
In versions 0.10.0 and 0.11.0, the event buffer capacity is not configurable, and is the default capacity for a LinkedBlockingQueue - Integer.MAX_VALUE. It is likely that the app would run out of memory before buffering this many events. This capacity will be configurable from version 0.12.0.
In the above PR, events that are in the process of being sent are removed from the main event buffer and put into a temporary collection. If the request is successful they're deleted; if not, they should be returned to the event buffer. If the event buffer is now full, there's nowhere for them to go.
Possible solutions are:
Counting how many events are currently being sent and in the pending buffer, and saving space for them in the main event buffer.
If a request fails, removing the right number of events from the end of the event buffer to make space for the returnees. This could be difficult locks/synchronisation-wise.
We could also complicate things by allowing users to choose a policy for what to do if the network is down and the Emitter is full - as in the Scala tracker.
Related to discussion in PR #305 - event sending retry.
Since v0.10.0, when an event is added to the Emitter, there is an attempt to add it to the event buffer. If it fails because the event buffer is full, an error message is logged, and the event is lost. This means that older events would be prioritised in the event of network connection loss. We assume that eventually dropping events is better than crashing the whole app.
In versions 0.10.0 and 0.11.0, the event buffer capacity is not configurable, and is the default capacity for a LinkedBlockingQueue -
Integer.MAX_VALUE. It is likely that the app would run out of memory before buffering this many events. This capacity will be configurable from version 0.12.0.In the above PR, events that are in the process of being sent are removed from the main event buffer and put into a temporary collection. If the request is successful they're deleted; if not, they should be returned to the event buffer. If the event buffer is now full, there's nowhere for them to go.
Possible solutions are:
We could also complicate things by allowing users to choose a policy for what to do if the network is down and the Emitter is full - as in the Scala tracker.