[jira] [Commented] (PROTON-199) [Proton-c] Python binding requires python 2.6+
[ https://issues.apache.org/jira/browse/PROTON-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553808#comment-13553808 ] Ken Giusti commented on PROTON-199: --- +1 for 2.4 - that's the oldest version of python that is supported by an active linux distro (Centos-5) that I'm aware of. [Proton-c] Python binding requires python 2.6+ -- Key: PROTON-199 URL: https://issues.apache.org/jira/browse/PROTON-199 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.3 Environment: python versions 2.5 Reporter: Ken Giusti Priority: Minor Python bindings make use of (at least two) python language features that require python versions newer than 2.5: - uuid - bytes In order to support older versions of the python language, these features would have to be removed, or a compatibility layer would need to be provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Is Proton a lightweight alternative to Qpid?
On Mon, Jan 14, 2013 at 11:14 AM, Eagy, Taylor te...@blackbirdtech.comwrote: 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
Messenger API - what am I missing?
Hi. I'm interested in testing Proton against the RabbitMQ AMQP 1.0 adapter. But I'm struggling with the APIs I need to use to write even a simple program. I'm using the Java version but from what I can see the C version has the same APIs. If I try to use the Messenger API then I don't see how I can specify a source or target on any of my links - and indeed the examples I can see showing use of the Messenger API don't do that. Indeed I don't seem to be able to specify very much, but the lack of source / target means I can't specify where I publish to or consume from. And if I run the examples and don't specify source / target I seem to end up sending attach frames with these bits missing - which the spec says means I will never send or receive messages! I tried using the lower level API (Driver / Connector / Connection / Session / Link / Message etc) but gave up when I got to 100 lines of code and hadn't sent a message - I assume I'm not supposed to use them directly? So what am I missing here? I assume there's some part of the API I don't understand... Cheers, Simon -- Simon MacMullen RabbitMQ, VMware
Re: Messenger API - what am I missing?
On Tue, Jan 15, 2013 at 9:33 AM, Simon MacMullen si...@rabbitmq.com wrote: Hi. I'm interested in testing Proton against the RabbitMQ AMQP 1.0 adapter. But I'm struggling with the APIs I need to use to write even a simple program. I'm using the Java version but from what I can see the C version has the same APIs. If I try to use the Messenger API then I don't see how I can specify a source or target on any of my links - and indeed the examples I can see showing use of the Messenger API don't do that. Indeed I don't seem to be able to specify very much, but the lack of source / target means I can't specify where I publish to or consume from. And if I run the examples and don't specify source / target I seem to end up sending attach frames with these bits missing - which the spec says means I will never send or receive messages! I tried using the lower level API (Driver / Connector / Connection / Session / Link / Message etc) but gave up when I got to 100 lines of code and hadn't sent a message - I assume I'm not supposed to use them directly? So what am I missing here? I assume there's some part of the API I don't understand... I'm guessing you need to set an address on the message. Messenger doesn't expose direct control over connections or links. It will figure out what connections/links to establish based on what address you specify on the message (kind of like SMTP). You could use something like amqp://host/target. If you post your messenger code snippet I'd be happy to comment in more detail. --Rafael
Re: Messenger API - what am I missing?
On 15/01/13 15:29, Rafael Schloming wrote:
I'm guessing you need to set an address on the message. Messenger doesn't
expose direct control over connections or links. It will figure out what
connections/links to establish based on what address you specify on the
message (kind of like SMTP). You could use something like
amqp://host/target.
If you post your messenger code snippet I'd be happy to comment in more
detail.
Thank you! So this was indeed my first idea of how to use it. So with
what I suspect is the simplest possible example:
Messenger mr = new MessengerImpl();
mr.start();
Message m = new MessageImpl();
m.setAddress(amqp://localhost:5672/queue/test);
mr.put(m);
mr.send();
I then see Proton setting the name field on the attach frame to
/queue/test - and source and target are blank:
1.0 frame decoded: {'v1_0.attach',[{name,{utf8,/queue/test}},
{handle,{uint,0}},
{role,false},
{snd_settle_mode,{ubyte,2}},
{rcv_settle_mode,{ubyte,0}},
{source,undefined},
{target,undefined},
{unsettled,undefined},
{incomplete_unsettled,false},
{initial_delivery_count,{uint,0}},
{max_message_size,undefined},
{offered_capabilities,undefined},
{desired_capabilities,undefined},
{properties,undefined}]}
(Please forgive the less-than-beautiful formatting from our adapter.)
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware
[jira] [Created] (PROTON-200) [Proton-c] Credit distribution by messenger is not balanced across all links
Ken Giusti created PROTON-200: - Summary: [Proton-c] Credit distribution by messenger is not balanced across all links Key: PROTON-200 URL: https://issues.apache.org/jira/browse/PROTON-200 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Ken Giusti The method used to distribute credit to receiving links may lead to starvation when the number of receiving links is the available credit. The distribution algorithm always starts with the same link - see messenger.c::pn_messenger_flow() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] 0.3 RC3
On Mon, Jan 14, 2013 at 2:48 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Mon, Jan 14, 2013 at 02:35:08PM -0500, Rajith Attapattu wrote: Rafi, We should create tags for the releases. Unless I have missed (in which case I apologize), I don't see any for 0.1 and 0.2 releases (I do see branches for them though). There are branches for the releases, if not tags. I do see the branches, but no tags! The Apache process requires us to tag each release to do repeatable builds. (In the case of 0.1 and 0.2 the stuff on the branch may or may not correspond to the exact released versions) Rajith -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: [VOTE] 0.3 RC3
The staging repo has been released, the RCs were copied over to dist last night, and the download page was updated this morning. I've also created a 0.3 branch. --Rafael On Mon, Jan 14, 2013 at 4:31 PM, Darryl L. Pierce dpie...@redhat.comwrote: On Mon, Jan 14, 2013 at 02:14:26PM -0500, Rafael Schloming wrote: +1 from me as well. I think we have enough votes/time to call this one. I'll post the RC3 as 0.3 shortly. Sorry, thought I'd posted before my +1. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: Messenger API - what am I missing?
Yes, the Python version works as I would expect, modulo:
* It strips the leading / from the target address
* On my machine, localhost resolves to ::1, and Proton appears not to
support IPv6.
But both of those can be worked around. Thank you!
Cheers, Simon
On 15/01/13 16:11, Rafael Schloming wrote:
That looks to me like it's a bug, possibly in the Java Messenger
implementation, or possibly some kind of interop bug. Any chance you
could try the same example in python and see if it works any better?
messenger = Messenger()
messenger.start()
msg = Message()
msg.address = amqp://localhost:5672/queue/test
messenger.put(msg)
messenger.send()
messenger.stop()
--Rafael
On Tue, Jan 15, 2013 at 10:46 AM, Simon MacMullen si...@rabbitmq.com
mailto:si...@rabbitmq.com wrote:
On 15/01/13 15:29, Rafael Schloming wrote:
I'm guessing you need to set an address on the message.
Messenger doesn't
expose direct control over connections or links. It will figure
out what
connections/links to establish based on what address you specify
on the
message (kind of like SMTP). You could use something like
amqp://host/target.
If you post your messenger code snippet I'd be happy to comment
in more
detail.
Thank you! So this was indeed my first idea of how to use it. So
with what I suspect is the simplest possible example:
Messenger mr = new MessengerImpl();
mr.start();
Message m = new MessageImpl();
m.setAddress(amqp://__localhost:5672/queue/test);
mr.put(m);
mr.send();
I then see Proton setting the name field on the attach frame to
/queue/test - and source and target are blank:
1.0 frame decoded: {'v1_0.attach',[{name,{utf8,__/queue/test}},
{handle,{uint,0}},
{role,false},
{snd_settle_mode,{ubyte,2}},
{rcv_settle_mode,{ubyte,0}},
{source,undefined},
{target,undefined},
{unsettled,undefined},
{incomplete_unsettled,false},
{initial_delivery_count,{uint,__0}},
{max_message_size,undefined},
{offered_capabilities,__undefined},
{desired_capabilities,__undefined},
{properties,undefined}]}
(Please forgive the less-than-beautiful formatting from our adapter.)
Cheers, Simon
--
Simon MacMullen
RabbitMQ, VMware
--
Simon MacMullen
RabbitMQ, VMware
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.comwrote: 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
Re: Is Proton a lightweight alternative to Qpid?
Taylor, You need the following files: proton.py (from proton-c/bindings/python) cproton.py (from $BUILD/bindings/python) _cproton.so(from $BUILD/bindings/python) libqpid-proton.so (from $BUILD) -Ted On 01/15/2013 03:35 PM, Eagy, Taylor wrote: 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
