pushok
pushok copied to clipboard
edamov
HTTP/2 stream was not closed cleanly: REFUSED STREAM
This just started happening a couple of days ago. httpd log entry in the error_log:
PHP Fatal error: Uncaught Exception: HTTP/2 stream 99347 was not closed cleanly: REFUSED_STREAM (err 7) in /var/www/html/pushok/vendor/edamov/pushok/src/Client.php:153\nStack trace:\n#0 /var/www/html/push/push-pushmessage.php(301): Pushok\Client->push()\n#1 {main}\n thrown in /var/www/html/pushok/vendor/edamov/pushok/src/Client.php on line 153
Most pushes seem to go through (sending around ~50k w/ concurrency @ 40 and concurrent connections @ 5. But when I go to loop through my responses from APNS, nothing happens because the script fails on that client connection.
Thoughts??
I haven't been able to test this theory specifically (I'm not going to hammer thousands of real devices with spammy messages), but it seems like there's some sort of upper limit per-client connection. That number appears to be ~50,000.
What I've done in my code is break my messages up into batches of 10,000. Each batch initiates a client connection, adds the 10,000 tokens to the notifications array, then attaches that to the client object, and finally pushes, then closes the connection. 10,000 more at a time until the end. So far, I'm not getting that error.
Just odd that this has come about all of a sudden. Likely nothing library-based (as nothing has changed), and more likely Apple has gotten more strict, without publishing any changelogs.
Thank you for the clarification! I am pleasantly surprised that you send such a big amount of notifications using this library
Well, I really appreciate you creating and maintaining this lib, so thank YOU! I feel like the APNS communication was "solved" years ago and nobody bothers to keep things up to do (live activities, etc), and then when you narrow it down to a specific language (in this case PHP), it makes that needle even tougher to thread.
Happy to chat with you offline about my use case. But overall, yes, I push >50k at a time, and over the course of some evenings, >1M+. :) Your library is fantastic. My skills are just above "hack" so I appreciate folks like yourself who can put out production, consumable and customizable code like this. Thanks again.
We're still experiencing the same issue, even after reducing the subscriber count to 5,000 per batch.
@yetdog did you ever manage to fix this?
Sorry I haven't replied yet. My batch jobs seemed to fix it, yes. But bummed to hear @omitech is still having the issue. I would have to assume something on Apple's end changed and wasn't documented?
The problem is that it is not reproducible; sometimes it works, sometimes it does not. It looks like an issue on Apple's end, rather than with the library.
I'm using curl 7.86.0
we also use this library and occasionally hit the same issue. The amount of push notifications varies - the last time this happened we only sent to just over 1500 subs.
Has anyone attempted to reduce "maximum concurrent streams" with custom curl options and get success?
