問題タブ [pika]

短いバージョン: リモート プロシージャ コールの状況で Pika をブロックしないようにするにはどうすればよいですか?

長いバージョン:

Pika の例はどれも、私のユース ケースを示していません。

AMQP（RabbitMQ、Pika）を介して他のプロセス/マシンと通信するTornadoサーバーがあります。これらの他のプロセスはあまり明確に定義されていませんが、ほとんどの場合、データを返します ( RabbitMQ の Web サイトの RPC の例を参照してください)。場合によっては、プロセスが大量の情報を処理するのに非常に長い時間がかかることがありますが、小さなリクエストがプロセスによって取得されるのを完全にブロックするべきではありません。または、リモート サーバーが Web 要求を送信したためにブロックされている可能性があります。Web サーバーのように考えてください。ただし、HTTP の代わりに AMQP を使用します。

Pika のドキュメントでは、スレッドセーフではないと主張しているため、接続を複数のスレッド (またはプロセス) に渡すことはできません。私がやりたいことは、Tornado でできるように、新しいプロセスを開始し、ソケット イベント (そのプログラムへのパイプ用) を Pika IOLoop に追加することです。Pika IOLoop は Tornado IOLoop とは大きく異なり、複数のハンドラーの追加をサポートしていないようです。1 つのソケットで 1 つの「ポーラー」を使用して動作しているようです。

IOLoop のみを使用するため、このパッケージに Tornado パッケージを要求することは避けたいと思います。それは問題外ではありませんが、他のオプションが何であるか、または複数の Pika IOLoops/Poller を何らかの方法で接続することによって問題の解決策があるかどうかを確認したいです。RabbitMQ のドキュメントには、多くの場合、ワーカーを追加することで「スケールアップ」できると書かれています。着信するすべてのリクエストに対して接続を作成することは避けたいと思います (リクエストが高速に着信する場合)。

取引所に複数のキューを設定する必要があります。単一の接続を作成してから、複数のキューを宣言し（これは機能します）、次に複数のキューでメッセージを公開します（これは機能しません）。

これを行うためにいくつかのテストコードを設定しましたが、毎回2回目の公開でハングアップします。このコードは、単一のキューで公開するときに機能するため（単一のキューで複数のメッセージを送信する場合でも）、接続を閉じずに複数のキューで公開するのは好きではないと思います。

これを機能させるために追加する必要があるものはありますか？公開間の接続を閉じる必要がないようにしたいと思います。また、コンシューマーを起動すると、複数のキューで送信するときにbasic_publish（）に送信しても、コンシューマーには何も表示されません。単一のキューで公開している場合、メッセージがほぼ瞬時に表示されます。

私たちのソフトウェア プログラムは 5 か月間問題なく動作していましたが、突然 Pika 警告が表示されるようになり、最終的に例外が発生しました。

Pika 0.9.5 UserWarning: 書き込みバッファが警告しきい値を超えました。

私は多くのフォーラムを検索しましたが、ほとんど満足できませんでした。説明されている 1 つの解決策は、これらの警告を完全に無視することでしたが、私はそれについて少し懐疑的です。この問題についての助けをいただければ幸いです。非常に緊急です。

ありがとう

Pika ライブラリ (gevent によってパッチが適用されたサル) を使用して、gevent プログラム内から RabbitMQ を利用しようとしましたが、gevent はランダムにタイムアウト エラーをスローするのが好きです。

私は何をすべきか？私が使用できる別のライブラリはありますか？

Python で AMQP サポートを実装するライブラリが多数あることは知っています。ただし、必要なのはライブラリです。同期スタイルで AMQP パブリッシュを実行できるようにする必要があります。これは WSGI アプリから使用されるため、キュー ブローカーとの通常の非同期コールバック駆動型の対話スタイルは、少し場違いです。

システムの他の部分では、 AMQP サポートにpikaを使用していますが、これは非同期であり、一種の「ブロッキング」接続があっても使用したくありません。

もちろん、他のすべてが失敗した場合は、WSGI プロセスごとに Pika イベント ループを維持することができます。もう 1 つの問題は、Pika の現在の安定版に厄介な (IMO) バグがいくつか見つかったため、別のものを使用したいということです。

繰り返します：

• basic.publish を実行する必要があります (メッセージが実際に公開されていないことがわかるように、「確認」をサポートしています)
• 同期的に
• rabbitmq へ (明らかに、「純粋な」AMQP も機能します)
• Python WSGI アプリケーションから

私は実稼働システムで pika を使用していますが、BlockingConnection と SelectConnection の両方が、明らかなエラーや警告なしであちこちにメッセージをドロップしていることに気付きました。残念ながら、コードを投稿することはできませんが、この種の行動を経験した可能性のある他のユーザーからのガイダンスや逸話を求めたいと思いました. RabbitMQ は非常に堅実であると聞いたので、pika の信頼性に疑問を持ち始め、より信頼できる代替手段があるかどうか疑問に思っています。

キューがあり、そこから n 個の要素を詰め込みました。

そこから 1 つの要素を取得して、コールバックを終了したいと考えていますpika。すべての例でコールバック メカニズムが使用されていますが、これはアプリケーションの構造ではまったく意味がありません。

次のようにコールバックを定義する

メッセージがキューに残っているため、機能しません

これを行うための通常のイディオムは何ですか?

私はRabbitMQとPikaを使用するのが初めてなので、答えが明らかな場合はすみません...

いくつかのデータをフィードし、その結果を rabbitmq メッセージ キューに渡します。キューは、elasticsearch にデータを書き込むプロセスによって消費されています。

データは、エラスティック検索にフィードするよりも速く生成されているため、キューが大きくなり、縮小することはほとんどありません。

pika を使用していて、警告が表示されます。

これは、Pika が奇妙なエラー メッセージで単純にクラッシュするまで、しばらく続きます。

Pika BlockingConnection オブジェクト (http://pika.github.com/connecting.html#blockingconnection) を使用しています。

これを修正する私の計画は、add_backpressure_callback 関数を使用して、背圧time.sleep(0.5)を適用する必要があるたびに呼び出す関数を作成することです。しかし、これは解決策が単純すぎるように思われ、このような問題を処理するためのより適切な方法が必要です。

キューが消費されるよりも速く入力されるというのは、よくある状況だと思います。キューを遅くする最善の方法について、例やアドバイスを探しています。

ありがとう！

2 つの異なるソースからのメッセージをリッスンするコンシューマーをセットアップしています。これら 2 つのソースからのメッセージに対して別のコールバックが必要です (ただし、他のソリューションは大歓迎です)。

私はrabbitmqとpikaに非常に慣れていないので、まだ核心的な詳細を把握していません. しかし、私が知りたいのは：

別のキューを使用して 2 つ設定する必要があります

私のコールバックのために、または代わりにルーティングキーでいくつかのトリックを行う必要がありますか?

rabbitmq サーバーに接続しようとしているアプリケーションがありますが、アプリケーションがサーバーに接続できない場合、指定された秒数以内にアプリケーションをタイムアウトさせたいと考えています。

私の問題は、それを行う方法がわからないことです。

明確にするために、私のプロデューサーが接続を試みたとき、私は以前にタイムアウトしたいと思っています.今では最大20〜30秒かかるからです.