Taylor,
Another possibility to look at is using ActiveMQ as your broker. They've
added an AMQP transport (based on Proton-J) to their project recently.
-Ted
On 01/15/2013 12:37 PM, Eagy, Taylor wrote:
Rafael,
Thanks for responding. The only reason why I said it wouldn't be portable is
because when I saw the CMake files I thought I'd have to build it to bind C
functions from the engine to Python. However, if I can perform the p2p
messaging just using the proton.py then that would work. My scenario is the
following: I have three Python modules running. One is a web service that takes
incoming requests and places the request data as a message on an incoming
queue, then another Python service listens on the incoming queue and processes
the data in the messages. After it finishes processing the data it passes the
results as another message onto an outgoing queue which is then grabbed by the
last Python service and sent back. Previously I was using the Java Qpid broker
because I need persistence enabled so that if the Qpid broker or one of these
Python services were to fail during a queue transaction, the services, when
restarted, would be able to pickup the durable message and continue the data
flow. While it works great with the Qpid broker, the main issue is that the
Qpid broker is just too heavy. I need a fast lightweight version that still
offers the basic persistence (I was using Derby store) and ideally written in
Python since all of my code is in Python. I don't have any specific performance
requirements other than saying the faster the better. Right now all of the
queueing is done locally between these services, but I would like to have the
ability to extend it easily to work over networked machines which I know Proton
can do. Do you think it's overkill to use something like Qpid or Proton in my
scenario?
Thanks,
Taylor
________________________________
From: Rafael Schloming [r...@alum.mit.edu]
Sent: Tuesday, January 15, 2013 8:44 AM
To: proton@qpid.apache.org
Subject: Re: Is Proton a lightweight alternative to Qpid?
On Mon, Jan 14, 2013 at 11:14 AM, Eagy, Taylor <te...@blackbirdtech.com>wrote:
Hi guys,
I've been using Qpid for the past several months and I really like it.
However, I've mainly just been using it to pass messages between several
Python processes running on the same machine, so using Qpid is probably
overkill. Then I noticed Proton and got excited. Ideally I'm looking for a
fast, lightweight, and portable queueing library preferrably in Python. Are
there any roadmap plans to create a Proton Python broker/engine? I looked
at RabbitMQ, but read the performance wasn't as good as Qpid. I was looking
into the examples and noticed you could implement your own queueing server
in Python, but it's not exactly portable since I'd have to build it for
Linux and Windows.
Hi,
To answer the question in your subject first, Proton isn't an alternative
to Qpid per/se, rather it's a component of Qpid. The latest release of the
cpp broker uses proton to provide AMQP 1.0 support, and we plan to use it
in future releases of the Java broker also. That said, Proton is definitely
intended to be used independently of either the cpp or Java broker, and can
be used without either (i.e. peer to peer), so in that sense the answer to
your question is yes.
There is definitely interest in building a lightweight queuing component
that works well with Proton and can be flexibly deployed in a variety of
topologies, and even dynamically/transparently redeployed at runtime. A
python prototype has been discussed as a starting point for some of this
work, and there has been other work ongoing both in terms of re-factoring
the cpp broker and in terms of prototyping new servers that may ultimately
contribute.
Why do you think your own queuing server built in python wouldn't be
portable? Can you describe a little bit more about your scenario, e.g. do
you need persistence, transactions, etc ...? Do you have any particular
performance requirements? Can you describe your messaging topology at all?
--Rafael
