If you ask the service to send too many notifications in a quick succession it sends infinite notifications
Pretty sure this is not my code doing this.
If you ask the service to send like 50 notifications in quick succession it repeatedly sends the same batch of notifications forever.
I have seen this happen twice now.
This is deployed to AWS on a fairly constrained Ubuntu server.
My send is within a router callback for PerfectHTTPServer, there is no loop in my code and I am logging when the callback happens, it only happens once. So unless Apple are doing this it does seem to be within PerfectNotifications or one of its dependencies.
However notably the callback is called like 50 times in rapid succession. separate instantiations on different threads. Possibly a concurrency violation?
Thank you for opening the issue. I just wanted to let you know that I'm digging into this one today and will report back ASAP.
Great thanks x. When I said callback only called once I meant it’s called like 50 times, but I expected 50, after that the notifications keep getting resent until I kill the server.
The recent commit fixes this, though an awful lot of notifications seem to get dropped instead, with a lot of internalServerError errors and ~HTTP2Client.startReadThread messages.
So thanks, I'll look into whether or not I can help fix that.
APNs: 500 Internal Server Error: Connection dropped 90a6<snip>
APNs: 500 Internal Server Error: Connection dropped bcee82<snip>
I get 20 or so of that. Followed by 40 or so HTTP2Client.startReadThread.
So I guess too many connections to APNs are being opened, I'm going to investigate.
Actually maybe not 100% fixed, looking at my notifications log some were doubled up. But it does stop now at least rather than sending them until I kill the server.
Yeah ok, this seems to possibly be the issue, I put a print counter into the code when HTTP2 streams are created and when I use my test case I get up to 66 open connections to APNs.
A google suggests 15 is the undocumented limit per IP that Apple allow before they start closing the connections.
Also my reading suggests that we are preemptively creating new streams, Apple say you should be able to do 9000 payload writes per second to one connection, I'm just trying to write 66 here within a few seconds.
Anyway, if there's any feedback I can take it into account as I attempt to fix this. Thanks.