Worklight 推送通知 (APNS) 因 javax.net.ssl.SSLHandshakeException 而失败 [英] Worklight Push notification (APNS) fails with javax.net.ssl.SSLHandshakeException

问题描述

我在 iOS 上有一个带有推送通知的 Worklight 6.1 应用程序.它工作正常，直到 Worklight 服务器出现问题.之后的所有推送通知都会失败，直到服务器重新启动.

I have a Worklight 6.1 app on iOS with push notifications. It works fine, until something goes wrong on the Worklight server. All push notifications after that fail until the server is restarted.

Worklight 服务器是 Linux x86_64 上的 Liberty 8.5.5.0使用 JDK:java-1.7.0-ibm-1.7.0.5.0.x86_64Worklight 数据库是 Derby(这是一个测试服务器)

The Worklight server is Liberty 8.5.5.0 on Linux x86_64 Using JDK : java-1.7.0-ibm-1.7.0.5.0.x86_64 The Worklight database is Derby (this is a test server)

当我启动服务器时一切正常.

Everything works great when I start the server.

服务器启动10分钟后，我看到:

10 minutes after the server starts, I see:

[2/20/14 19:39:15:319 CST] 0000003e com.notnoop.apns.internal.ApnsFeedbackConnection             W Failed to retreive invalid devices
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: End user tried to act as a CA

但这似乎并没有破坏任何东西.推送通知仍然有效.服务器启动 30 分钟后，我看到:

But that doesn't seem to break anything. Push notifications still work. 30 minutes after server start, I see:

[2/20/14 19:59:48:657 CST] 00000061 com.ibm.ws.webcontainer.util.ApplicationErrorUtils           E SRVE0777E: Exception thrown by application class 'org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException:365'
org.jboss.resteasy.spi.UnhandledException: org.springframework.dao.InvalidDataAccessApiUsageException: Multiple DISTINCT aggregates are not supported at this time. {SELECT COUNT(DISTINCT t0.DEVICE), COUNT(DISTINCT t1.ID) FROM NOTIFICATION_DEVICE t0 INNER JOIN NOTIFICATION_USER t1 ON t0.USERSUBSCRIPTIONID = t1.ID WHERE (t0.APPLICATIONID IN (?) AND t0.PLATFORM = ?)} [code=30000, state=42Z02]; nested exception is <openjpa-1.2.2-r422266:898935 nonfatal user error> org.apache.openjpa.persistence.ArgumentException: Multiple DISTINCT aggregates are not supported at this time. {SELECT COUNT(DISTINCT t0.DEVICE), COUNT(DISTINCT t1.ID) FROM NOTIFICATION_DEVICE t0 INNER JOIN NOTIFICATION_USER t1 ON t0.USERSUBSCRIPTIONID = t1.ID WHERE (t0.APPLICATIONID IN (?) AND t0.PLATFORM = ?)} [code=30000, state=42Z02]

之后对推送适配器的任何调用都会导致:

And any call to the push adapter after that results in:

[2/21/14 19:06:44:038 CST] 00000090 com.notnoop.apns.internal.ApnsConnectionImpl                 I Exception while waiting for error code
java.net.SocketException: Socket is closed
    at com.ibm.jsse2.qc.j(qc.java:301)
    at com.ibm.jsse2.e.read(e.java:32)
    at java.io.InputStream.read(InputStream.java:102)
    at com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114)

[2/21/14 19:06:44:650 CST] 00000085 com.notnoop.apns.internal.ApnsConnectionImpl                 I Failed to send message Message(Id=2; Token=499D9813FBC377CCDE787E2749CDA914F826EDF39B0830D4AFEEF7A5D71A1802; Payload={"aps":{"alert":{"body":"You have 4 available messages","action-loc-key":null},"sound":"","badge":4},"payload":"{\"alias\":\"myNotificationPush\"}"})... trying again after delay
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: End user tried to act as a CA

之后的所有重试都会导致同样的失败.

And all the retries after that result in the same failure.

有一些关于最终用户试图充当 CA"和APNS"的谷歌点击表明这是 JDK 1.5 问题(在 1.6 中修复)，并且可以使用 IbmPKIX 信任管理器修复它，但我确定我使用的是 JDK 1.7，并且 java.security 中的信任管理器是 PKIX

There are some google hits on "End user tried to act as a CA" and "APNS" that suggest this is a JDK 1.5 problem (fixed in 1.6), and that it can be fixed by using the IbmPKIX trust manager, but I am certain that I am using JDK 1.7, and the trust manager in java.security is PKIX

推荐答案

再一次……这花了很长时间才弄明白.

Once again … this took long enough to figure out.

潜在的问题是 Worklight 服务器托管在 SoftLayer 上，显然 SoftLayer 防火墙默认监视套接字连接，如果连接空闲约 10 分钟，则将其丢弃.

The underlying problem was that the Worklight server was hosted on SoftLayer, and evidently the SoftLayer firewall by default monitors socket connections, and if a connection is idle for ~10 minutes, drops it.

因此，工作灯服务器连接到 APN 并推送工作.然后 10 分钟过去了，没有任何推送通知，防火墙丢弃了 Worklight 服务器和 APNS 服务器之间的套接字.所有后续推送请求都以静默方式失败，因为 Worklight 有一个用于 APNS 服务的死套接字.

So, the worklight server connected to APN and push worked. Then 10 minutes passed without any push notifications, and the firewall dropped the socket between the Worklight server and the APNS server. All subsequent push requests failed silently because Worklight had a dead socket for the APNS service.

我们重新配置了防火墙，允许与 APNS 的连接无限期闲置，问题得到解决.

We reconfigured the firewall to allow the connection to APNS to sit idle indefinitely and the problem was resolved.

这篇关于Worklight 推送通知 (APNS) 因 javax.net.ssl.SSLHandshakeException 而失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！