High CPU usage when using sandbox certificate in production environment about pushy HOT 6 CLOSED

Hello,
After having a second look, it looks like the high CPU had nothing to do with netty ( even though it could have on an older version of java ) , it was something rather silly . The scenario that caused the high CPU usage is the following :
A valid development certificate was used on production apns
the SSL handshake gets completed, still APNS closes the connection immediately ( because the certificate is not a production certificate)
pushy goes into an infinite loop reconnecting thinking that the certificate is valid and the connection just got closed causing high CPU usage.

from pushy.

A valid development certificate was used on production apns

Ah -- yes. We actually just ran into this issue on the mailing list. I'll look into it a bit, but I'm not sure there's a whole lot we can do other than document the issue. I'm curious as to whether the gateway is sending an actual error code before closing the connection, though.

Thanks for following up!

from pushy.

…also, I updated the summary of this issue to more accurately reflect the problem.

from pushy.

Maybe one thing you could do if the gateway isn't sending an error code is to validate the certificate before you open a connection. The developer certificate 's subject contains "CN=Apple Development IOS Push Services" , and the production certificate's subject contains "CN=Apple Production IOS Push Services" .

Thanks.

from pushy.

True, but I was surprised to learn today that there doesn't seem to be a good way to get a KeyStore back out of an SSLContext after it's gone in. Any suggestions from the audience?

If we can't get a KeyManager out of an SSLContext, we'd have to really rethink how the PushManagerFactory works, and I'm not sure any of the designs I've been able to think of so far would make sense. There's still some danger that the best we can do is to document the issue in a FAQ somewhere.

from pushy.

I added this to our FAQ for now. If this turns into a bigger problem in the future, we'll consider more significant architectural changes to address it.

Thanks for calling it to our attention!

from pushy.