プッシュ通知のトラブルシューティング

• GCM からの応答が「内部サーバー・エラーです」または「GCM サービスは使用不可です」の場合、通知の再送が試行されます。 試行頻度は、「Retry-After」の値に基づいて決定されます。
• GCM に到達できない場合、エラーは trace.log ファイルに出力され、メッセージは再送されません。
• GCM は到達可能でも、障害を受け取った場合
  • 「登録されていません」/「ID が無効です」/「ID が不一致です」/「登録がありません」は、デバイス ID の使用が無効か、GCM でのアプリケーションの登録が無効であるために発生した可能性があります。 データベースで不整合なデータが発生することを避けるために、デバイス ID がデータベースから削除されます。 通知は再送されません。
  • メッセージが大きすぎる場合、メッセージの送信は再試行されず、ログが trace.log ファイルに記録されます。
  • エラー・コード 401 の場合、認証エラーが原因の可能性があります。メッセージの送信は再試行されず、ログが trace.log ファイルに記録されます。
  • エラー・コード 400 または 403 の場合、メッセージの送信は再試行されず、ログが trace.log ファイルに記録されます。

APNS では、APNS 接続が閉じられた場合に再試行されます。 APNS との接続を確立するために、3 回試行されます。 その他の場合、再試行は行われません。

アプリケーションにサインインするために使用されるプロビジョニング・プロファイルでプッシュ機能が有効になっていることを確認します。 これは、Apple Developer Portal のアプリケーション ID の設定ページで確認できます。

APNS では、MobileFirst Server と APNS サービスの間に永続的ソケット接続が必要です。 プッシュ・サービスはオープンしているソケットがあると想定し、通知を送信しようとします。 しかし、多くの場合、顧客のファイアウォールは、未使用のソケットをクローズするように構成されています (プッシュは頻繁に使用されないことがあります)。 そのような予期しないソケットのクローズはどちらのエンドポイントからも検出できません。これは、通常のソケットのクローズは、一方のエンドポイントからシグナルが送信され、他方のエンドポイントからその確認応答が返されることによって起こるためです。 プッシュ・サービスの発送がクローズされたソケットで試行されると、ログにはソケット例外が表示されます。

これを回避するには、ファイアウォール・ルールで APNS ソケットが確実にクローズされないようにするか、プッシュ・サービスの JNDI プロパティーである push.apns.connectionIdleTimeout を使用します。 このプロパティーを構成することで、サーバーは、指定されたタイムアウト (ソケットのファイアウォール・タイムアウト未満) 内に APNS プッシュ通知に使用されるソケットを正常にクローズします。 このようにして、顧客はファイアウォールによって不意にシャットダウンされる前にソケットをクローズできます。

次に例を示します。

java.net.SocketException: Malformed reply from SOCKS serverat java.net.SocksSocketImpl.readSocksReply(SocksSocketImpl.java

通知は即時に行われることも、遅延することもあります。 遅延は数秒から数分になる場合があります。 以下のようなさまざまな理由を考慮できます。

• MobileFirst Server では、メディエーター・サービスに到達した通知を制御できません。
• デバイスのネットワークまたはオンライン状況 (デバイスのオン/オフ) を考慮する必要があります。
• ファイアウォールまたはプロキシーが使用されているかどうかを確認し、使用されている場合は、メディエーターへの (およびメディエーターからの) 通信をブロックするように構成されていないことを確認してください。
• 実際のメディエーター URL を使用する代わりに、GCM/APNS/WNS メディエーターについて IP をファイアウォールで選択的にホワイトリスト指定しないでください。 メディエーター URL は任意の IP に解決されることがあるため、これによって問題が発生する可能性があります。 顧客は、IP ではなく URL へのアクセスを許可する必要があります。 メディエーター URL に telnet することでメディエーター接続が確保されるようにしても、必ずしもすべてが解決するわけではないことに注意してください。 特に iOS では、これはアウトバウンド接続を証明するだけです。 実際の送信は TCP ソケット経由で行われ、telnet では保証されません。 特定の IP アドレスのみを許可することで、例えば GCM では、以下のことが発生する可能性があります。

  Caused by: java.net.UnknownHostException:android.googleapis.com:android.googleapis.com: Name or service not known.

Apple の QoS は、合体通知と呼ばれるものを定義します。 これは、APNS サーバーが (トークンによって識別された) デバイスに通知を即時に配信できない場合に、サーバーで 1 つの通知のみを維持することを意味します。 例えば、5 つの通知が次々に発送された場合について考えます。 デバイスが不安定なネットワーク上にあり、最初の通知が配信され、2 番目の通知が APNS サーバーによって一時的に保管されたとします。 それまでに、3 番目の通知が発送され、APNS サーバーに到達します。 すると、古い (配信されていない) 2 番目の通知は破棄され、3 番目 (最後の通知) は保管されます。 エンド・ユーザーには、これは欠落している通知として現れます。

... アプリケーションが実行中ではない場合、またはアプリケーションがバックグラウンドにある場合、通知の陰影で通知をタップしてもアプリケーションは起動しません。 これは、strings.xml ファイルの app_name フィールドがカスタム名に変更されたために発生した可能性があります。 これにより、アプリケーション名と、AndroidManifest.xml ファイルで定義された意図したアクションが一致しなくなります。 アプリケーションに別の名前が必要な場合、app_label フィールドを代わりに使用するか、strings.xml ファイルでカスタム定義を使用する必要があります。

次に例を示します。

ApnsConnection | com.ibm.mfp.push.server.notification.apns.Apns.Connectionlmpl sendMessage Failed to send message Message (Id=1; Token=xxxx; Payload={"payload":{"\nid\":\"44b7f47\",\"tag\":\"Push.ALL\"}", "aps":{"alert":{"action-loc-key":null,"body":"TEST"}}})... trying again after delay javax.net.ssl.SSLHandshakeException:Received fatal alert: handshake_failure

この問題は、IBM JDK 1.8 JVM の使用時にのみ検出されます。 解決方法は、IBM JDK 1.8 をバージョン 8.0.3.11 以降にアップグレードすることです。

デプロイされている .war ファイルと、mfp.admin.push.url、mfp.push.authorization.server.url、および secret の各プロパティーが server.xml ファイルで正しく構成されている場合でも、プッシュ・サービスが非アクティブと表示されます。

MFP 管理サービスに対してサーバーの JNDI プロパティーが正しく設定されていることを確認してください。 これには、例えば以下のものが含まれている必要があります。

<jndiEntry jndiName="mfpadmin/mfp.admin.push.url" value='"http://localhost:9080/imfpush"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.server.url" value='"http://localhost:9080/mfp"'/>
<jndiEntry jndiName="mfpadmin/mfp.push.authorization.client.id" value='"push-client-id"'/>
<jndiEntry jndiName="mfpadmin/mfp.push.authorization.client.secret" value='"pushSecret"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.client.id" value='"admin-client-id"'/>
<jndiEntry jndiName="mfpadmin/mfp.admin.authorization.client.secret" value='"adminSecret"'/>
<jndiEntry jndiName="mfpadmin/mfp.config.service.password" value='"{xor}DCs+LStubWw="'/>
<jndiEntry jndiName="mfpadmin/mfp.config.service.user" value='"configUser"'/>