Proton is more lightweight and the systems that it runs on won't have Java 
installed. While I would prefer a more Pythonic portable solution, as long as 
Proton-c builds within 5MB, then it should work. However, I'm getting a bunch 
of undefined reference messages from pythonPYTHON_wrap.c when trying to make 
install it. So if I just want to use the p2p messaging between Python 
processes, what are the minimum amount of files that I need to create a Python 
queue server to handle the queues between processes? (i.e. proton.py, 
cproton.py, etc)



From: Ted Ross [tr...@redhat.com]
Sent: Tuesday, January 15, 2013 1:34 PM
To: proton@qpid.apache.org
Subject: Re: Is Proton a lightweight alternative to Qpid?


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.


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

Reply via email to