Re: Review Request 30318: allow for simple send in proton
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote: proton-c/bindings/python/proton/__init__.py, line 2701 https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701 This seems to change the semantics of send in a subtle but odd way. If you pass in something that it knows how to encode into bytes, it will assume that constitutes an entire message and call advance and automatically generate a tag for you. Yet if you pass in raw bytes, it doesn't do this. I think these two things should really be controlled orthogonally, e.g. I might want to be able to configure the sender to assume every call to send is a single message even if I'm just passing in raw bytes, and I might also want to be able to stream large messages out by passing in higher level message chunks that the sender automatically encodes into bytes for me. Gordon Sim wrote: WHat I want is a simple, single call to send a message. I'd like that to be called send(), since that seems a clear and intuitive name for it. However that clashes with the existing definition. I would argue that send() isn't such a great name for the current semantics in that it isn't (in my view) clear that you first need to create a delivery and then need to call advance() when done. To me the current semantic is more like an append_data(). However, I didn't want to impose a breaking change. Hence the somewhat odd combination of semantics for the same name. There are (at least) three ways to deal with this: (1) use send_message() for the new simple, single call semantic and leave send() as is. I could live with that but it seems a shame to me to use the obvious name for the less obvious (and I believe less commonly required) semantic (2) use send() exclusively for the new simple, single call semantic, and have send_bytes() - or better still perhaps, append_data() - as the old semantic. This is obviously a breaking API change though, not sure how acceptable that would be? (3) add in some flag(s)/option(s) to control the single-shot v. part-of-sequence-of-calls semantics. However the defaults need to be decided. So agin, we can default it to the current bheaviour, but that in my view is less intuitive and less commonly what users want. Or we can default it to the new behaviour, but that then is another breaking change. To me, if a breaking change is acceptable, I'd probably go for something like (2), because I think it will be clearer. Perhaps I'm just not imaginative enough yet on what the flags/options might be like in 3. If a breaking change isn't acceptable, I'd probably rather just stick with a send_message() rather than have a send() where a non-default option was required to trigger the single-shot behaviour. Rafael Schloming wrote: I agree with you that send(Message) should do the obvious thing, so I'm not keen on (1). I don't agree that send is a bad name for the streaming behaviour though. I think in the scenario where you are streaming a large message out over the wire, you are still very much sending, it's just that you are sending Message Chunks rather than entire messages, but you are still sending a unit of work that you expect to make it all the way over the wire to the receiver. I also think that automatically rendering objects into amqp bytes shouldn't be only associated with the non streaming case, in other words I want to be able to do something like this: send(Header); send(Chunk); ...; send(Footer) Where each of those things are actual objects that know how to render themselves into the appropriate AMQP section. One possibility here might be to delegate back to the object itself again for a bit more flexibility, e.g. have send check if the object being sent has some sort of send_yourself method and then delegate back to it. That would allow the object to then set up whatever delivery tags it wanted, encode itself however it wanted, and then choose whether or not to advance the link. Presumably in the above example the Header would set up the delivery tag, the Chunk would just send more data, and the Footer would advance the link. That of course does leave the question of defaults when you pass in raw bytes. To keep backwards compatibility we would need to say that passing in raw bytes is equivalent to passing in Chunk(bytes), assuming Chunk is defined to be roughly what I described above. I'm not opposed to breaking compatibility here though, I think that's partly the point of this release. Gordon Sim wrote: I fully agree that automatically encoding an object into bytes shouldn't be restricted to a Message. In theory I also agree that the object being sent could identify whether it is 'complete' or not. My only concern there would be that it might
Re: Review Request 30318: allow for simple send in proton
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/#review70001 --- Ship it! Ship It! - Rafael Schloming On Jan. 28, 2015, 12:17 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 12:17 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
[jira] [Created] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
Alex Rudyy created QPID-6343: Summary: [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
[ https://issues.apache.org/jira/browse/QPID-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294914#comment-14294914 ] ASF subversion and git services commented on QPID-6343: --- Commit 1655246 from oru...@apache.org in branch 'maven/trunk' [ https://svn.apache.org/r1655246 ] QPID-6343: Remove derby version from qpid parent pom.xml as it is only java broker dependency [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 -- Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: qpid-proton git commit: NO-JIRA: Removed python with keyword from utils.py, not supported in jython.
On 01/27/2015 02:55 PM, acon...@apache.org wrote: Repository: qpid-proton Updated Branches: refs/heads/master c96f10736 - 553023b95 NO-JIRA: Removed python with keyword from utils.py, not supported in jython. In jython 2.5 I believe you have to use: from __future__ import with_statement (Since jython is used only for testing, perhaps we could even upgrade?) [...] http://git-wip-us.apache.org/repos/asf/qpid-proton/blob/553023b9/proton-c/bindings/python/proton/utils.py -- diff --git a/proton-c/bindings/python/proton/utils.py b/proton-c/bindings/python/proton/utils.py index 187fc29..65121ee 100644 --- a/proton-c/bindings/python/proton/utils.py +++ b/proton-c/bindings/python/proton/utils.py @@ -191,22 +191,26 @@ class BlockingConnection(Handler): def on_disconnected(self, event): raise ConnectionException(Connection %s disconnected % self.url); -def atomic_count(start=0, step=1): -Thread-safe atomic count iterator -lock = threading.Lock() -count = start -while True: -with lock: -count += step; -yield count - +class AtomicCount(object): +def __init__(self, start=0, step=1): +Thread-safe atomic counter. Start at start, increment by step. +self.count, self.step = start, step +self.lock = threading.Lock() + +def next(self): +Get the next value +self.lock.acquire() +self.count += self.step; +result = self.count +self.lock.release() +return result Why do you need an AtomicCount? The intent to allow concurrent requests I assume? The underlying BlockingConnection and engine objects are not threadsafe, so if that assumption is correct you will need to prevent threads from concurrently accessing the same objects. class SyncRequestResponse(IncomingMessageHandler): Implementation of the synchronous request-responce (aka RPC) pattern. -correlation_id = atomic_count() +correlation_id = AtomicCount() def __init__(self, connection, address=None): - To unsubscribe, e-mail: commits-unsubscr...@qpid.apache.org For additional commands, e-mail: commits-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
[ https://issues.apache.org/jira/browse/QPID-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-6343: Assignee: Keith Wall (was: Alex Rudyy) Keith please review the changes [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 -- Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Alex Rudyy Assignee: Keith Wall Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 30318: allow for simple send in proton
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote: proton-c/bindings/python/proton/__init__.py, line 2701 https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701 This seems to change the semantics of send in a subtle but odd way. If you pass in something that it knows how to encode into bytes, it will assume that constitutes an entire message and call advance and automatically generate a tag for you. Yet if you pass in raw bytes, it doesn't do this. I think these two things should really be controlled orthogonally, e.g. I might want to be able to configure the sender to assume every call to send is a single message even if I'm just passing in raw bytes, and I might also want to be able to stream large messages out by passing in higher level message chunks that the sender automatically encodes into bytes for me. Gordon Sim wrote: WHat I want is a simple, single call to send a message. I'd like that to be called send(), since that seems a clear and intuitive name for it. However that clashes with the existing definition. I would argue that send() isn't such a great name for the current semantics in that it isn't (in my view) clear that you first need to create a delivery and then need to call advance() when done. To me the current semantic is more like an append_data(). However, I didn't want to impose a breaking change. Hence the somewhat odd combination of semantics for the same name. There are (at least) three ways to deal with this: (1) use send_message() for the new simple, single call semantic and leave send() as is. I could live with that but it seems a shame to me to use the obvious name for the less obvious (and I believe less commonly required) semantic (2) use send() exclusively for the new simple, single call semantic, and have send_bytes() - or better still perhaps, append_data() - as the old semantic. This is obviously a breaking API change though, not sure how acceptable that would be? (3) add in some flag(s)/option(s) to control the single-shot v. part-of-sequence-of-calls semantics. However the defaults need to be decided. So agin, we can default it to the current bheaviour, but that in my view is less intuitive and less commonly what users want. Or we can default it to the new behaviour, but that then is another breaking change. To me, if a breaking change is acceptable, I'd probably go for something like (2), because I think it will be clearer. Perhaps I'm just not imaginative enough yet on what the flags/options might be like in 3. If a breaking change isn't acceptable, I'd probably rather just stick with a send_message() rather than have a send() where a non-default option was required to trigger the single-shot behaviour. Rafael Schloming wrote: I agree with you that send(Message) should do the obvious thing, so I'm not keen on (1). I don't agree that send is a bad name for the streaming behaviour though. I think in the scenario where you are streaming a large message out over the wire, you are still very much sending, it's just that you are sending Message Chunks rather than entire messages, but you are still sending a unit of work that you expect to make it all the way over the wire to the receiver. I also think that automatically rendering objects into amqp bytes shouldn't be only associated with the non streaming case, in other words I want to be able to do something like this: send(Header); send(Chunk); ...; send(Footer) Where each of those things are actual objects that know how to render themselves into the appropriate AMQP section. One possibility here might be to delegate back to the object itself again for a bit more flexibility, e.g. have send check if the object being sent has some sort of send_yourself method and then delegate back to it. That would allow the object to then set up whatever delivery tags it wanted, encode itself however it wanted, and then choose whether or not to advance the link. Presumably in the above example the Header would set up the delivery tag, the Chunk would just send more data, and the Footer would advance the link. That of course does leave the question of defaults when you pass in raw bytes. To keep backwards compatibility we would need to say that passing in raw bytes is equivalent to passing in Chunk(bytes), assuming Chunk is defined to be roughly what I described above. I'm not opposed to breaking compatibility here though, I think that's partly the point of this release. Gordon Sim wrote: I fully agree that automatically encoding an object into bytes shouldn't be restricted to a Message. In theory I also agree that the object being sent could identify whether it is 'complete' or not. My only concern there would be that it might
Re: Review Request 30318: allow for simple send in proton
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote: proton-c/bindings/python/proton/__init__.py, line 2701 https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701 This seems to change the semantics of send in a subtle but odd way. If you pass in something that it knows how to encode into bytes, it will assume that constitutes an entire message and call advance and automatically generate a tag for you. Yet if you pass in raw bytes, it doesn't do this. I think these two things should really be controlled orthogonally, e.g. I might want to be able to configure the sender to assume every call to send is a single message even if I'm just passing in raw bytes, and I might also want to be able to stream large messages out by passing in higher level message chunks that the sender automatically encodes into bytes for me. Gordon Sim wrote: WHat I want is a simple, single call to send a message. I'd like that to be called send(), since that seems a clear and intuitive name for it. However that clashes with the existing definition. I would argue that send() isn't such a great name for the current semantics in that it isn't (in my view) clear that you first need to create a delivery and then need to call advance() when done. To me the current semantic is more like an append_data(). However, I didn't want to impose a breaking change. Hence the somewhat odd combination of semantics for the same name. There are (at least) three ways to deal with this: (1) use send_message() for the new simple, single call semantic and leave send() as is. I could live with that but it seems a shame to me to use the obvious name for the less obvious (and I believe less commonly required) semantic (2) use send() exclusively for the new simple, single call semantic, and have send_bytes() - or better still perhaps, append_data() - as the old semantic. This is obviously a breaking API change though, not sure how acceptable that would be? (3) add in some flag(s)/option(s) to control the single-shot v. part-of-sequence-of-calls semantics. However the defaults need to be decided. So agin, we can default it to the current bheaviour, but that in my view is less intuitive and less commonly what users want. Or we can default it to the new behaviour, but that then is another breaking change. To me, if a breaking change is acceptable, I'd probably go for something like (2), because I think it will be clearer. Perhaps I'm just not imaginative enough yet on what the flags/options might be like in 3. If a breaking change isn't acceptable, I'd probably rather just stick with a send_message() rather than have a send() where a non-default option was required to trigger the single-shot behaviour. Rafael Schloming wrote: I agree with you that send(Message) should do the obvious thing, so I'm not keen on (1). I don't agree that send is a bad name for the streaming behaviour though. I think in the scenario where you are streaming a large message out over the wire, you are still very much sending, it's just that you are sending Message Chunks rather than entire messages, but you are still sending a unit of work that you expect to make it all the way over the wire to the receiver. I also think that automatically rendering objects into amqp bytes shouldn't be only associated with the non streaming case, in other words I want to be able to do something like this: send(Header); send(Chunk); ...; send(Footer) Where each of those things are actual objects that know how to render themselves into the appropriate AMQP section. One possibility here might be to delegate back to the object itself again for a bit more flexibility, e.g. have send check if the object being sent has some sort of send_yourself method and then delegate back to it. That would allow the object to then set up whatever delivery tags it wanted, encode itself however it wanted, and then choose whether or not to advance the link. Presumably in the above example the Header would set up the delivery tag, the Chunk would just send more data, and the Footer would advance the link. That of course does leave the question of defaults when you pass in raw bytes. To keep backwards compatibility we would need to say that passing in raw bytes is equivalent to passing in Chunk(bytes), assuming Chunk is defined to be roughly what I described above. I'm not opposed to breaking compatibility here though, I think that's partly the point of this release. Gordon Sim wrote: I fully agree that automatically encoding an object into bytes shouldn't be restricted to a Message. In theory I also agree that the object being sent could identify whether it is 'complete' or not. My only concern there would be that it might
[jira] [Updated] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
[ https://issues.apache.org/jira/browse/QPID-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6343: - Issue Type: Improvement (was: Bug) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 -- Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Alex Rudyy Assignee: Keith Wall Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
[ https://issues.apache.org/jira/browse/QPID-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295012#comment-14295012 ] Keith Wall commented on QPID-6343: -- Changes look reasonable to me [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 -- Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Alex Rudyy Assignee: Keith Wall Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-6343) [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1
[ https://issues.apache.org/jira/browse/QPID-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-6343. -- Resolution: Fixed [Java Broker] Upgrade Apache Derby dependency to 10.11.1.1 -- Key: QPID-6343 URL: https://issues.apache.org/jira/browse/QPID-6343 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Alex Rudyy Assignee: Keith Wall Fix For: 0.31 Upgrade Apache Derby dependency to 10.11.1.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 30318: allow for simple send in proton
On Jan. 27, 2015, 7:37 p.m., Rafael Schloming wrote: proton-c/bindings/python/proton/__init__.py, line 2701 https://reviews.apache.org/r/30318/diff/1/?file=836290#file836290line2701 This seems to change the semantics of send in a subtle but odd way. If you pass in something that it knows how to encode into bytes, it will assume that constitutes an entire message and call advance and automatically generate a tag for you. Yet if you pass in raw bytes, it doesn't do this. I think these two things should really be controlled orthogonally, e.g. I might want to be able to configure the sender to assume every call to send is a single message even if I'm just passing in raw bytes, and I might also want to be able to stream large messages out by passing in higher level message chunks that the sender automatically encodes into bytes for me. Gordon Sim wrote: WHat I want is a simple, single call to send a message. I'd like that to be called send(), since that seems a clear and intuitive name for it. However that clashes with the existing definition. I would argue that send() isn't such a great name for the current semantics in that it isn't (in my view) clear that you first need to create a delivery and then need to call advance() when done. To me the current semantic is more like an append_data(). However, I didn't want to impose a breaking change. Hence the somewhat odd combination of semantics for the same name. There are (at least) three ways to deal with this: (1) use send_message() for the new simple, single call semantic and leave send() as is. I could live with that but it seems a shame to me to use the obvious name for the less obvious (and I believe less commonly required) semantic (2) use send() exclusively for the new simple, single call semantic, and have send_bytes() - or better still perhaps, append_data() - as the old semantic. This is obviously a breaking API change though, not sure how acceptable that would be? (3) add in some flag(s)/option(s) to control the single-shot v. part-of-sequence-of-calls semantics. However the defaults need to be decided. So agin, we can default it to the current bheaviour, but that in my view is less intuitive and less commonly what users want. Or we can default it to the new behaviour, but that then is another breaking change. To me, if a breaking change is acceptable, I'd probably go for something like (2), because I think it will be clearer. Perhaps I'm just not imaginative enough yet on what the flags/options might be like in 3. If a breaking change isn't acceptable, I'd probably rather just stick with a send_message() rather than have a send() where a non-default option was required to trigger the single-shot behaviour. Rafael Schloming wrote: I agree with you that send(Message) should do the obvious thing, so I'm not keen on (1). I don't agree that send is a bad name for the streaming behaviour though. I think in the scenario where you are streaming a large message out over the wire, you are still very much sending, it's just that you are sending Message Chunks rather than entire messages, but you are still sending a unit of work that you expect to make it all the way over the wire to the receiver. I also think that automatically rendering objects into amqp bytes shouldn't be only associated with the non streaming case, in other words I want to be able to do something like this: send(Header); send(Chunk); ...; send(Footer) Where each of those things are actual objects that know how to render themselves into the appropriate AMQP section. One possibility here might be to delegate back to the object itself again for a bit more flexibility, e.g. have send check if the object being sent has some sort of send_yourself method and then delegate back to it. That would allow the object to then set up whatever delivery tags it wanted, encode itself however it wanted, and then choose whether or not to advance the link. Presumably in the above example the Header would set up the delivery tag, the Chunk would just send more data, and the Footer would advance the link. That of course does leave the question of defaults when you pass in raw bytes. To keep backwards compatibility we would need to say that passing in raw bytes is equivalent to passing in Chunk(bytes), assuming Chunk is defined to be roughly what I described above. I'm not opposed to breaking compatibility here though, I think that's partly the point of this release. Gordon Sim wrote: I fully agree that automatically encoding an object into bytes shouldn't be restricted to a Message. In theory I also agree that the object being sent could identify whether it is 'complete' or not. My only concern there would be that it might
Re: Review Request 30318: allow for simple send in proton
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 12:17 p.m.) Review request for qpid and Rafael Schloming. Changes --- Updated to reflect Rafi's suggested approach Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs (updated) - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
Re: Review Request 30318: allow for simple send in proton
When you document Python's send, you're going to have to explain that it either appends bytes to the current delivery or delegates to whatever the send behavior happens to be on the passed in object, and then explain how Message has a send behavior that does X. This is much more complex than it should be. And this new behavior is only present in the Python layer. The C-layer send still just appends bytes. Since at the Python layer people will rapidly begin to think of send only in terms of sending whole messages (because that's what the examples will do), they will be surprised when they attempt the same in C. To me, it would be much better to have append_some_bytes and send_a_message as distinct, self-evident operations. On Wed, Jan 28, 2015 at 7:34 AM, Rafael Schloming r...@apache.org wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/#review70001 --- Ship it! Ship It! - Rafael Schloming On Jan. 28, 2015, 12:17 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 12:17 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
[jira] [Commented] (DISPATCH-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295437#comment-14295437 ] ASF subversion and git services commented on DISPATCH-103: -- Commit 1655398 from [~aconway] in branch 'dispatch/trunk' [ https://svn.apache.org/r1655398 ] DISPATCH-103: Add management entity providng get-schema operations. - Add org.amqp.management to qdrouter schema. - Add org.apache.qpid.dispatch extending org.amq.management with get-schema operations - Make org.amqp.management a regulary entity class, move standard mgmt ops Agent to ManagementEntity. - Add tests for get-schema operations. Websocket Listeners --- Key: DISPATCH-103 URL: https://issues.apache.org/jira/browse/DISPATCH-103 Project: Qpid Dispatch Issue Type: New Feature Components: Container Reporter: Ted Ross Fix For: 0.5 Add an option in configured listeners to use websockets encapsulation. This will allow AMQP clients inside web browsers to directly connect to the message bus. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 30318: allow for simple send in proton
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/#review70080 --- proton-c/bindings/python/proton/__init__.py https://reviews.apache.org/r/30318/#comment115044 Call it send_bytes rather than stream? Stream has a different meaning. - Alan Conway On Jan. 28, 2015, 6 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 6 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
Re: Review Request 30318: allow for simple send in proton
On Jan. 28, 2015, 8:58 p.m., Alan Conway wrote: Oops, meant to say Ship It - Alan --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/#review70080 --- On Jan. 28, 2015, 6 p.m., Gordon Sim wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 6 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
Re: Review Request 30379: Skeleton code for a possible approach for codec improvements in proton-j.
On Jan. 28, 2015, 8:49 p.m., Rafael Schloming wrote: proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java, line 141 https://reviews.apache.org/r/30379/diff/1/?file=839118#file839118line141 do we want to specify the types for the Map here? We should IMO. The current code does not. I was thinking String, Object. On Jan. 28, 2015, 8:49 p.m., Rafael Schloming wrote: proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesDecoder.java, line 32 https://reviews.apache.org/r/30379/diff/1/?file=839119#file839119line32 I'm not quite following how this part works. How do you know that the data you have is a flow? Or is this a callback that is made when you've detected a flow in the decoding stream? If the latter is the case, what is actually invoking this? Yes this is called when we detect it's a flow performative in the decoding stream. I didn't put together the part that was going to call this method yet. I will do so shortly On Jan. 28, 2015, 8:49 p.m., Rafael Schloming wrote: proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesEncoder.java, line 32 https://reviews.apache.org/r/30379/diff/1/?file=839120#file839120line32 It might be worth introducing an Encodable interface with Encodable.encode(Encoder) and Encodable.decode(Decoder). That way you could keep the encode and decode logic together in the performative itself. I think having the encode/decode logic together would be good so that you could easily spot if they are asymmetric. It would also ease code generation if you end up going that route since you just need to generate the one class. I think it would also give you a good way to supply the missing piece of your decode picture that I mentioned above, since you could just have a general purpose decoder that holds a map from a descriptor to a factory. Then in your decoder when you get the descriptor callback you can lookup and construct the appropriate Encodable and delegate to it. I was initially hesitant to put any codec logic in the POJO version of the performatives. But I think the approach you propose is a good compromise and would come in handy for code generation and building a general purpose decoder. I will be posting another patch tonight with changes. - rajith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30379/#review70071 --- On Jan. 28, 2015, 8:04 p.m., rajith attapattu wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30379/ --- (Updated Jan. 28, 2015, 8:04 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Skeleton code for a possible approach for codec improvements in proton-j. Diffs - proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesDecoder.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesEncoder.java PRE-CREATION Diff: https://reviews.apache.org/r/30379/diff/ Testing --- Thanks, rajith attapattu
[jira] [Created] (QPID-6345) [Java Broker] Allow enable TLS Ciphers to be restricted
Rob Godfrey created QPID-6345: - Summary: [Java Broker] Allow enable TLS Ciphers to be restricted Key: QPID-6345 URL: https://issues.apache.org/jira/browse/QPID-6345 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.31 Allow the enabled TLS Cipher Suites to be configured on a per port basis -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6345) [Java Broker] Allow enabled TLS Ciphers to be restricted through configuration
[ https://issues.apache.org/jira/browse/QPID-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-6345: -- Summary: [Java Broker] Allow enabled TLS Ciphers to be restricted through configuration (was: [Java Broker] Allow enable TLS Ciphers to be restricted) [Java Broker] Allow enabled TLS Ciphers to be restricted through configuration -- Key: QPID-6345 URL: https://issues.apache.org/jira/browse/QPID-6345 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.31 Allow the enabled TLS Cipher Suites to be configured on a per port basis -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-6) Implement link-routing
[ https://issues.apache.org/jira/browse/DISPATCH-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295917#comment-14295917 ] ASF subversion and git services commented on DISPATCH-6: Commit 1655478 from [~tedross] in branch 'dispatch/trunk' [ https://svn.apache.org/r1655478 ] DISPATCH-6 - Update pyrouter to carry the address class with the address rather than assume all addresses are in the Mobile class. This will be used to carry 'C' class addresses for attach-routing. Moved the logging of mapped/unmapped addresses from C to Python to make the logs more descriptive. Implement link-routing -- Key: DISPATCH-6 URL: https://issues.apache.org/jira/browse/DISPATCH-6 Project: Qpid Dispatch Issue Type: New Feature Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.4 All routing is done at the message-delivery level in Dispatch. Implement link routing (at the link-attach level) as an alternative mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6345) [Java Broker] Allow enable TLS Ciphers to be restricted
[ https://issues.apache.org/jira/browse/QPID-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295806#comment-14295806 ] ASF subversion and git services commented on QPID-6345: --- Commit 1655457 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1655457 ] QPID-6345 : Allow enabled cipher suites to be configured [Java Broker] Allow enable TLS Ciphers to be restricted --- Key: QPID-6345 URL: https://issues.apache.org/jira/browse/QPID-6345 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.31 Allow the enabled TLS Cipher Suites to be configured on a per port basis -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 30379: Skeleton code for a possible approach for codec improvements in proton-j.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30379/#review70071 --- proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java https://reviews.apache.org/r/30379/#comment115027 do we want to specify the types for the Map here? proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesDecoder.java https://reviews.apache.org/r/30379/#comment115040 I'm not quite following how this part works. How do you know that the data you have is a flow? Or is this a callback that is made when you've detected a flow in the decoding stream? If the latter is the case, what is actually invoking this? proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesEncoder.java https://reviews.apache.org/r/30379/#comment115043 It might be worth introducing an Encodable interface with Encodable.encode(Encoder) and Encodable.decode(Decoder). That way you could keep the encode and decode logic together in the performative itself. I think having the encode/decode logic together would be good so that you could easily spot if they are asymmetric. It would also ease code generation if you end up going that route since you just need to generate the one class. I think it would also give you a good way to supply the missing piece of your decode picture that I mentioned above, since you could just have a general purpose decoder that holds a map from a descriptor to a factory. Then in your decoder when you get the descriptor callback you can lookup and construct the appropriate Encodable and delegate to it. - Rafael Schloming On Jan. 28, 2015, 8:04 p.m., rajith attapattu wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30379/ --- (Updated Jan. 28, 2015, 8:04 p.m.) Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Skeleton code for a possible approach for codec improvements in proton-j. Diffs - proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesDecoder.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesEncoder.java PRE-CREATION Diff: https://reviews.apache.org/r/30379/diff/ Testing --- Thanks, rajith attapattu
Re: Review Request 30318: allow for simple send in proton
On 01/28/2015 12:53 PM, Justin Ross wrote: When you document Python's send, you're going to have to explain that it either appends bytes to the current delivery or delegates to whatever the send behavior happens to be on the passed in object, and then explain how Message has a send behavior that does X. This is much more complex than it should be. And this new behavior is only present in the Python layer. The C-layer send still just appends bytes. Since at the Python layer people will rapidly begin to think of send only in terms of sending whole messages (because that's what the examples will do), they will be surprised when they attempt the same in C. To me, it would be much better to have append_some_bytes and send_a_message as distinct, self-evident operations. How about this as a compromise: We change the name of the current send() method to send_bytes() (or something similar). We add a new send() method that always expects an object with a send method on it, taking the sender as an argument. This is really just a convenience to allow sender.send(message) as well as message.send(sender). Optionally we can then perhaps allow the special treatment of the argument to Sender.send() where it is bytes, for one release as a way to transition. Applications wanting to use that form would be directed by documentation to use the send_bytes() method. That we we end up with something that is simple, intuitive yet extensible, and also have the option to avoid breaking the existing api. So, as far as the patch under review, this would simply mean adding a send_bytes() method, and calling that from Message.send() and (optionally) from Sender.send() if the argument does not have a send method on it. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6336) [0-8..0-91] State of connection can be corrupted by subsequent reconnection attempts
[ https://issues.apache.org/jira/browse/QPID-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295954#comment-14295954 ] ASF subversion and git services commented on QPID-6336: --- Commit 1655485 from [~k-wall] in branch 'qpid/trunk' [ https://svn.apache.org/r1655485 ] QPID-6336: Add extra logging to help understand occasional SSLTest failure showing on slow CI box [0-8..0-91] State of connection can be corrupted by subsequent reconnection attempts Key: QPID-6336 URL: https://issues.apache.org/jira/browse/QPID-6336 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.12, 0.18, 0.22, 0.30 Reporter: Keith Wall Assignee: Keith Wall If the connection url is configured to retry failed connections, a race in the 0-8..0-91 path means that it is possible for the internal state of the connection to become corrupt. This can cause the JMS Connection object to believe it is closed when it is not, and the underlying protocol handler object may emit a invalid sequence of AMQ connection frames during the re-connect attempts. The problem does not occur if the connection (or reconnection) attempt fails owing to a TCP connection refused, but does occur if the connection failure occurs later i.e virtual host not active or password error. For this reason, this problem is most likely to affect users of the Java Broker utilising the BDB-HA option where failover is used to follow the active virtual host. The 0-10 path is unaffected. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 30318: allow for simple send in proton
Yes, I think that would be a lot better. On Wed, Jan 28, 2015 at 11:00 AM, Gordon Sim g...@redhat.com wrote: On 01/28/2015 12:53 PM, Justin Ross wrote: When you document Python's send, you're going to have to explain that it either appends bytes to the current delivery or delegates to whatever the send behavior happens to be on the passed in object, and then explain how Message has a send behavior that does X. This is much more complex than it should be. And this new behavior is only present in the Python layer. The C-layer send still just appends bytes. Since at the Python layer people will rapidly begin to think of send only in terms of sending whole messages (because that's what the examples will do), they will be surprised when they attempt the same in C. To me, it would be much better to have append_some_bytes and send_a_message as distinct, self-evident operations. How about this as a compromise: We change the name of the current send() method to send_bytes() (or something similar). We add a new send() method that always expects an object with a send method on it, taking the sender as an argument. This is really just a convenience to allow sender.send(message) as well as message.send(sender). Optionally we can then perhaps allow the special treatment of the argument to Sender.send() where it is bytes, for one release as a way to transition. Applications wanting to use that form would be directed by documentation to use the send_bytes() method. That we we end up with something that is simple, intuitive yet extensible, and also have the option to avoid breaking the existing api. So, as far as the patch under review, this would simply mean adding a send_bytes() method, and calling that from Message.send() and (optionally) from Sender.send() if the argument does not have a send method on it. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
test
please ignore
Re: Review Request 30318: allow for simple send in proton
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30318/ --- (Updated Jan. 28, 2015, 6 p.m.) Review request for qpid and Rafael Schloming. Changes --- Provide explicit method through which the current behaviour can be obtained. The behaviour of Sender.send() on receiving bytes may change in the future so should not be relied on as yet. Repository: qpid-proton-git Description --- Sending a message requires several steps: create a delivery with a unique tag, encode the message, cal send(), call advance. While this gives a lot of flexibility and power (e.g. streaming messages in chunks without ever holding the entire thing in memory), for many, many use cases, a simpler solution would be adequate and would avoid users having to learn what is in my view one of the more esoteric aspects of the API. The attached patch adds send support for a Message object, such that a message can be sent with a single call. It also allows the send() method to be 'dual purpose'. It remains backwards compatible as a way of appending bytes to the current delivery, but can also be used as a one-step call to send a single message. At present the engine examples in python make use of a similar simplification, but one that is added dynamiccaly and is therefore less clean and obvious. It currently also doesn't work as well for sending on links established by the remote peer. This addition would in my view allow for simpler use where needed, without breaking any existing usage. Diffs (updated) - proton-c/bindings/python/proton/__init__.py 17cef30 Diff: https://reviews.apache.org/r/30318/diff/ Testing --- Thanks, Gordon Sim
[jira] [Created] (QPID-6344) Package python-qpid 0.18 is not available on EL5
Brian Bouterse created QPID-6344: Summary: Package python-qpid 0.18 is not available on EL5 Key: QPID-6344 URL: https://issues.apache.org/jira/browse/QPID-6344 Project: Qpid Issue Type: Improvement Components: Python Client Affects Versions: 0.18 Reporter: Brian Bouterse The Pulp team needs to run Qpid client code contained in python-qpid on EL5 systems. We need version 0.18. Currently we have no SRPM that Pulp could build in koji.katello.org and then distribute with Pulp. Can an SRPM please be provided that will allow us to build python-qpid 0.18 on EL5? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 30379: Skeleton code for a possible approach for codec improvements in proton-j.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30379/ --- Review request for qpid and Rafael Schloming. Repository: qpid-proton-git Description --- Skeleton code for a possible approach for codec improvements in proton-j. Diffs - proton-j/src/main/java/org/apache/qpid/proton/amqp/transport2/Flow.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesDecoder.java PRE-CREATION proton-j/src/main/java/org/apache/qpid/proton/codec2/TransportTypesEncoder.java PRE-CREATION Diff: https://reviews.apache.org/r/30379/diff/ Testing --- Thanks, rajith attapattu
[jira] [Commented] (DISPATCH-6) Implement link-routing
[ https://issues.apache.org/jira/browse/DISPATCH-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295753#comment-14295753 ] ASF subversion and git services commented on DISPATCH-6: Commit 1655450 from [~tedross] in branch 'dispatch/trunk' [ https://svn.apache.org/r1655450 ] DISPATCH-6 - Add connection open/close handlers to on-demand connectores in connection_manager. Implement link-routing -- Key: DISPATCH-6 URL: https://issues.apache.org/jira/browse/DISPATCH-6 Project: Qpid Dispatch Issue Type: New Feature Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.4 All routing is done at the message-delivery level in Dispatch. Implement link routing (at the link-attach level) as an alternative mechanism. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
