問題タブ [bayeux]

複数のエンドポイントが同じパスに展開されない可能性があるという有望な答えは見つかりませんでしたが、いくつかのスタックオーバーフローとGoogleグループのcometd関連トピックを精査しました。

Cometd バージョン: 3.0.5 Tomcat バージョン: 7.0.55

Spring 統合のために、BayeuxServer インスタンスは次のように作成されます。

例: https://github.com/cometd/cometd/blob/master/cometd-java/cometd-java-oort/src/test/java/org/cometd/oort/spring/OortConfigurator.java

このセットアップ中に、cometd と tomcat の両方が、エラー ログに示されているように、同じパスにエンド ポイントを追加しようとしました。

原因: java.lang.RuntimeException: javax.websocket.DeploymentException: Multiple Endpoints may not be deployed to the same path [/cometd] at org.cometd.websocket.server.WebSocketTransport .init(WebSocketTransport.java:93)

2015 年 7 月 30 日 4:35:02 PM org.apache.catalina.core.StandardWrapperValve 呼び出し SEVERE: サーブレット cometd javax.websocket.DeploymentException の割り当て例外: 複数のエンドポイントが組織の同じパス [/cometd] にデプロイされていない可能性があります。 apache.tomcat.websocket.server.WsServerContainer.addEndpoint (WsServerContainer.java:207)

cometd が tomcat でうまく動作しないことは理解しています。Tomcat が cometd によって作成されたのと同じエンドポイントを追加できないようにすることはできますか? アプリケーションを Tomcat にデプロイする必要があります。

Bayeux プロトコルを理解しようとしています。bayeux クライアントが技術的にどのように機能するかを詳細に説明している Web リソースは見つかりませんでした。

このリソースから、

Bayeux プロトコルでは、新しいクライアントが送信する最初のメッセージがハンドシェイク メッセージ (/meta/handshake チャネルで送信されるメッセージ) である必要があります。

クライアントはハンドシェイク応答を処理し、それが成功した場合は、接続メッセージ (/meta/connect チャネルで送信されるメッセージ) を交換することにより、サーバーとのハートビート メカニズムを内部で開始します。

このハートビート メカニズムの詳細は、使用されるクライアント トランスポートによって異なりますが、クライアントが接続メッセージを送信し、しばらくしてから応答を期待しているように見えます。

接続メッセージは、いずれかの側が切断メッセージ (/meta/disconnect チャネルで送信されるメッセージ) を送信して切断することを決定するまで、クライアントとサーバーの間を流れ続けます。

最初にハンドシェイクを行い、次に特定のチャネルをサブスクライブする Java メソッドを記述しました。HTTP POST リクエストを実行するために、Apache HttpClient ライブラリを利用しました。

次に接続の部分です。

私の理解では、バイユーサーバーに対してリクエストを開いたままにし、応答を受け取るたびに別のリクエストを行う必要があるということです。

私は以下のコードを書いています。私の理解は正しいですか?このバイユー クライアントは正しい接続機能を示しますか? (欠落している切断、登録解除メソッドは無視してください)

また、bayeux サーバーに対してコードをテストしたところ、正しく動作しました。

チャット機能を実装している Android アプリケーションに取り組んでいます。Cometd を使用しているため、チャットは非常に高速ですが、何らかの理由で Cometd が代替メッセージを送信しています。メッセージ 1 を送信する場合、メッセージ 2 を送信せず、メッセージ 3 を送信する、というように続きます。これは非常に奇妙な動作であり、エラーがないため問題を特定するのは困難です。

システム ログを追加して、onClick メソッドが呼び出されているかどうか、およびメッセージを送信する内部のループを確認しました。また、サーバー側のコードに system.out を追加したところ、代替メッセージのみが受信されます。これにより、Cometd が何らかの理由ですべての代替メッセージを送信していないという結論に至りました。どんな助けでもいいでしょう。ありがとうございました。

PUSH サービスは、ConsoleChatClient.java でインスタンス化された Cometd によって提供されることに注意してください。

コード :

ConsoleChatClient :

カウンター付きコード: 0 で初期化されたカウンター。

カウンターのサーバー側印刷:

Android のログ:

サーバー側のログ:

ログ画像:

取得

したがって、私の最初の推測は、承認ヘッダーを追加することです。どうやってやるの？Jetty 9 は、サーバーとクライアントの両方のコード ライブラリに使用されます。

WebSockets、Bayeux プロトコル、またはロング ポーリング技術などを一般的に、AWS Lambda をトリガーするイベントのソースとして使用できる可能性はありますか? (EC2 ベースのリスナーを実装せずに)

クライアントとして機能するアプリケーションは、cometd を使用して未承諾の通知をクライアントに配信する外部システムにサブスクライブする必要があります。cometd ライブラリなしでこれを達成する方法はありますか (たとえば、apache HttpClient を介して)? Java バージョンの不一致が問題です。私たちは 1.6 を使用していますが、cometd には 1.7 以降が必要です。

前もって感謝します

記事http://www.cometdaily.com/2008/05/15/the-many-shades-of-bayeuxcometd-2/index.htmlで、著者は次のように説明しています。

多くの場合、PubSub では、開発者はプライベート メッセージをクライアントに配信するために、ユーザーごとにチャネルを作成する必要があると感じています。たとえば、取引システムが完了した取引をユーザーに通知したい場合、/trades/a_user_id のようなチャネルを作成して、各ユーザーが自分のチャネルにサブスクライブするようにします。このアプローチは機能しますが、この問題を解決する最もリソースに配慮した方法ではなく、権限のないクライアントが他のユーザー チャネルにサブスクライブするのを防ぐためにセキュリティ コードが必要です。

特定のユーザー向けのメッセージを実装するために、サービス チャネルとブロードキャスト チャネルの間のトレードオフは何ですか? トレードオフのセキュリティ面は理解していますが、リソースのオーバーヘッドはどうですか? カスタム ルーティング サービスよりも多くのリソースがブロードキャスト チャネルで使用される理由がわかりません。賢明であるかどうかの包括的な声明ではなく、ユースケースで一方が他方よりも優れている理由を説明できれば、それは私を決定に導くのに役立ちます.

私がこれを正しく行うことを確認するためだけに。外部の CometD サーバーと連携するように Bayeux クライアントをコーディングしています (ロングポーリング経由)。私のクライアントは、ハンドシェイク、接続、サブスクライブ、接続の順序でリクエストを送信します。後者の接続は、メッセージが利用可能になるまで停止されます。メッセージが来ると、サーバーの応答。すべてが機能します。私はそれを正しくやっていますか？

Jetty 9 で実行されている CometD サーバーに大きなメッセージ (>130k) を送信しようとしています。サーバーがこの大きなメッセージを受信すると、次の例外が生成されます。

問題が何であるかを理解しており、CometD のドキュメントを確認しました。ドキュメントによると、バッファ サイズと最大メッセージ サイズは、初期化パラメータ ws.bufferSize と ws.maxMessageSize を使用して変更できます。これらのパラメーターを web.xml ファイルに設定し、Jetty を再起動しましたが、パラメーターの設定は効果がないようです。バッファサイズが変更されていないため、まったく同じ例外が発生します。

web.xml ファイルの設定を以下に示します。

何か不足していますか？CometD サーバーで最大メッセージ サイズを設定し、実際にそのメッセージ サイズをサーバーに使用させるにはどうすればよいですか?