send() can hang due to http2 client.request() apparently having no timeout about node-apn HOT 10 CLOSED

I will setup a test tomorrow.

from node-apn.

I can confirme our worker is in the air doing nothing.

All the "write" part is a bit messy, maybe check to https://github.com/AndrewBarba/apns2/blob/master/lib/http2-client.js as a replacement of client.js. To me it appears cleaner ;)

(Despite session.setTimeout steel missing)

from node-apn.

@petitchevalroux Refer to https://github.com/AndrewBarba/apns2/issues/33 - there's quite a few unaddressed review comments, and that file does call setTimeout but seems like it introduce different potential failure modes (e.g. it can be establishing multiple connections to APNs concurrently in connect(), but only use one).

You may be interested in #27 - A few unit tests of failure modes were added but I haven't tested this against the real apns servers for a prolonged period of time yet.

from node-apn.

No I haven't seen this problem but it's a great find, @trevh3 comments sound interesting.
I dove into http2 for the first time yesterday so I don't understand all. We will check #27 and potentially test its behavior next week.

At the moment we are not sure that timeout is the real problem. But from my first client.js read and this issue it's my first guess We enabled debug mode in production to see if we can have more information on the "worker in the air" effect.

Thanks for your feedback ;)

from node-apn.

I also do not understand why the problem is back now - and we have it really often. We actually have implemented an own watchdog .... waiting 10 sec and then creates a new APN Provider and continues. But we are sending packages with 100 receivers and I do not know which of them have received the notification and which not.
We will try now the new version but I think only the timeout will not solve the problem. We are already checking for others ways to send - with curl or whatever.
The version worked over month - but now it happens nearly on every message.

btw.
I posted in parse forum ( https://community.parseplatform.org/t/node-apn-problem-send-hangs/871/5 ) but cool that now issues is enabled here.

from node-apn.

We actually have implemented an own watchdog .... waiting 10 sec and then creates a new APN Provider and continues. But we are sending packages with 100 receivers and I do not know which of them have received the notification and which not.

@trx222 frequently opening and closing connections to APNs may make the problem worse - APNs may treat frequently opening and closing connections as a malfunctioning client or a denial of service and block connections from your IP address. (I forget where I read that.)

from node-apn.

You saw it in Apple's APNS documentation

Keep your connections with APNs open across multiple notifications; do not repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day, it is acceptable practice to use a new connection each day.

from node-apn.

Yes sure - I know this part and we only do a limited number of retrys ( 3 to 5 times ) and then we give up ... But what else should I do - I cannot completly stop sending in that case. We anyways have 30 parallel processes for sending to speed up everything - otherwise it takes to long for transmitting everything.

But The problem also happens if we have just 300 receivers sending in one process ... it makes no difference.

from node-apn.

Guys, could try with this branch? #29

It looks working better for me in my tests, but it would be good to have more feedback before merging.

from node-apn.

I think this can be closed now with the release of 4.0.0?

from node-apn.