問題タブ [workling]

私は神を使ってスターリングデーモンとワーキングデーモンを開始および監視していました。

開発マシンでは問題なく動作しますが、本番マシンでは「workling_starling_client」が起動しません。

今日、バックグラウンド タスク キューを処理するために Starling と Workling を多用する Web サイトを立ち上げました。

トラフィックが非常に多く、サーバーの CPU やメモリに大きな負荷がかかっていませんが、ジョブ キューが深刻にバックアップされています。

私は Starling と Workling の両方に不慣れで、キューを高速化する方法を早急に理解する必要があります。

これはおそらく非常に単純な構成の問題ですが、すべての提案や考えをいただければ幸いです。

さらに情報が必要な場合はお知らせください。

動作中のデーモンを正しく動作させるのに問題があります。私が走るとき：

デーモンはレールのロードを開始しますが、無期限にハングします。プロセスを強制終了すると、スタックトレースは常に同じになります。

デーモンライブラリなしでスクリプトを実行すると、期待どおりに機能します。実際、Rails環境を必要とするものをロードするためにデーモンgemを使用するのに問題がありました。何か案は？

更新：workling_clientはworklingslisten.rbをデーモンとしてロードします。listen.rbにrailsをロードする代わりに、代わりにworkling_clientにロードされるように変更し、プロセスは問題なく機能します。したがって、デーモン化されたスクリプトでレールをロードできない理由がいくつかあります:-(

非同期処理を行う Rails アプリを持っていますが、プロダクション モードで動作させるのに問題があります。次のように、アプリケーションのルートからスターリングを開始します。

それから私はこのように働き始めます

これを初めて実行したとき、開発データベースがないために不平を言ったので、開発データベースを作成しました。作業を再開すると、そのエラーはなくなりました。しかし、実際に非同期プロセスを実行しようとすると、log/production.log にこのメッセージが表示されます

だから、私は走る

次に、次のようにアプリケーションのルートから starling を再起動します。

正常に動作しているように見えますが、この script/workling_client start -t を使用して作業を再開しようとすると、コンソールにこのメッセージが表示されます

そこで、workling プラグイン内の config/workling.yml ファイルを変更して、本番環境と開発環境の両方が 15151 でリッスンするようにしようとしましたが、うまくいきませんでした。次に、22122 で両方を試しましたが、サイコロはまだなかったので、ランダムに試してみましたポートですが、workling.ymlファイルに何を入れてもまったく同じ動作をします

非同期タスクを実行するRoRアプリをデプロイしようとしています。そのためにworklingを使用し、メッセージキューはRabbitMQです。この組み合わせはStarlingで問題なく機能しましたが、MQforRabbitを変更することにしました。どこかで、environment.rbに次のコードを含める必要があることを読みました。

しかし、Apacheは次のメッセージで完全に失敗します：サーバーで内部エラーまたは設定ミスが発生し、リクエストを完了できませんでした

workling.output または production.log で作業のログが表示されないのはなぜですか?

開発中、ログは development.log に表示されます。

私の環境/ production.rb では、ログレベルをデバッグに設定しています。config.log_level = :debug

私はこのようにスターリングとワークリングを始めています

私は現在、RailsアプリでWorklingwithStarlingを使用しています。Worklingは好きですが、監視するのはちょっと難しいと思います。

さらに悪いことに、Worklingインスタンスがいくつかあります。Worklingは、：multipleを「true」に設定して実行しています（workling_client内）。

各インスタンスなどのpidを確認できますが、実際に何らかの作業を行っているかどうかを知り、実行するインスタンスを増やす（または減らす）必要があるかどうかを確認したいと思います。

ツール、ハック、またはこれについて私を助けることができる何かの提案がありますか？

We have a rails app running on passenger and we background process some tasks using a combination of RabbitMQ and Workling. The workling's worker process is started using the script/workling_client command. There is always only one worker process started, and the script/workling_client has a :multiple => false options, thus allowing only one instance. But sometimes, under mysterious circumstances which I haven't been able to track down, more worklings spawn up. If I let the system run for some time, more and more worklings appear. I'm not sure if these rogue worklings cause any problems, but it is still unsettling not to know why is it happening. We are using Monit to monitor the workling process. So if it dies, it will spawn it up again. But this still does not explain how come there are suddenly more than one of them.

So my question is: does anyone know what can be cause of this and how to make it stop? Is it possible that workling sometimes dies by itself, without deleting it's pid file? Could there be something wrong with the Daemons gem workling_client is build upon?

Swoopo スタイルのオークション サイトであるアプリケーションで、バックグラウンド タスクを処理するために Starling と Workling を使用しています。この場合、バックグラウンド タスクは、オークションを監視して勝者に通知する通知システムです。モニタは、オークション オブジェクトの作成時に呼び出されます。私の問題は、監視コードが監視対象のオークションを見つけられないことです。コードは次のとおりです。

失敗する単体テスト:

ワーカーコード:

ワーカーを呼び出すコード:

テストを実行するたびに、ワーカーに提供されたオークションが見つからないというエラーが表示されます。

誰にもアイデアはありますか？Rails 2.3.5、sqlite3、および最新の Starling、Workling、およびその他の関連するすべての gem を Mac OSX 10.6.2 Macbook Pro で使用しています。

すべての入力に感謝します。

自分のニーズに合ったメッセージングシステムを探しています。手伝って頂けますか ？

• 今のところ、処理するデータの量はそれほど多くありませんが、後で制限されたくありません...
• マシンは単なるWebサーバーではないため、処理速度がそれほど速くない場合でも、メッセージングツールは軽量である必要があります。
• サーバーで一部のデータが変更された場合、すべてのサーバーがその情報を保持し、ローカルで処理する必要があります。（それぞれのサーバーごとに1つのチャネルを作成する必要がありますか？）
• フロントエンドはRailsで記述されているため、開発を簡素化するために、送信される通信とデータを管理するためのgem/プラグインがあることが重要です。

現時点では ：

• RabbitMQ+worklingは私のニーズに合っているようです。これは正しい選択でしょうか？
• ActiveMQは、Javaのせいで、私を恐れさせます（Javaについてはよくわかりませんが、CPUを大量に消費しているようです）。
• 他の人は彼らほど成熟していないようです。

この種の技術を使った開発はたくさんあるかもしれないので、間違った方向に進むことはできません！

助けてくれてありがとう。