工作灯推送通知（APNS）失败，javax.net.ssl​​.SSLHandshakeException [英] Worklight Push notification (APNS) fails with javax.net.ssl.SSLHandshakeException

问题描述

我在iOS上一个工作灯6.1应用程序使用推送通知。它工作正常，直到不顺心的事的工作灯服务器上。之后所有推送通知的失败，直到重新启动服务器。

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.

该工作灯服务器是自由8.5.5.0在Linux上的x86_64
使用JDK：Java的1.7.0-IBM-1.7.0.5.0.x86_64
该工作灯数据库是德比（这是一个测试服务器）

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.

根本的问题是，工作灯服务器托管于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分钟，并且在防火墙丢弃的工作灯服务器和APNS服务器之间的插座。所有后续的推送请求，因为工作灯曾经为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.

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