> > I think we need to close on how we want to deal with failures, see mail > thread [3]. Currently, the spec doesn’t go into the expected details on > what to do if the beacon has failed to be sent or received for whatever > reason. I personally rather we keep this behavior as implementation details > and let the quality of implementation determine how often it will retry. > However, it may make sense to put in some recommendations in the spec so we > have interoperability. As Luke mentions, if one UA always sends the > analytics by aggressively retrying but another doesn’t, the analytics data > may be skewed, which may hurt the adoption of this method. > I think there should be some way for beacons to give some flow control hints, ie a 503 status code with an optional "Retry-After" header that should be honored by the UA. The UA may need to drop the data if it can't hold on to it for that long, but oh well. I can imagine scenarios where a beacon service goes down but load balancers stand in and send out 503s to give the beacon service some time to come back up. Some data may be lost, but hopefully much of the data could still come through on later retrys. Perhaps this could also be a mechanism to ensure that UAs aren't too aggresive in retries. If you know you won't be back up for 5 minutes, then just tell UAs to wait that long.
Received on Thursday, 7 November 2013 00:24:36 UTC