【问题标题】:APNS through socket on GCE stops working after a few hours几个小时后,通过 GCE 上的套接字的 APNS 停止工作
【发布时间】:2017-05-07 12:41:40
【问题描述】:

这是我从 Heroku 迁移到 Google Container Engine 后开始面临的一个有趣问题:

自从迁移到 GCE 后,在服务器启动/重新启动/部署几个小时后,我的 Elixir 应用程序无法再向 APNS 发送推送通知。我正在使用apns4ex 库。以下是我目前发现的大致内容:

在 init 内部,库打开一个到 APNS 的 :ssl (erlang) 套接字,并在 GenServer 进程中不断回收它

def connect_socket(host, port, opts, timeout_seconds) do
    address = "#{host}:#{port}"

    case :ssl.connect(host, port, opts, timeout_seconds * 1000) do
      {:ok, socket} ->
        APNS.Logger.debug("successfully connected to #{address}")
        {:ok, socket}
      {:error, reason} ->
        APNS.Logger.error("failed to connect to push socket #{address}, reason given: #{inspect(reason)}")
        {:error, {:connection_failed, address}}
    end
end

现在,从 x 小时开始,在尝试发送消息后,库开始接收 :ssl_closed 消息/回调,以指示 SSL 连接已关闭

def handle_info({:ssl_closed, socket}, %{socket_apple: socket} = state) do
  APNS.Logger.debug("ssl socket closed, returning :connect")
  {:connect, {:error, "ssl_closed"}, %{state | socket_apple: nil}}
end

它的处理方式是让我们关闭连接并返回:connect,然后它将重新连接到APNS(here

一旦推送通知停止工作,调试日志总是会在每条消息上报告以下模式。

  1. 尝试发送消息
  2. 报告“发送成功”(没有任何内容发送到手机。此消息是由:ssl.send 报告:ok 引起的)
  3. 然后收到一个 ssl 套接字关闭消息
  4. 重新连接到 gateway.push.apple.com(:ssl.connect 返回:ok
  5. 重复

send_package代码:

def send_package(socket, packet) do
  result = :ssl.send(socket, [packet])

  case result do
    :ok ->
      APNS.Logger.debug("success sending ssl package")
    {:error, reason} ->
      APNS.Logger.warn("error #{reason} sending ssl package")
  end

  result
end

相比之下,成功发送后它会在第 2 点停止。

这是发送推送时我的应用程序的一些原始日志输出(注意最后 9 行显示了我描述的模式)

01:41:14.820 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending in poolboy transaction :myapp
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 23303051:1ad798 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending in poolboy transaction :myapp
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handling cast :send
01:41:14.821 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 message's payload looks good
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 62064556:b12e98 sending message
01:41:14.821 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending in poolboy transaction :myapp
01:41:14.822 [debug] [APNS] #PID<0.349.0> success sending ssl package
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 success sending
01:41:14.822 [debug] [APNS] #PID<0.349.0> 23303051:1ad798 handle call :send received :ok
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handling cast :send
01:41:14.822 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 message's payload looks good
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [debug] [APNS] #PID<0.20135.97> 19048099:b3ed8e sending message
01:41:14.823 request_id=fecds3h3s1so2825c44qfestvvvpv707 [info] Sent 200 in 22ms
01:41:14.823 [debug] [APNS] #PID<0.348.0> success sending ssl package
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 success sending
01:41:14.823 [debug] [APNS] #PID<0.348.0> 62064556:b12e98 handle call :send received :ok
01:41:14.823 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handling cast :send
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e message's payload looks good
01:41:14.824 [debug] [APNS] #PID<0.347.0> success sending ssl package
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e success sending
01:41:14.824 [debug] [APNS] #PID<0.347.0> 19048099:b3ed8e handle call :send received :ok
01:41:15.027 [debug] [APNS] #PID<0.348.0> ssl socket closed, returning :connect
01:41:15.029 [debug] [APNS] #PID<0.347.0> ssl socket closed, returning :connect
01:41:15.043 [debug] [APNS] #PID<0.349.0> ssl socket closed, returning :connect
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to gateway.push.apple.com:2195
01:41:15.207 [debug] [APNS] #PID<0.348.0> successfully connected to socket
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to gateway.push.apple.com:2195
01:41:15.209 [debug] [APNS] #PID<0.347.0> successfully connected to socket
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to gateway.push.apple.com:2195
01:41:15.214 [debug] [APNS] #PID<0.349.0> successfully connected to socket

一种理论是 GCE 正在关闭空闲连接,但这并不能解释为什么重新连接后的另一条消息立即导致相同的模式。另外为什么套接字只有在使用:ssl.send 发送后才会关闭?

【问题讨论】:

    标签: ssl erlang apple-push-notifications elixir google-compute-engine


    【解决方案1】:

    我对 apns4erl 也有同样的问题,当套接字在尝试发送消息后关闭时,但问题出在我这边,不记得了,要么是在错误的证书文件中,要么是格式错误的消息

    【讨论】:

    • 有趣。你有更多关于你的情况的信息吗?我认为这不是证书,因为消息首先运行良好。
    • 旧代码带有过期的证书和代码中形成的有效负载,Packet = >, ssl:send(Socket,包)。切换到 apns4erl,我得到了格式错误的有效负载(因为 #apns_msg{} 中的数据类型),并且当打开套接字但消息不是激流回旋时出现类似的问题
    猜你喜欢
    • 2014-09-23
    • 2018-12-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-09-30
    • 2012-12-20
    • 2018-02-20
    相关资源
    最近更新 更多