12

When using the Google Cloud Messaging API to send messages between a backend server and an Android/Chrome client, the backend server can, at times, receive a rate limit exceeded response code. This code is “DeviceMessageRateExceeded” for a HTTP Connection Server and “DEVICE_MESSAGE_RATE_EXCEEDED” for a Cloud Connection Server.

What is this error code and how should it be managed?

PaulR
  • 3,223
  • 1
  • 21
  • 32

2 Answers2

13

The rate limit exception code indicates that you are sending messages from a backend server too frequently. To ensure a stable service, there is a per minute / per device app upper limit on the number of messages that can be sent from a backend server. This limit is set high so most well behaving apps should not be affected, all apps should however be prepared to receive this error code.

As specified in the question, in the case of an HTTP Connection Server, the error code will be “DeviceMessageRateExceeded”. And for a Cloud Connection Server, it will be “DEVICE_MESSAGE_RATE_EXCEEDED”, which is replacing the previous error code “QUOTA_EXCEEDED”.

If your backend server receives this error code, it must slow down the rate it sends messages to the client, ideally by implementing exponential backoff.

PaulR
  • 3,223
  • 1
  • 21
  • 32
  • Is the downstream ack accounted for in the quota? How do I know the time in which I'll be able to send downstream messages again? – doplumi Jan 18 '15 at 11:55
  • You won't know exactly when you will be able to send messages again, but you should use exponential backoff at the system level as you try to resubmit. – PaulR Jan 20 '15 at 16:53
  • If we already do exponential backoff and respect Retry-After for 5xx error codes should that be sufficient? – James Wheare Jan 20 '15 at 17:37
  • Also, what error code number is returned for HTTP DeviceMessageRateExceeded errors? – James Wheare Jan 20 '15 at 17:59
8

CCS downstream ack is not accounted in the quota.

The DeviceMessageRateExceeded quota is hit when you send too many messages to a single device - you don't need to backoff all sending, just to that registration ID. Please make sure you handle "Canonical" registration ID response - it is possible to have multiple regids pointing to the same device.

The 'quota_exceeded' was used in C2DM - GCM doesn't currently return it. If anyone is still using C2DM - the handling is to throttle/backoff sending for all messages. Or even better - to migrate to GCM which doesn't have this global quota.