Ted,
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) Thanks, Taylor ________________________________ 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? 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 >
