After merging PR #1216 , we saw IO exceptions when the android sender lambda sent notifications to a relatively larger group of device (more than several hundreds).
We used the same HttpClient instance for the processing of all SQS messages within an invocation of a lambda, and it appears that the HttpClient sent the requests over the same connection via HTTP/2. In larger notifications, it hit the limit on the maximum of concurrent stream over a connection.
This PR attempts to fix the problem by creating a HttpClient instance for the processing of each SQS message. Within each SQS message, there is a setting on concurrency level which specifies how many device token to send concurrently. This approach helps us to control the maximum number of concurrent stream we open when sending requests to Firebase API.
How to test
We tested locally and confirmed that we created as many HttpClient instances as the messages we are processing.
We also deployed to CODE, tested a notification and we were able to receive it on our Android emulator.
All deployment options
- [Deploy build 4352 of `mobile-n10n:notificationworkerlambda` to CODE](https://riffraff.gutools.co.uk/deployment/deployAgain?project=mobile-n10n%3Anotificationworkerlambda&build=4352&stage=CODE&updateStrategy=MostlyHarmless&action=deploy)
- [Deploy parts of build 4352 to CODE by previewing it first](https://riffraff.gutools.co.uk/preview/yaml?project=mobile-n10n%3Anotificationworkerlambda&build=4352&stage=CODE&updateStrategy=MostlyHarmless)
- [What's on CODE right now?](https://riffraff.gutools.co.uk/deployment/history?projectName=mobile-n10n%3Anotificationworkerlambda&stage=CODE)
I paired with @aracho1 on this piece of work.
What does this change?
After merging PR #1216 , we saw IO exceptions when the android sender lambda sent notifications to a relatively larger group of device (more than several hundreds).
We used the same
HttpClient
instance for the processing of all SQS messages within an invocation of a lambda, and it appears that theHttpClient
sent the requests over the same connection via HTTP/2. In larger notifications, it hit the limit on the maximum of concurrent stream over a connection.This PR attempts to fix the problem by creating a
HttpClient
instance for the processing of each SQS message. Within each SQS message, there is a setting on concurrency level which specifies how many device token to send concurrently. This approach helps us to control the maximum number of concurrent stream we open when sending requests to Firebase API.How to test
We tested locally and confirmed that we created as many
HttpClient
instances as the messages we are processing.We also deployed to
CODE
, tested a notification and we were able to receive it on our Android emulator.