Welcome to the new home of Open Message Queue (Open MQ) on GitHub. Open Message Queue is a complete message-oriented middleware platform, offering high quality, enterprise-ready messaging. It is the reference implementation for the JMS (Java Message Service) specification, and the JMS provider in GlassFish. Open Message Queue is open source, with a community of developers and users. Please see the
概要 : AMQP のプロトコルを読むと、一瞥して送信はパケットを送るだけ、受信はソケットを読み込むだけのようにも見える。しかしながら、実際に書いてみると、再送処理を自前で実装する必要があるため、現実には大変に複雑な処理が必要だ。 そもそもなぜ RabbitMQ を使うのかという話、あるいはなぜ再送が必要かという話たんにコンポーネント同士が疎結合で通信したいのであればわざわざ MQ を使う必然性は皆無である。ごくあたりまえに TCP で通信すればそれでいい。暗号通信が必要なら当然 SSL でいいし、パケットエンティティに依存する複雑な L7 リバースプロキシを MQ を使って実現することも、不可能ではないが、普通そういうのは varnish とかでやるだろう。 MQ において優れているのはデータの durability だ。つまり、一旦キューにためておけば、その両側のコンポーネントは好き勝
原文(投稿日：2012/02/13)へのリンク Apache Apollo 1.0 がリリースされた。ActiveMQ のサブプロジェクトである Apache Apollo は，マルチコア・マルチプロセッサ指向の新たなスレッディングモデルを備えることによって，速度とスケーラビリティ，さらには信頼性の面でも ActiveMQ やその他の多くのメッセージ処理プロジェクトを凌駕する。 Apollo 1.0 の特徴： Stomp 1.0 ワイヤプロトコル Stomp 1.1 ワイヤプロトコル トピックおよびキュー キューブラウザ トピックの恒久サブスクリプション 高信頼性メッセージング (reliable messaging) JMS API その他多数 Apollo の開発リーダである Hiram Chirino 氏は，Apollo 本来のパフォーマンスを実証するために STOMP ベンチマーク
前回の記事にて、Kyoto Tycoonでメッセージキューを実現する方法について述べた。今回は、それを実運用にて使いやすくするための諸機能について説明する。みんな大好きなmemcachedプロトコルでメッセージキューを実現してみよう。 ジョブキューとメッセージキュー どうでもいい話ではあるが、ジョブキューおよびメッセージキューという用語はよく混同して使ってしまう。俺定義では、ジョブキューは「ジョブ管理機能」という目的をたまたまキュー構造に基づいて実装しているものであり、メッセージキューはキュー構造に基づく非同期メッセージング機構であって用途は特に限定しない。つまりメッセージキューをジョブキューを実装するのに使うこともあるが、それ以外の用途にもメッセージキューは使われる。またジョブキューをメッセージキューに基づかないで同期的に実装することもできる。 きっと偉い学者さんがどこかでちゃんとした定
本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーはnekokakさんこと小林篤さんで、テーマは「ジョブキューで後回し大作戦」です。 ジョブキューとは 一時代前は時間のかかる処理もすべてWebアプリケーションで行っていましたが、最近ではいろいろな部分で処理の非同期化が行われるようになってきました。たとえばWebのインタフェース側ではAjaxがその最たるものでしょう。アプリケーションのバックグラウンド側でも今回のテーマであるジョブキューと呼ばれるしくみが多く利用されるようになりました。ジョブキューを賢く上手に利用することで、ユーザにストレスを与えることなく、またサーバのリソースも有効に使えるようになります。 ジョブキューは延々と動き続けるバッチ処理、というイメージが最もわかりやすいでしょう。通常のバッチ処理であればcrondを利用し、一定周期でプログラムを起動して
memcachedプロトコルでメッセージキューが実現できるという話を前回したが、今回はその具体的な使用方法を解説してみる。 サーバを起動する まずはサーバを起動しないと始まらない。典型的には以下のコマンドで立ち上げるとよい。 $ ktserver -th 1 -ls \ -plsv /usr/local/libexec/ktplugservmemc.so \ -plex 'port=11211#tout=30#thnum=16#opts=fq#qtout=10' \ 'casket.kct#ktopts=p' 「-th 1」でメインサーバのスレッド数を1にしている。最新版からはデフォルトで16スレッドを立てるのだが、アプリ側からはメインのサーバにはアクセスしないだろうから、1個あればよい。「-ls」はログレベルをSYSTEMに設定。「-plsv ...」では、memachedプラガブルサー
巷では git の大ブームだけど，ひさしぶりに Mercurial について書きます。 Mercurial について言及されたブログとか読んでいるとき，たまに MQ という言葉を目にして気になっていた。ながらく気にはとめつつ全然調べていなかったんだけど，ちょっと利用しようかなというケースがあり，ちょこっと触ってみた。 自分の理解では，MQ (Mercurial Queues) とは，誤解を恐れずにいえば Mercurial の changeset と独立して構成される修正履歴（パッチ）のスタックのようなものだ。 （なので今後 MQ の patch queues を Queues という名称と裏腹に「パッチスタック」「パッチ群」などと勝手に呼び称します） 「誤解を恐れずにいえば」と書いたけれど，この直感的な印象は MQ を使っていくうちに――大筋では変わらないものの――ちょっと変わった。それ
kombuはceleryの作者askによるメッセージングフレームワーク。https://github.com/ask/kombu同じ作者によるcarrotというライブラリ/フレームワークもあるが、kombuはcarrotをリライトしなおしたもので、今後はkombuの方を開発していくらしい。それにしても、askはどんだけメッセージングが大好きなんだよ。celeryとcarrot/kombuの違いは、celeryが高レベルのタスクキューAPIを用意しているのに対して、carrot/kombuはより低レベルのよりAMQPに近いAPIを提供していることにあると思っている。個人的にはceleryよりcarrot/kombuの方が小回りが効いて使いやすい。carrotとkombuを比べるとkombuの方がモジュール構成がシンプルで、APIもより素のAMQPに近いと感じた。kombuのREADMEに書い
Why ZeroMQ? ZeroMQ (also known as ØMQ, 0MQ, or zmq) looks like an embeddable networking library but acts like a concurrency framework. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fan-out, pub-sub, task distribution, and request-reply. It's fast enough to be the fabric
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
