問題タブ [bunny]

RabbitMQ サーバーに接続しようとしていますが、常に次のエラーが発生します。

と

MAC OSでRuby 2.1.2、RabbitMQ 3.5.6を使用しています。申し訳ありませんが、私はRabbitMQの初心者です。使用しようとしているだけですが、問題を処理できません。アドバイスをお願いします。

これは私の config/initializers/bunny.rb ファイルです:

ご覧のとおり、どこでも使用できるように、SmsHandle をグローバル変数として宣言しました。

ワーカー コード:

しかし、ここでの問題は、delayed_job で呼び出されるメソッドで使用できないことです。

では、delayed_job がこの特定の変数を使用できるようにするにはどうすればよいでしょうか。

config/initializer/delayed_job.rb でこのような変数を宣言する必要がありますか? これでもうまくいかないようです。誰かがこれを行う正しい方法を指摘できますか?

rabbitmq を使用して RPC を構築しようとしています。

rabbitmq http://www.rabbitmq.com/tutorials/tutorial-six-ruby.htmlを使用して RPC を構築するためのチュートリアルによると、クライアントごとに 1 つの応答キューを使用し、correlation_id を使用して応答と要求をマッピングできます。correlation_id の使用方法について混乱していますか?

これが私が実行している問題です。2 つの異なる相関 ID を持つ同じ応答キューを使用して、1 つのクライアントから 2 つの rpc 呼び出しを同期的に作成したいと考えています。ただし、チュートリアルで読んだことから、各クライアントが rpc 呼び出しを順番に行っていると想定しているように見えるため、これが正しいユースケースであるかどうかはわかりません。(この場合、なぜここで correlation_id が必要なのか、さらに混乱します)。

これは、私が達成しようとしているコード例です (rpc_server.rb はチュートリアルと同じです)。うまくいけば、私の質問がより明確になります。

thr1 に設定すると、correlation_id が thr2 によって上書きされるため、以下のコード ブロックは機能しません。

とにかくそれを修正して機能させることはあるのだろうか？@reply_queue.subscribe ブロックを初期化から外して別の call_id を渡そうとしても、thr1 が終了するのを待っている間に @reply-queue がロックされるように見えるため、まだ機能しません。

質問が不明な場合はお知らせください。ご回答いただきありがとうございます。

bunny ruby​​ gemを使用して、rabbitmq サーバーとの間でメッセージを送受信しています。待機時間にタイムアウトを設定しながら、キューからメッセージを同期的にポップするにはどうすればよいですか (つまり、3 秒後にメッセージが到着しない場合はブロックを停止します)。

明らかな解決策の 1 つは、タイムアウトになるかメッセージが受信されるまで pop 呼び出しをループすることですが、これは非常に非効率的です。よりエレガントなソリューションはありますか？bunny のドキュメントと rabbitmq サイトのチュートリアルを調べましたが、この特定のシナリオの解決策が見つかりません。

複数のアプリケーションが RPC 呼び出しを実行できるように、プロジェクトで RabbitMQ と共に Bunny Gem を使用しています。これらの呼び出しで統合テストを行う方法を見つけるのに苦労しています。確かに、偽のデータを返すメソッドをモックしてオブジェクトを作成し、スタブ化することはできますが、RabbitMQ を使用した VCR gem のようなものがあると便利です。バニーをテストする最善の方法に関するガイダンスはありますか?

他のスレッドでも同様の問題を見たことがありますが、決定的な答えはありません。

約 4 つのコンシューマー (Bunny クライアント gem を使用して Ruby で記述) をスピンアップして、同じキューにサブスクライブし、メッセージを処理します。約 20,000 から 40,000 のメッセージが消費されるまで、すべて正常に動作します。その後、コンシューマーは単にメッセージの受信を停止します。接続/チャネルは開いたままになり、サーバーは引き続きコンシューマーを認識しますが、メッセージを受信しません。

同様のスレッドで提案されているように、プリフェッチの問題ではないと思います。さまざまなレベルでプリフェッチを設定しましたが、問題は解決しません。問題は、1 つのコンシューマが他のコンシューマよりも先にすべてのメッセージを取得していることではなく、すべてのコンシューマが停止していることです。

ホストされたRabbitMQサービスCloudAMQPを使用しているので、パフォーマンスの問題である可能性があると考えましたが、メッセージの発行は引き続き正常に機能しており、選択したインスタンスサイズに関係なく同じ問題を抱えています. ログを見ても何もおかしくない。

ch.acknowledge(delivery_info.delivery_tag, false) を使用してメッセージを明示的に確認していることを付け加えておきます。

私はここで少し困惑しており、あなたの助けに本当に感謝しています. 重要な詳細を省略した場合はお知らせください。

いくつかのコード例: