Occasional javax.net.ssl.SSLException: handshake timed out when connecting

[Mark]

I'm seeing SSL handshake timeouts sometimes when trying to connect to the dev gateway (i.e apnsClient.connect(ApnsClient.DEVELOPMENT_APNS_HOST)).

I'm only using a single ApnsClient instance. I try to connect once and maintain that connection. I have two hosts that I use for development, i.e. use the same dev push cert (a Mac, and Linux box). Either platform can work fine or have connection problems. However, once I get a connection failure, it's persistent for many hours.

It appears that Apple is upset that I switch between the two hosts, but I'm not completely certain it's down to that. I can run the server and restart/reconnect on one host just fine for hours/days. However, if run the server on the other host (even if I kill it on the first one), I may get the handshake time out. I can try reconnecting over an hour later, and I still can't connect. However, on one occasion, I was able to reconnect successfully the next day (say 12+ hours later) with the same code/jar – I changed nothing. I've only had one chance to observe this thus far.

I assume Apple thinks I'm some sort of bad guy (DDOS) and has instituted some more aggressive countermeasures with the new HTTP/2 gateway than they've used in the past. With the old gateway, I was able to run on both servers with the same dev push cert simultaneously and things worked fine (at least as far as I knew, right?).

I could spend days off in the weeds on this. It's particularly difficult because there aren't good HTTP/2 debugging tools yet (e.g. Charles doesn't do HTTP/2 yet). So, I'm hoping someone has some ideas?

1. Does anyone see similar behavior? Is it me? Netty? Apple?

2. My stack trace seems pretty useless, even running with javax.net.debug=all and log level debug. All I get is some pretty routine io.netty log messages (nothing looks suspicous, but can post if warranted) and then "javax.net.ssl.SSLException: handshake timed out". Can anyone suggest some debugging flags/properties/measures to get some better diagnostics? 

3. If my suspicions about Apple are not unfounded, does anyone know the new "rules" or if they might be documented somewhere? Their push notification troubleshooting doc is woefully out of date.

Thanks, folks...

[Jon Chambers]

Sadly, it seems like this is just A Thing™ that's affecting lots of users in the sandbox environment. We suspect it's an upstream issue; we've been encouraging users affected by this issue to file a bug report with Apple (https://bugreport.apple.com/). I think the stack trace may be a little opaque because "handshake timed out" is, in fact, exactly what happened. At this time, we don't have any reason to believe this is a symptom of rate limiting or DDoS defense.

Hope that helps!

-Jon

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark]

Thanks, Jon. Well, it's good to know I'm not alone, but this is going to be frustrating (and slow development tremendously). I guess this means you're not hearing of the same problems for the production gateway. That's good news at least.

Sorry, I just found Push #295. Thought I'd searched closed issues. I'll try to file a bug later tonight. Based on that dev forum thread, it may be a bad server in the DNS pool. Never fails to amaze me how long it takes Apple to fix something like this – for developers at least.

[Mark]

Radar filed: 26311870